IPv6 Minimum Path MTU Hop-by-Hop Option
draft-ietf-6man-mtu-option-15

[Ballot comment]
In Sections 1 and 2, you refer to "this draft", e.g.:

  The purpose of this draft is to improve the situation ...

When published, this won't be a draft.  I suggest changing both to "document".

[Result of my DISCUSS:] Some of the SHOULDs in Section 6 make me uneasy as used here, but it seems like they were done this way in RFC 8200 as well, so this is possibly the wrong place to get that fixed.  I'll let the sponsoring AD make the final call on this.

[Ballot comment]
I am abstaining, explicitly a non-blocking position.

Measurements like those done by Geoff Huston/Joao Damas (http://iepg.org/2022-03-20-ietf113/huston-v6frag.pdf) and those contained in draft-vyncke-v6ops-james make me dubious that HbH options will reliable in the Internet in any sort of reasonable timeframe. In addition, I'm dubious that operators will be willing to enable HbH processing to enable this mechanism, and, while this HbH option *itself* may be implementable in the fast-path, enabling processing of HbH to find this option seems likely to often require punting the packet, and may also make finding the L4 information harder.

Finally, I'm still not clear how exactly the signal should be interpreted next to other MTU mechanisms - if only a small number of devices actually implement and process this, it doesn't really remove the need for other mechanisms, and the performance hit for enabling it (and having HbH containing packets dropped) seems like it would likely outweigh the gains.

With all of that said, this *is* Experimental, and does mention many of my concerns. It also talks about applicability in "environments where there is control over the hosts and nodes that connect them", and so where operators may be willing to enable this because they know what sort of traffic exists. In addition, it's entirely possible that I'm wrong (I often am), and that this experiment will turn out to be wildly successful, and soon almost every router will do this -- and, if so, I'll be really happy!

In summary, I'm Abstaining, knowing that the document will progress, and hoping that it will be successful; ultimately, like most Abstains, it is a virtue-signaling no-op.

[Ballot comment]
Thank you for the work on this document.

Many thanks to Bernard Aboba for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/Xo9yYxkzEBBDQnEhFvhnnHm-e5M/ , and thanks to the authors for replying to him.

I wonder if it wouldn't be useful to have the diagrams the authors have sketched up (in https://mailarchive.ietf.org/arch/msg/art/HKwq8_wLbwXU6iS9ahLBoVcI6Mc/) in an appendix of the document - that might require some additional descriptive text around them, but I think they would be helpful.

Francesca

[Ballot comment]
While experimentation is good, I also share the concerns voiced by Bernard Aboba (https://datatracker.ietf.org/doc/review-ietf-6man-mtu-option-13-artart-lc-aboba-2022-03-09/) that this experiment repeats the failure of RFC 1063

  If the MTU of the link is less than the Min-PMTU,
  it rewrites the value in the option data with the smaller value.

Wouldn't this mean that what is stored is the maximum path mtu, not the minimum one?

It would be good to mention IPsec (both ESP transport mode whether the option is not (?) expected to work, and for ESP tunnel mode, where the option in the encapsulated packet could set to take into account the IPsec overhead for both ESP and possible ESPinUDP. Or the outer ESP packet could set the option after some header calculations.

    The use of this option with DNS and DNSSEC over UDP

DNS already has its application layer options to deal with MTU via an EDNS option. Although it could possibly read value from the network packet and use that in its ENDS option answer, it is not sure if this is worth the risk of abuse, where amplification attacks are common. If this experiment is not widely deployed, it could mean that excessive large values would actually make it to the DNS server, so using those values could be damaging especially if the packet was spoofed and the large packets are returned to the real victim.

I am not sure how TLS or IPsec could protect this option, as it is required to be modified on-path ?

  When a forged packet causes a packet to be sent including the minimum
  Path MTU option, and the return path does not forward packets with
  this option, the packet will be dropped Section 6.3.6.  This attack
  is mitigated [...]

Isn't dropping the spoofed packet mitigation enough?

[Ballot discuss]
Alvaro and Zahed pointed out concerns about the SHOULDs in Sections 6.1 and 6.2, and since all three of us tripped on the same text, I'd like to discuss them.  My own angle is that they're SHOULDs but it's not clear to me why they aren't MUSTs.  SHOULD offers the implementer a choice; if we're sure these need to be SHOULDs, then what advice might we provide to implementers that think they have legitimate reasons not to do what they say?

For instance, if I'm coding a router that understands HBH but is configured not to honor this option, why might I not ignore the option and forward the packet?

[Ballot comment]
In Sections 1 and 2, you refer to "this draft", e.g.:

  The purpose of this draft is to improve the situation ...

When published, this won't be a draft.  I suggest changing both to "document".

[Ballot comment]
Thank you to Charlie Kaufman for the SECDIR

** Recommend consistent language on validating again off-path injection.

Both sections first make this statement:
  An upper layer protocol that validates each received
  packet discards any packet when this validation fails. 

(a) Section 6.3.2. 
  When packet validation fails, the upper layer MUST
  also discard the associated Option Data from the minimum Path MTU
  option without further processing.

(b) Section 8.3
  In this case,
  the host MUST also discard the associated Option Data from the
  minimum Path MTU option without further processing (Section 6.3).

Why does (b) use “host” and not “upper layer”?

** Section 1.1.  Figure 1 is a helpful summary.  Consider including another scenario or additional text which involves a middlebox dropping the packet or stripping the option per the behavior in Section 6.3.6 and 8.6

** Section 6.3.6
  There is evidence that some middleboxes drop packets that include
  Hop-by-Hop options.  For example, a firewall might drop a packet that
  carries an unknown extension header or option.  This practice is
  expected to decrease as an option becomes more widely used. 

Is there a reference that can be used to support this optimism of middle-box operators changing their current practice? I was under the impression that this remains a prevalent practice and the motivation for draft-ietf-opsec-ipv6-eh-filtering.

** Section 9.  Thank you for being explicit on the experiment goals on this experimental document!  Would another component contributing to a successful experiment be operators not filtering this traffic?

[Ballot comment]
Thank you to Charlie Kaufman for the SECDIR

** Recommend consistent language on validating again off-path injection.

Both sections first make this statement:
  An upper layer protocol that validates each received
  packet discards any packet when this validation fails. 

(a) Section 6.3.2. 
  When packet validation fails, the upper layer MUST
  also discard the associated Option Data from the minimum Path MTU
  option without further processing.

(b) Section 8.3
  In this case,
  the host MUST also discard the associated Option Data from the
  minimum Path MTU option without further processing (Section 6.3).

Why does (b) use “host” and not “upper layer”?

** Section 1.1.  Figure 1 is a helpful summary.  Consider including another scenario or additional text which involves a middlebox dropping the packet or stripping the option per the behavior in Section 6.3.6 and 8.6

** Section 6.3.6
  There is evidence that some middleboxes drop packets that include
  Hop-by-Hop options.  For example, a firewall might drop a packet that
  carries an unknown extension header or option.  This practice is
  expected to decrease as an option becomes more widely used. 

Is there a reference that can be used to support this optimism of middle-box operators changing their current practice? I was under the impression that this remains a prevalent practice and the motivation for draft-ietf-opsec-ipv6-eh-filtering.

** Section 9.  Thank you for being explicit on the experiment goals on this experimental document!  Would another component contributing to the success would be operators not filtering this traffic?

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

[Ballot 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)?.

[Ballot comment]
Section 5. , paragraph 9, comment:
>      Min-PMTU: n 16-bits.  The minimum MTU recorded along the path
>                  in octets, reflecting the smallest link MTU that
>                  the packet experienced along the path.
>                  A value less than the IPv6 minimum link
>                  MTU [RFC8200] MUST be ignored.

Would there be any value in using a scheme that can encode MTUs larger than
64K? Could steal some bits by not defining a way to encode values below 1280.

Thanks to Paul Kyzivat for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/cSJ1VnpREVnAknRj_ANN0QFRdA0).

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2. , paragraph 3, nit:
-    This results in many transport connections being configured to use
+    This results in many transport-layer connections being configured to use
+                                  ++++++

Section 2. , paragraph 4, nit:
-    size available for a transport to use.  Also, some use-cases increase
+    size available for a transport protocol to use.  Also, some use-cases increase
+                                  +++++++++

Section 6.3. , paragraph 3, nit:
-    This avoids the transport needing to retransmit a lost packet that
+    This avoids the transport protocol needing to retransmit a lost packet that
+                            +++++++++

Section 6.3.1. , paragraph 10, nit:
-    *  A datagram transport can utilise DPLPMTUD [RFC8899].  For example,
-                                    ^
+    *  A datagram transport can utilize DPLPMTUD [RFC8899].  For example,
+                                    ^

Section 6.3.4. , paragraph 4, nit:
-    *  The actual PMTU may be lower than the Rtn-PMTU value because the
-                                                                  ----

Reference [RFC2460] to RFC2460, which was obsoleted by RFC8200 (this may be on
purpose).

Reference [RFC1063] to RFC1063, which was obsoleted by RFC1191 (this may be on
purpose).

Section 4. , paragraph 3, nit:
> IANA-HBH]. Length: 4 The size of the each value field in Option Data field su
>                                  ^^^^^^^^
Two determiners in a row. Choose either "the" or "each".

Section 6.2. , paragraph 2, nit:
> acket with this option in response to a R-flag, as well as which packets to i
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 8.4. , paragraph 4, nit:
>  mitigate the impact by responding to a R-Flag by including the option in a p
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

[Ballot comment]
I'm supportive of trying to solve the MTU problem and there seems to be no harm in trying this experiment, although I'm somewhat doubtful as to how many vendors will implement this functionality and how many operators will configure/enable it ... perhaps the IETF should try and write a BCP that recommends that interfaces carrying internet traffic support an IPv6 MTU of 9000 (if that is indeed the right thing to do).

Regards,
Rob

[Ballot comment]
This is good work on a thorny problem, and I hope the experiment is successful.

Throughout this document, there are SHOULD requirements that ought to have some language about the correct conditions under which to ignore the SHOULD.

(6.3) this is threatened not only by "loss of the packet", but also loss of the packet sent in response.

(8.3) packet validation in itself still leaves the mechanism vulnerable to replay attacks; the packet also must be non-duplicate.

[Ballot comment]
Thank you for the work put into this document. I am all in favour of extending IPv6 with extension headers, and any system to improve path MTU detection is helpful (esp. in data center at the beginning).

Let me also apologise to Bob, Gorry, and the 6MAN WG as I could have sent those comments during the WGLC...

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Ole Trøan for the shepherd's write-up including the justification for the intended status as experimental. You may also expect a INT directorate review by David Lamparter later.

I hope that this helps to improve the document,

Regards,

-éric

What about multicast traffic ? Can this HbH option be used ? How can several answers be combined ? As the intended status is "experimental", this is not blocking but close to be a DISCUSS-level point though.

## Abstract

Just wondering whether "node" should be used instead of "host" in "along the forward path between a source host to a destination host" (also in other places in other sections). Of course, nothing prevent a router to act as a host. §9 uses "node" and not "host" ;-)

