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

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 9 Oct 2019 16:11:37 +0000

Hi Eric, thanks for the review! I missed your comments email when it was sent originally, please see inline.

> On Sep 5, 2019, at 8:15 AM, Éric Vyncke via Datatracker <[email-masked]> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-6man-segment-routing-header-22: No Objection
> 
> ----------------------------------------------------------------------
> 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.

The result is the same, but since there is a registry for the bits U/Unused seemed most appropriate.

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

Reversed from what?  
It’s been a long time so I don’t recall why this order is better than any other except that any other routing headers use the same order without discussion of why.

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

Parsing is required for reading a TLV.
Therefore a node parsing TLVs must support PAD TLVs.

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

Thanks, will be closed in 25 with variable length HMAC TLV.

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

The HMAC Key ID is opaque but it identifies a key.  
Using the opaque value of the Key ID is one thing an implementation may use, but local configuration on how it may use it is outside this document’s scope.

I don’t understand your C.6 reference and truncation comment, but revision 25 describes the truncation of HMAC and variable length HMAC TLVs fully.
I think that should resolve this comment.

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

The example is intended to be brief and for illustration purpose only, not normative.
I think it’s most appropriate to leave it brief and allow future specifications to define when the HMAC TLV is/must be processed if necessary.

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

Extension headers are processed in order.
A header following a routing extension header is not processed until SL==0.
Therefore decapsulation only happens at the last segment.

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

Thanks, closed in 24 clarifying the source vs source address with additional clarity.

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

Thanks, closed in 24