The question is "should an IPv4 netmask field be its own fieldtype?" The main problem being that netmasks are being treated as IPv4 fields and are attempted to be named resolved, which shouldn't be. The original patch created an "IPv4_MASK" field type to handle this. Recent discussions about field types (on this mailing list and other patch reviews) have consistently resulted in new "display types" being created over new field types. Following this, I amended the original patch to use a "display type" instead of a field type. The argument for the field type by the original patch author (Jeffrey Smith, CCed here in case he's not on -dev) is:
"... the display filter "protocolXYZ.netmask == 10.0.0.1/24" is currently valid but semantically makes no sense. Also, I think "protocolXYZ.netmask == /24" does make sense but does not work. This change makes the sensible thing happen in those cases, but a display-only change would not have the same effect."
I'm not familiar enough with using this filter notation or know how popular it is to know how much this impact should be considered. But I know there are others on the list that may have stronger and more educated opinions.