## Section 1.2

Suggest removing the note about RFC 2460 as 8200 has been published for years now.

Even if mostly obvious, please expand "HBH" at first use.

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

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 ?

Is the "Discussion" part still relevant at this stage (IESG evaluation) ? Or should it be moved to the "experiment success evaluation" part ?

Can the router apply sampling/rate limiting on those packets ?

## 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" ?

If it was not an experimental document, I would probably have raised a blocking DISCUSS (sorry Bob & Gorry), usually ECMP is done on the 5-tuple, so using different layer-4 ports could end up in slightly different paths with different MTU (section 5.2 of RFC 8201 is a little better, recommend referring to it ? -- it is only referred to in § 6.3.4).

Please expand "PL"

"When requested to send an IPv6 packet" how ? and who request such an action ? My major concern is whether it is a per packet or per "connection" request as using a 8-byte MTU in a data packet actually reduces the useful MTU by 8 bytes. A forward reference to §6.3.1 would be beneficial.

Bullet #3, it is unclear what "This" means.

## Section 6.3

"Using a PMTU Probe" is it the HbH option described in this document ? If so, then propose being clear or introduce the synonym earlier in the text.

## Section 6.3.2

Just wondering how different this method is wrt to ICMP-based PMTUD as the 5-tuple must also be present (albeit no data).

