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

From: Zaheduzzaman Sarker via Datatracker <[email-masked]>
Date: Wed, 06 Apr 2022 06:22:49 -0700

Zaheduzzaman Sarker 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:
----------------------------------------------------------------------

Thanks for working on this  specification and I hope efforts for Path MTU
discovery will be successful and useful. Thanks to  Olivier Bonaventure for 
the  TSVART review.

I have the following  observations/questions  :

* Section 2:  s/1998/1988 for RFC 1063.

* Section 6.1 and 6.2: I was expecting more clear description of
consequences/analysis when the SHOULD's are followed. The security
consideration was felt a little bit short of describing potential risk analysis
in that regard.

* Section 6.3:  is this ref to section 4.1 of RFC9000 the right reference here?

* Section 9: I am not sure I get a clear view of the goals of the experiment.
is  this to check the dependability questions? or the proof of support those
are listed in this section? can we be more precise on what we expect the 
implementation experience report(s)?.

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 6 Apr 2022 15:26:25 +0100

> * Section 2:  s/1998/1988 for RFC 1063.

BH+GF: We will fix.

> consequences/analysis when the SHOULD's are followed.

GF+BH:  See response EV's comment also in IESG LC.

> The security

GF+BH: Section 8 does not contain normative recommendations. I think the normative
text is in RFC8085, as noted.

> * Section 6.3:  is this ref to section 4.1 of RFC9000 the right reference here?

GF+BH: It is casualty of a late edit, we will fix.

> implementation experience report(s)?.
GF+BH: The experiment is to gain experience in deploying a HBH option. It seemed imprudent to make a PS for a mechanism that included requirements fo hosts and also for routers.

Hope that helps, if you have further insight - we will also include in the next revision.
Gorry & Bob

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Thu, 7 Apr 2022 14:49:28 +0000

> On 6 Apr 2022, at 16:26, Gorry Fairhurst <[email-masked]> wrote:
> 
Can I get a link to that comment or a summery of what was the response?
> text is in RFC8085, as noted.

Didn’t understand what is noted where?
> GF+BH: The experiment is to gain experience in deploying a HBH option. It seemed imprudent to make a PS for a mechanism that included requirements fo hosts and also for routers.
Please make the goal clearer. I also think it would be helpful to align the expectations on the results/report of the experiments.

//Zahed

---

From: Erik Kline <[email-masked]>
Date: Thu, 7 Apr 2022 16:53:12 -0700

> Can I get a link to that comment or a summery of what was the response?

Assuming EV == Eric Vyncke, you should hopefully have a thread in your
inbox with the subject "Éric Vyncke's No Objection on
draft-ietf-6man-mtu-option-13: (with COMMENT)".  Repasting a snipper of
Gorry's responses on that thread:

---8<---

## Section 6.1

For a router not configured for HbH-processing: why only "SHOULD ignore" ?
Either exception use case(s) should be provided or a "MUST NOT" and
"MUST" (for
forward) be used.

GF+BH: The SHOULD language doesn’t work perfectly here.
I guess it's really a statement of fact "will ignore". Not sure it is
worth changing.

Why does a router "SHOULD" only update and not "MUST" ? This is an
experimental
document and not a proposed standard one so little reason to be
ultra-cautious.
If "SHOULD" is kept, then when can/should a router deviate from the update
action ?

GF+BH:: We are happy to say MUST, i.e.if it implements this RFC it needs to.

--->8---

---8<---

## Section 6.2

"This cached value can be used by other flows that share the host's
destination
cache." is hard to parse and possibly incorrect (as missing the egress
interface), suggest to use "other flows to the same destination and same
egress
interface" ?

===

GF+BH: Probably good to clarify. Indeed,it needs to be balanced with my
ECMP text
added to 8201 that warns that paths are not just identified by address
(see below)

--->8---

Separately, I think there are some things we should consider for the host
behavior:

    * does changing a SHOULD to a MUST require the document to go back to
