Subject: [netmod] Warren Kumari's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Sep 2018 13:49:13 -0700

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.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 26 Sep 2018 18:32:46 -0700

> On Sep 26, 2018, at 1:49 PM, Warren Kumari <[email-masked]> wrote:
> 
> headers.”

Ok.

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?

> applications/attachments." models.

Ok.

> acronyms list. RFC2474 perhaps?

It is in Section 1 and 1.1.

> *think* Ethernet is uppercase. This is a nit.

Will 
s/support/match on/

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Sep 2018 19:01:54 -0700

On Wed, Sep 26, 2018 at 6:32 PM Mahesh Jethanandani <[email-masked]>
wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

Discuss cleared.

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

> It is in Section 1 and 1.1.

Doh! Sorry.

> > *think* Ethernet is uppercase. This is a nit.
Win!

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

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