Re: Mirja Kühlewind's No Objection on draft-ietf-6man-segment-routing-header-22: (with COMMENT)

["Darren Dukes (ddukes)" <[e-mail]>]

Thanks Mirja for the review.  comments inline.

> On Aug 29, 2019, at 12:18 PM, Mirja Kühlewind via Datatracker <[e-mail]> wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-6man-segment-routing-header-22: No Objection
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I have a couple of questions/comments:
> 
> 1) Given this is an IP header extension that would need to be added to every
> single packet when used, I would have expected a more byte-conserving design
> for the HMAC TLV. It doesn't seems that the RESERVED field is actually needed
> (as padding can be done by the padding TLVs) and the HMAC TLV could even be
> variable length based on the actual output of the HMAC algorithm used. Why was
> the current design chosen instead?

HMAC was defined before TLVs were added, and the HMAC was converted into a TLV from a fixed length structure that followed a segment list.
The TLV format reused that fixed length structure.


> 
> 2) I agree with the TSV-ART review (Thanks Joe!) that MTU discussion in section
> 5.3 is not sufficient and at least a pointer to draft-ietf-intarea-tunnels
> would be good.

I’ll work with Joe on this, some others had similar comments and I think we can resolve the concern.

> 
> 3) Sec 5.6: I would rather like to see a clear applicability state at the
> beginning of this document that the statement in section 5.6 at the end of the
> document. E.g. use of the HMAC TLV also assumes some kind of common
> (centralised/SDN-based) pre-configuration. I think it would be important to
> state these kind of constraints upfront. I think this point does not raise
> discuss level, however, I think it would be really important to address because
> it becomes clear when ready the document that certain deployment scenario was
> assumed and I think it would be appropriate to restrict the applicability of
> this spec to this scenario. Otherwise I think it would not be acceptable to
> have some of the "out-of-scope" statements in this doc.
> 

The SR Architecture RFC8402 defines the use of SR and the SRH within an SR domain, and defines the SR domain.
This is referenced in the introduction and I think we can expect implementors to understand the architecture.

I believe this is sufficient to address your concern.


> 4) I also agree with the TSV-ART review that the registration procedure for the
> Flags should be "IETF review". Alternatively I actually recommend to not create
> this registry now and leave this decision to the first RFC that will assign a
> flag (which would anyway need to update this RFC).

Thanks there have been several different suggestions around the review type - IETF Review, IESG Review, clarification text in IANA registry and Expert Review.

I don’t know that we can satisfy all opinions on this.

Having a registry is something the WG wanted in order to document in a single location what flags where implemented in which specification.
I think it serves that purpose.
As you rightly suggest a document adding a flag does need to update this document and register the flag in the IANA registry.

Darren

> 
>