Also wondering how an upper-layer protocol (possibly QUIC in user space) could signal to the PMTU cache (possibly in the kernel) to ignore a value. But, hey this is all about experimenting ;-) And § 6.3.3 is going in more details about where this data could be stored.

## Section 6.3.4

Why not a "MUST" in "A source host SHOULD ignore a Rtn-PMTU value larger than the MTU configured for the outgoing link." ?

# NITS 

## Section 1.1

In scenario 2, s/considers the link to the destination host/considers the link between R2 and the destination host/ ?

## Section 2

s/977K packets per second (pps)/977,000 packets per second (or 997 kpps)/

## Section 6.3.4

s/layer 2 device/layer-2 device/

## Section 8.1

s/Hop by Hop/Hop-by-Hop/

[Ballot comment]
Thank you for the work put into this document. I am all in favour of extending IPv6 with extension headers, and any system to improve path MTU detection is helpful (esp. in data center at the beginning).

Let me also apologise to Bob, Gorry, and the 6MAN WG as I could have sent those comments during the WGLC...

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Ole Trøan for the shepherd's write-up including the justification for the intended status as experimental.

I hope that this helps to improve the document,

Regards,

-éric

What about multicast traffic ? Can this HbH option be used ? How can several answers be combined ? As the intended status is "experimental", this is not blocking but close to be a DISCUSS-level point though.

