> On Sep 26, 2018, at 1:49 PM, Warren Kumari <[email protected]> wrote: > > 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.”
Ok. > > > ---------------------------------------------------------------------- > 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). I am not sure what the concern is. The "overall packet length" being referred to is not the “packet length” in the header field. It is the length of the packet as received over the wire. Is that the clarification you were looking for in the document? > > Section 2: > Nit: "It is very important that model can be used easily by > applications/attachments." models. Ok. > > 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? It is in Section 1 and 1.1. > > 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. Will s/support/match on/ Thanks. > > Mahesh Jethanandani [email protected] _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
