Subject: Éric Vyncke's No Objection on draft-ietf-6man-segment-routing-header-22: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Thu, 05 Sep 2019 05:15:45 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-6man-segment-routing-header-22: 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-6man-segment-routing-header/

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

Thank you for the hard work put into this easy to read document. Happy to see
how this document has improved since the first drafts, years ago while I
contributed to those first drafts.

Regards,

-éric

== COMMENTS ==

-- Section 2 --
C.1) Unsure whether the use of multiple "U" to indicate unused bit is useful,
most RFC states that this field is reserved.

C.2) An explanation about why segments are in the reverse order would be
helpful for the reader.

-- Section 2.1 --
C.3) " an implementation adding or parsing TLVs MUST support PAD TLVs" is it
just 'parsing' == read them ?

-- Section 2.1.2 --
C.4) it is possibly already in the security AD DISCUSSes, but, I would make the
HMAC field variable length as it depends on the HMAC algorithm being used.

-- Section 2.1.2.1 --
C.5) "It may be based on ..., HMAC Key ID, or other packet fields." seems to
contradict the opaque quality of the HMAC Key ID. I suggest to remove the
mention of 'HMAC Key ID' here. C.6) See also C.4 (so please address either C.6
or C.4), need to specify what to truncate: most significant or least
significant bytes.

-- Section 4.3.1.1.1. --
C.7) Describing the use cases behind the example could help the reader.

-- Section 4.3.1.2. --
C.8) rather a question of mine, is this behavior applicable for all SID on the
paths? (i.e. on all SRv6-capable routers where the current DA matches the
locally configured interface addresses/SID ?) I would have guessed that
decapsultion only happen at the last segment as explained in 4.3.2.

== NITS ==

-- Section 2.1.1 --
s/to verify the source of a packet/to verify whether the source of a packet/

-- Section 5.4 --
Please add a note to change the '4' to the IANA allocated value.