## Abstract

Just wondering whether "node" should be used instead of "host" in "along the forward path between a source host to a destination host" (also in other places in other sections). Of course, nothing prevent a router to act as a host. §9 uses "node" and not "host" ;-)

## Section 1.2

Suggest removing the note about RFC 2460 as 8200 has been published for years now.

Even if mostly obvious, please expand "HBH" at first use.

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

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 ?

Is the "Discussion" part still relevant at this stage (IESG evaluation) ? Or should it be moved to the "experiment success evaluation" part ?

Can the router apply sampling/rate limiting on those packets ?

## 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" ?

If it was not an experimental document, I would probably have raised a blocking DISCUSS (sorry Bob & Gorry), usually ECMP is done on the 5-tuple, so using different layer-4 ports could end up in slightly different paths with different MTU (section 5.2 of RFC 8201 is a little better, recommend referring to it ? -- it is only referred to in § 6.3.4).

Please expand "PL"

"When requested to send an IPv6 packet" how ? and who request such an action ? My major concern is whether it is a per packet or per "connection" request as using a 8-byte MTU in a data packet actually reduces the useful MTU by 8 bytes. A forward reference to §6.3.1 would be beneficial.

Bullet #3, it is unclear what "This" means.

## Section 6.3

"Using a PMTU Probe" is it the HbH option described in this document ? If so, then propose being clear or introduce the synonym earlier in the text.

## Section 6.3.2

Just wondering how different this method is wrt to ICMP-based PMTUD as the 5-tuple must also be present (albeit no data).

