Warren Kumari has entered the following ballot position for draft-ietf-netmod-acl-model-19: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Be ye not afraid -- this DISCUSS is easily cleared, but sufficiently important that I thought it worth making, and making sure it didn't slip through the cracks. The description for match-on-ipv4 says: "The device can support matching on IPv4 headers.", but the description for 'match-on-tcp', 'match-on-udp', 'match-on-icmp' say: "The device can support <protocol> headers." I really think that these need to be "The device can support matching on <protocol> headers." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1: "In case a vendor supports it, metadata matches apply to fields associated with the packet but not in the packet header such as input interface or overall packet length". I don't have a suggested replacement, but seeing as this is introductory text, I figured it was aimed at people not familiar with how forwarding / filtering works. I'm slightly concerned that some people will get confused, because almost all protocols include a "packet length" in the header. Perhaps just dropping the "or overall packet length"? (Yes, we could get into a long thing on protocol packet length, and overall length, etc, but that's likely to not be helpful in the document). Section 2: Nit: "It is very important that model can be used easily by applications/attachments." models. Section 3: "Packet header matching applies to fields visible in the packet such as address or CoS or port numbers." CoS isn't expanded, and isn't in the well known acronyms list. RFC2474 perhaps? Section 3: "These include features such as "Device can support ethernet headers" or "Device can support of IPv4 headers". "can support of" makes no sense. Also, I *think* Ethernet is uppercase. This is a nit. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
