Adam Roach's No Objection on draft-ietf-6man-rfc1981bis-06: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-6man-rfc1981bis-06: 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-rfc1981bis/



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

I'd like to add my voice to the concerns expressed regarding RFC2119
language. I understand the desire to only deal with the changed parts of
the specification; but the current process as I understand it is that bis
versions of document are expected to be "brought up to code" according to
modern IETF document practices. Perhaps we should have a conversation
about whether that practice is in need of revising, but I'm not sure
making piecemeal exceptions is the best way to go about starting that
conversation. In any case, I believe that current practice is that new
RFCs cite 2119 and adhere to its definitions when using these specific
terms in all-caps; and that this will be published as a new RFC.

Minor technical comment: Like others, I also had a really hard time with
the paragraph in section 4 concluding with "MUST force the Path MTU
Discovery process to end." It's difficult to read this as anything
*other* than "you get one Path Too Big, and just shut down discovery,"
but that's clearly not what the rest of the document says. (I'll also
note that if we are treating capital "MUST" as normative, then "MUST
attempt to" is kind of meaningless).

Minor technical comment: Section 5.4 has three paragraphs, starting
"Alternatively, the retransmission could be done in immediate response to
a notification" that propose a more aggressive means of dealing with
packets lost to PMTU issues; most of this text is a warning about how
this can go awry and (if you'll excuse a bit of hyperbole) melt the
Internet. Given that the first alternative works just fine and appears to
be much safer, is this alternative actually something we want to
recommend for today's implementations?

The remainder of my comments are editorial.

The second-to-last paragraph of the introduction uses the phrase "such
messages" in a way that makes the antecedant difficult to find. I spent a
while trying to figure out how PMTUD used TCP three-way-handshakes or
blackholed TCP packets to determine PMTU. Suggest: "..relies on ICMPv6
messages to determine..."

The abbreviation "PTB" appears in the second paragraph of section 4. I
would ordinarily suggest expanding on first use; but as this is this
first and only use, I suggest simply replacing it with the long form used
in the rest of the document.

Section 5.1 introduces the term MMS_S, and relates it to EMTU_S. I note
that the former is not in the terminology section, while the latter is --
I suspect that they should both be present.

Section 5.2 uses the acronym "ECMP". I would suggest citing the related
document in which ECMP is defined and optionally expanding the acronym.

Section 5.2 indicates:

   Also, the instance that sent the packet that elicited the Packet Too
   Big message should be notified that its packet has been dropped,
even
   if the PMTU estimate has not changed, so that it may retransmit the
   dropped data.

It is quite nonintuitive how this situation could arise: if the packet is
of size X, and the PMTU has not changed, then it follows that X <= PMTU
(as the packet would have been reduced in size otherwise). If the PMTU
has not changed, it also follows that PMTU <= MTU (from the Packet Too
Big message). it follows that X <= MTU (from the Packet Too Big message),
and so it really should not have been dropped unless the corresponding
router has an implementation flaw of some kind. More importantly, it
would seem that an attempt to transmit another packet of size X at this
point would run an overwhelmingly high chance of triggering another
Packet Too Big for whatever errant reason caused the first one to be
sent.

I'm sure this naïve explanation overlooks whatever nonintuitive situation
is envisioned by this paragraph. It would be quite helpful if such a
situation were described: I, as an implementor, would look at this and
say "What? No. I'm not doing that. It's extra work for no benefit."

I suspect it will be dealt with by the RFC editor, but the first
normative reference seems to have some kind of issue with the production
of the authors' names.

I see several acknowledgements in section B.1 that will be removed prior
to publication. The authors may wish to consider moving these names to
section 7 for the sake of posterity.