Also wondering how an upper-layer protocol (possibly QUIC in user space) could signal to the PMTU cache (possibly in the kernel) to ignore a value. But, hey this is all about experimenting ;-) And § 6.3.3 is going in more details about where this data could be stored.

## Section 6.3.4

Why not a "MUST" in "A source host SHOULD ignore a Rtn-PMTU value larger than the MTU configured for the outgoing link." ?

# NITS 

## Section 1.1

In scenario 2, s/considers the link to the destination host/considers the link between R2 and the destination host/ ?

## Section 2

s/977K packets per second (pps)/977,000 packets per second (or 997 kpps)/

## Section 6.3.4

s/layer 2 device/layer-2 device/

## Section 8.1

s/Hop by Hop/Hop-by-Hop/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-6man-mtu-option-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Destination Options and Hop-by-Hop Options registry on the Internet Protocol Version 6 (IPv6) Parameters registry page located at:

https://www.iana.org/assignments/ipv6-parameters/

the temporary registration for

Hex Value: 0x30
act: 00
chg: 1
rest: 10000
Description: Path MTU Record Option

will be made permanent and its reference changed to [ RFC-to-be ].

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-02-10):

From: The IESG
To: IETF-Announce
CC: 6man-chairs@ietf.org, draft-ietf-6man-mtu-option@ietf.org, ek.ietf@gmail.com, ipv6@ietf.org, otroan@employees.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IPv6 Minimum Path MTU Hop-by-Hop Option) to Experimental RFC


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'IPv6 Minimum Path MTU Hop-by-Hop Option'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-02-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a new IPv6 Hop-by-Hop option that is used to
  record the minimum Path MTU along the forward path between a source
  host to a destination host.  The recorded value can then be
  communicated back to the source using the return Path MTU field in
  the option.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4567/

My apologies for the huge delay.

[S6.2.1; nit]

* "Sender sends probe" -> "Sender sends a probe"

[S6.2.1; question]

* In step (3), the sender sends a response with the R-Flag cleared if
  and only if the R-Flag was set on the Destination's reply, I presume.
  If true, this might be made more explicit; if not, I've misunderstood
  something.

[S6.2.2.4; comment]

* Another reason care might be needed when using the Rtn-PMTU value is
  that the set of routers constituting the path might have changed
  between when the probe was sent and when the Rtn-PMTU value might be
  used to send the next datagram.

  This is noted in 6.2.2.5, so in some ways its absence from the list
  here is easily noted.  It might go without saying that the path
  characteristics are not expected to change on the same time scale as
  typical RTTs (the time it would take a sender to learn the Rtn-PMTU),
  though.

[S8.3; comment/question]

* IPsec doesn't mitigate all forms of packet creation or alternation,
  and I suspect someone will want this explicitly acknowledged.

  Per 8200 S4.2 and RFC 4302 S3.3.3.1.2.2, for AH specifically "for any
  option whose data may change en route, its entire Option Data field must
  be treated as zero-valued octets when computing or verifying the
  packet's authenticating value."

  Thus, even something as annoying must kinda harmless as clearing the
  R-Flag won't be easily detectable.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

  Experimental.
  We could have justed proposed for PS. If it's an experiment then this experiment COULD be short-lived and
  successful if implemented and deployment experience  gained.
  The reasons why this is an experiment, is that although the mechanism itself might be simple:
  there are interactions between different layers needed to gain the benefit; 
  and implementations would be needed in the network as well as the host; and finally there
  could be changes needed in operational practice. That's something where a  little experience
  might cause us to be able to specify/guide more. We don't know what that would be at this moment.
  It would fail if no-one used it. At least in the transport area, we have tried to avoid
  predicting the future - even to predict the timescale over which an experiment with
  multiple parts might conclude. Although, if the WG later decides it fails, then the experiment
  will surely become historic.
  See also section 9 "Experiment Goals"

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document specifies a new IPv6 Hop-by-Hop option that is used to
  record the minimum Path MTU along the forward path between a source
  host to a destination host.  The recorded value can then be
  communicated back to the source using the return Path MTU field in
  the option.

