On Wed, Sep 26, 2018 at 6:32 PM Mahesh Jethanandani <mjethanand...@gmail.com>
wrote:

>
>
> > On Sep 26, 2018, at 1:49 PM, Warren Kumari <war...@kumari.net> 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.
>
>

Discuss cleared.



> >
> >
> > ----------------------------------------------------------------------
> > 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?
>

Yup, perfect.

People often seem to forget this -- the surrounding text is all
introductory, and so I was concerned that the audience would see that, and
think: "But the packet length is in the header", and miss the distinction
that L3 packet length != L2 packet lenght, etc.


>
> >
> > 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.
>

Doh! Sorry.



>
> >
> > 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/
>
>
Win!

Thank you for accepting the suggestions in the spirit they were offered.
W



> Thanks.
>
> >
> >
>
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
>
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to