Subject: Alvaro Retana's No Objection on draft-ietf-6man-mtu-option-13: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Wed, 06 Apr 2022 10:53:08 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-6man-mtu-option-13: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/

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

[Eric and Zahed brought up comments related to the text in §6.1 -- my concerns
are slightly different.]

===
   6.1. Router Behavior

   Routers that are not configured to support Hop-by-Hop Options SHOULD
   ignore this option and SHOULD forward the packet [RFC8200].

   Routers that support Hop-by-Hop Options, but that are not configured
   to support this option SHOULD ignore the option and SHOULD forward
   the packet.
===

Both paragraphs seem to want to define the behavior of routers that don't
support this specification or HbH in general. I interpret "not configured to
support" to mean that the router doesn't support (vs. one that has been
upgraded to support the new option but was manually configured not to). Note
that the next paragraph covers the case of "[r]outers that support this option".

If they don't support the option, then this document can't expect, much less
specify, any behavior.

Also, and more importantly, the specification above conflicts with rfc8200.

The first paragraph refers to routers that "are not configured to support
Hop-by-Hop Options". The reference to rfc8200 confuses me because rfc8200 (1)
doesn't use rfc2119 language, and (2) already describes the expectation.

>From §4/rfc8200: "it is now expected that nodes along a packet's delivery path
only examine and process the Hop-by-Hop Options header if explicitly configured
to do so."  I interpret this expectation as a requirement (MUST), not a
recommendation (SHOULD). There is a conflict between what is specified here and
rfc8200.

I believe it is unnecessary to try to restate what rfc8200 already says.
However, please say so clearly if you still want to point at what rfc8200 says
about routers not configured to support Hop-by-Hop Options.

Suggestion>
   Routers that are not configured to support Hop-by-Hop Options are
   expected not to examine or process the contents [RFC8200].

The second paragraph refers to routers that "are not configured to support this
option". The option type starts with 00, which §4.2/rfc8200 and §5 in this
document define as "skip over this option and continue processing the header"
(if the type is not recognized). In this case, the behavior is required, but
this section only recommends (SHOULD) it. There is a conflict between what is
specified here and what is written in rfc8200 and §5.

I believe it is unnecessary to try to restate what rfc8200 and §5 already say.
However, if you still want to talk about routers that won't recognize the new
option in this section, please say so without Normative language.

Suggestion>
   Routers that support Hop-by-Hop Options but that don't recognize
   this new option will skip over it and continue processing the header.

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 7 Apr 2022 09:27:03 +0100

> https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/

Thanks again for this careful read. There are several inter-twined comments from others, which will all need resolved consistently, but I do think these are helpdful proposals:

This topic related to RFC2119 was discussed, of course, and a little 
depends on how these keywords are interpretted in this slightly odd 
context, and now is the time to get this finalised! If we start 
precisioning this, I think Bob and I would likely prefer:

   Routers that are not configured to support Hop-by-Hop Options are
   not expected to examine or process the contents [RFC8200].
>     this new option will skip over it and continue processing the header.
Routers that support Hop-by-Hop Options, but that do not recognize
this new option will skip over the option and continue processing the header.

...

Best wishes,
Gorry