Working Group Summary:

  This document is the product of the 6man working group. It is a part of the ongoing effort of improving path MTU discovery in the Internet.
  The mechanism described has been implemented as part of an IETF hackathon. It has undergone thorough review by multiple
  working group participants. It is experimental as described above.

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

  Making PMTUD work better is multi faceted and there are uncertainties in the WG regarding the deployability of this mechanism. That's also why it is experimental.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

  There are multiple prototype implementations of this mechanism as described in the implementation section of the draft.

Personnel:

  Document Shepherd: Ole Troan
  Responsible Area Director: Erik Kline

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

  The document shepherd has implemented the mechanism described in this document.
  The document shepherd has also reviewed the document in detail, both for language and technical issues over 3 iterations.
  This work is part of chair's experiment to see if a much more thorough review at the working group level correlates
  with fewer changes introduced by the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  No.
  This document has followed the 6MAN WG process with a WGLC to the list (28 responses) the volunteered
  reviewers (Matt Smith/Michael Dougherty) and three thorough chair's / document shepherd reviews.
  In addition Jen Linkova, Fernando Gont and Mark Smith has performed extensive reviews. See also
  section 12 in the document.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

  This document and mechanism was initiated from a collaboration between the 6man and the transport working group.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

  This is the first HBH option that can have Internet wide use(fullness). The WG has discussed at length if it is deployable.
  There is of course a feedback loop between a useful option with implementation and deployability / drop-rate in the Internet.
  There is significant uncertainty here, which is why we want to conduct this experiment.
  Can a notionally useful HBH option resolve the deadlock of Internet wide handling of HBH options?
  Secondarily can this option find a use within a limited domain?

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  Yes, confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

  Yes, there is an IPR filed.
  Apart from the chair making the working group aware of the IPR, there has been no discussion of the IPR claims.
  The WG does not believe it is in it's area to make conclusions about IPR claims.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

  The document has solid consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  There are no nits.
  The references to old documents are intentional.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  N/A

(13) Have all references within this document been identified as either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

  Confirmed.
  (The new HBH option described in the document has already a temporary allocation from IANA.)

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

  No new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

  N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

  N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

  Experimental.
  We could have justed proposed for PS. If it's an experiment then this experiment COULD be short-lived and
  successful if implemented and deployment experience  gained.
  The reasons why this is an experiment, is that although the mechanism itself might be simple:
  there are interactions between different layers needed to gain the benefit; 
  and implementations would be needed in the network as well as the host; and finally there
  could be changes needed in operational practice. That's something where a  little experience
  might cause us to be able to specify/guide more. We don't know what that would be at this moment.
  It would fail if no-one used it. At least in the transport area, we have tried to avoid
  predicting the future - even to predict the timescale over which an experiment with
  multiple parts might conclude. Although, if the WG later decides it fails, then the experiment
  will surely become historic.
  See also section 9 "Experiment Goals"

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document specifies a new IPv6 Hop-by-Hop option that is used to
  record the minimum Path MTU along the forward path between a source
  host to a destination host.  The recorded value can then be
  communicated back to the source using the return Path MTU field in
  the option.

Working Group Summary:

  This document is the product of the 6man working group. It is a part of the ongoing effort of improving path MTU discovery in the Internet.
  The mechanism described has been implemented as part of an IETF hackathon. It has undergone thorough review by multiple
  working group participants. It is experimental as described above.

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

  Making PMTUD work better is multi faceted and there are uncertainties in the WG regarding the deployability of this mechanism. That's also why it is experimental.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

  There are multiple prototype implementations of this mechanism as described in the implementation section of the draft.