WGLC/IETF LC again?

    * having MUSTs for nodes that implement this specification is fine
(assuming consensus), but we should note that, with respect to PTMUD
overall, the RFC 8201 language continues pre-2119 lowercase syntax and

    * both this option and ICMPv6 PTBs are not strongly authenticated,
merely correlated with existing communications, and are designed to be
change en route; therefore

    * it might make sense to allow hosts in some networks the latitude to
implement local policy.

I should maybe have thought of these points (and others) this morning, but
I was afflicted with "7am brain".  =)

-ek

---

From: Bob Hinden <[email-masked]>
Date: Thu, 7 Apr 2022 18:13:59 -0700

Erik,

Several of the AD Comments and one Discuss are about the contents of Section 6.1. "Router Behavior”.  The text from -13 version of the draft (unchanged since at least -08):

   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.

   Routers that support this option SHOULD compare the value of the Min-
   PMTU field with the MTU configured for the outgoing link.  If the MTU
   of the outgoing link is less than the Min-PMTU, the router rewrites
   the Min-PMTU in the Option to use the smaller value.  (The router
   processing is performed without checking the valid range of the Min-
   PMTU or the Rtn-PMTU fields.)

   A router MUST ignore and MUST NOT change the Rtn-PMTU field or the
   R-Flag in the option.

   Discussion:

   *  The design of this option makes it feasible to be implemented
      within the fast path of a router, because the processing
      requirements are minimal.

Gorry and I have proposed some alternatives based on the AD comments.

However, thinking about is more, the only change I would make is to remove the “Discussion” text based on Éric Vyncke comment.   I think the SHOULD language is correct, this is what we want to happen unless there is a good reason do do something else.

Given the time zones, I have not discussed this with my co-author Gorry, so this is my view.

Bob

> On Apr 7, 2022, at 4:53 PM, Erik Kline <[email-masked]> wrote:
> 
> GF+BH:: We are happy to say MUST, i.e.if it implements this RFC it needs to

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Fri, 8 Apr 2022 08:26:49 +0000

> On 8 Apr 2022, at 01:53, Erik Kline <[email-masked]> wrote:
> 
> 
> Assuming EV == Eric Vyncke, you should hopefully have a thread in your inbox with the subject "Éric Vyncke's No Objection on draft-ietf-6man-mtu-option-13: (with COMMENT)”.
Ok, I should have thought about that, I think I got distracted by the phrase IESG LC :-).
>   Repasting a snipper of Gorry's responses on that thread:
> 
> ---8<---
> 
> ## Section 6.1
> 
> Separately, I think there are some things we should consider for the host behavior:
> 
>     * does changing a SHOULD to a MUST require the document to go back to WGLC/IETF LC again?
May be it needs to, but I think we are discussing where the change is required or not and that is most important thing to settle here. If that is settled the rest of it is process question.
> 
>     * having MUSTs for nodes that implement this specification is fine (assuming consensus), but we should note that, with respect to PTMUD overall, the RFC 8201 language continues pre-2119 lowercase syntax and
> 
>     * both this option and ICMPv6 PTBs are not strongly authenticated, merely correlated with existing communications, and are designed to be change en route; therefore
> 
>     * it might make sense to allow hosts in some networks the latitude to implement local policy.
> 
> I should maybe have thought of these points (and others) this morning, but I was afflicted with "7am brain".  =)
I think I agree that there are cases where network policies are important. However, if we thrive for MTU discory to work for the usefulness it has, we should try in our specifications to be specific about it rather left to the choice of implementers (even thought ultimately they decide what they want to implement). If we can’t do that for example - one argument I saw is that this "spec is experimental only” , then at least we should let the implementers know about the implications of not following the recommendation and how that can hurt the experiment of it. I am missing this part as well.

Having said that I respect the WG’s concuss if they think a SHOULD is enough for this experimental spec and there is no need warn about the implications if the implementers not even following the SHOULD. I can live with that.

//Zahed