Subject: [Idr] Éric Vyncke's No Objection on draft-ietf-idr-flow-spec-v6-21: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 24 Nov 2020 07:52:30 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-idr-flow-spec-v6-21: No Objection

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-idr-flow-spec-v6/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my DISCUSS point in the security section in the latest
revision. I am now balloting a NO OBJECTION so clearing my previous blocking
DISCUSS.

Regards

-éric

PS: I still have doubts about the implementation status wiki page though ;-)

-------- IGNORE TEXT BELOW ----------
The rest below is for archival purpose as all the points have been addressed.

Thank you for the work put into this document. It is indeed due time to filter
also those IPv6 packets ;-)

Please find below one blocking DISCUSS point, some non-blocking COMMENT points,
and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

I am puzzled by the absence of a flow spec for the first Next-Header being a
specific value and by the absence of a flowspec for the occurence of any
extension header in the extension header chain. Extension headers are an
important difference compared to IPv4 and could be 'nasty' as well (e.g.,
hop-by-hop header). Why was this not considered by the authors ? Or is there
another document in the WG to address this issue ?

== COMMENTS ==

-- Section 3.3 --
How is the upper-layer defined here? Basically, how a node can determine
whether it is an extension header or an upper-layer header? While I agree that
there are not too many new upper-layer protocols being specified, I would
prefer to have a definition of "upper-layer" here either by listing (or
referring to a IANA registry) all existing extension headers (then all 'next
header' not being 'extension header' are by default 'upper layer') or
vice-versa.

-- Section 3.6 --
Just curious ;-) Why is bit 7 not used in this encoding ?

-- Section 3.7 --
I share Ben Kaduk's concern about the encoding of the flow label in less than
20 bits.

== NITS ==

-- Section 3.1 (and possibly others) --
Sometimes the field 'length' is all lower case and sometimes it is capitalized.

-- Section 3.8.2 (and possibly others) --
Please use RFC 5952 to write IPv6 addresses.