Personnel:

  Document Shepherd: Ole Troan
  Responsible Area Director: Erik Kline

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

  The document shepherd has implemented the mechanism described in this document.
  The document shepherd has also reviewed the document in detail, both for language and technical issues over 3 iterations.
  This work is part of chair's experiment to see if a much more thorough review at the working group level correlates
  with fewer changes introduced by the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  No.
  This document has followed the 6MAN WG process with a WGLC to the list (28 responses) the volunteered
  reviewers (Matt Smith/Michael Dougherty) and three thorough chair's / document shepherd reviews.
  In addition Jen Linkova, Fernando Gont and Mark Smith has performed extensive reviews. See also
  section 12 in the document.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

  This document and mechanism was initiated from a collaboration between the 6man and the transport working group.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

  This is the first HBH option that can have Internet wide use(fullness). The WG has discussed at length if it is deployable.
  There is of course a feedback loop between a useful option with implementation and deployability / drop-rate in the Internet.
  There is significant uncertainty here, which is why we want to conduct this experiment.
  Can a notionally useful HBH option resolve the deadlock of Internet wide handling of HBH options?
  Secondarily can this option find a use within a limited domain?

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  Yes, confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

  Yes, there is an IPR filed.
  Apart from the chair making the working group aware of the IPR, there has been no discussion of the IPR claims.
  The WG does not believe it is in it's area to make conclusions about IPR claims.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

  The document has solid consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  There are no nits.
  The references to old documents are intentional.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  N/A

(13) Have all references within this document been identified as either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

  Confirmed.
  (The new HBH option described in the document has already a temporary allocation from IANA.)

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

  No new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

  N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

  N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

  Experimental.
  We could have justed proposed for PS. If it's an experiment then this experiment COULD be short-lived and
  successful if implemented and deployment experience  gained.
  The reasons why this is an experiment, is that although the mechanism itself might be simple:
  there are interactions between different layers needed to gain the benefit; 
  and implementations would be needed in the network as well as the host; and finally there
  could be changes needed in operational practice. That's something where a  little experience
  might cause us to be able to specify/guide more. We don't know what that would be at this moment.
  It would fail if no-one used it. At least in the transport area, we have tried to avoid
  predicting the future - even to predict the timescale over which an experiment with
  multiple parts might conclude. Although, if the WG later decides it fails, then the experiment
  will surely become historic.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document specifies a new IPv6 Hop-by-Hop option that is used to
  record the minimum Path MTU along the forward path between a source
  host to a destination host.  The recorded value can then be
  communicated back to the source using the return Path MTU field in
  the option.

Working Group Summary:

  This document is the product of the 6man working group. It is a part of the ongoing effort of improving path MTU discovery in the Internet.
  The mechanism described has been implemented as part of an IETF hackathon. It has undergone thorough review by multiple
  working group participants. It is experimental as described above.

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

  Making PMTUD work better is multi faceted and there are uncertainties in the WG regarding the deployability of this mechanism. That's also why it is experimental.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

  There are multiple prototype implementations of this mechanism as described in the implementation section of the draft.

Personnel:

  Document Shepherd: Ole Troan
  Responsible Area Director: Erik Kline

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

  The document shepherd has implemented the mechanism described in this document.
  The document shepherd has also reviewed the document in detail, both for language and technical issues over 3 iterations.
  This work is part of chair's experiment to see if a much more thorough review at the working group level correlates
  with fewer changes introduced by the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  No.
  This document has followed the 6MAN WG process with a WGLC to the list (28 responses) the volunteered
  reviewers (Matt Smith/Michael Dougherty) and three thorough chair's / document shepherd reviews.
  In addition Jen Linkova, Fernando Gont and Mark Smith has performed extensive reviews. See also
  section 12 in the document.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

  This document and mechanism was initiated from a collaboration between the 6man and the transport working group.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

  This is the first HBH option that can have Internet wide use(fullness). The WG has discussed at length if it is deployable.
  There is of course a feedback loop between a useful option with implementation and deployability / drop-rate in the Internet.
  There is significant uncertainty here, which is why we want to conduct this experiment.
  Can a notionally useful HBH option resolve the deadlock of Internet wide handling of HBH options?
  Secondarily can this option find a use within a limited domain?

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  Yes, confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

  Yes, there is an IPR filed.
  Apart from the chair making the working group aware of the IPR, there has been no discussion of the IPR claims.
  The WG does not believe it is in it's area to make conclusions about IPR claims.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

  The document has solid consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  There are no nits.
  The references to old documents are intentional.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  N/A

