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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Thu, 29 Aug 2019 09:18:59 -0700

Mirja Kühlewind 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:
----------------------------------------------------------------------

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?

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.

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.

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