(13) Have all references within this document been identified as either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

  Confirmed.
  (The new HBH option described in the document has already a temporary allocation from IANA.)

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

  No new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

  N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

  N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.
We could have justed proposed for PS. If it's an experiment then this experiment COULD be short-lived and successful if implemented and deployment experience gained.
The reasons why this is an experiment, is that although the mechanism itself might be simple: there are interactions between different layers are needed to gain the benefit; and implementations would be needed in the network as well as the host; and finally there could be changes needed in operational practice. That's something where a little experience might cause us to be able to specify/guide more. We don't know what that would be at this moment.
It would fail if no-one used it. At least in the transport area, we have tried to avoid predicting the future - even to predict the timescale over which an experiment with multiple parts might conclude. Although, if the WG later decides it fails, then the experiment will surely become historic!

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document specifies a new IPv6 Hop-by-Hop option that is used to
  record the minimum Path MTU along the forward path between a source
  host to a destination host.  The recorded value can then be
  communicated back to the source using the return Path MTU field in
  the option.

Working Group Summary:



Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Ole Troan
Responsible Area Director: Erik Kline

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.
This document has followed the 6MAN WG process with a WGLC to the list (28 responses) the volunteered reviewers (Matt Smith/Michael Dougherty) and three thorough chair's / document shepherd reviews.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

This is the first HBH option that can have Internet wide use(fullness). The WG has discussed at length if it is deployable. There is of course a feedback loop between a useful option with implementation and deployability / drop-rate in the Internet. There is significant uncertainty here, which is why we want to conduct this experiment. Can a notionally useful HBH option resolve the deadlock of Internet wide handling of HBH options? Secondarily can this option find a use within a limited domain?

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes, there is an IPR filed.
Apart from the chair making the working group aware of the IPR, there has been no discussion of the IPR claims.
The WG does not believe it is in it's area to make conclusions about IPR claims.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document has solid consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are no nits.
The references to old documents are intentional.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Confirmed.
(The new HBH option described in the document has already a temporary allocation from IANA.)

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

We could have justed proposed for PS. If it's an experiment then this experiment COULD be short-lived and successful if implemented and deployment experience gained.

The reasons why this is an experiment, to me, is that although the mechanism itself might be simple: there are interactions between different layers are needed to gain the benefit; and implementations would be needed in the network as well as the host; and finally there could be changes needed in operational practice. That's something where I could anticipate a little experience might cause us to be able to specify/guide more. I don't know what that would be at this moment.

It would fail if no-one used it. At least in the transport area, we have tried to avoid predicting the future - even to predict the timescale over which an experiment with multiple parts might conclude. Although, if the WG later decides it fails, then the experiment will surely become historic!

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Ole Troan
Responsible Area Director: Erik Kline

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.
This document has followed the 6MAN WG process with a WGLC to the list (28 responses) a volunteered reviewer (Matt Smith) and a thorough chair's / document shepherd review.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

This is the first HBH option that can have Internet wide use(fullness). The WG has certainly discussed at length if it is deployable. There is of course a feedback loop between a useful option with implementation and deployability / drop-rate in the Internet. There is significant uncertainty here, which is why we want to conduct this experiment. Can a notionally useful HBH option resolve the deadlock of Internet wide handling of HBH options? Secondarily can this option find a use within a limited domain?

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?