Spencer Dawkins' No Objection on draft-ietf-6man-rfc6434-bis-08: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-6man-rfc6434-bis-08: 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-rfc6434-bis/



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

Thanks for doing this update. I have some comments, but the only one that's
more than editorial is on RFC 8311.

Do the right thing, of course.

I'm not understanding

  A host MAY limit the number of consecutive PAD1 options in
   destination options or hop-by-hop options to seven.  In this case, if
   the more than seven consecutive PAD1 options are present the packet
   should be silently discarded.  The rationale is that if padding of
   eight or more bytes is required than the PADN option should be used.

Isn't this saying that a path might work, or might fail silently, or might work
even if the packet should have been discarded (I note the lower-case "should",
without a reference to RFC 8174, which doesn't help)? It seems like "MAY limit"
is significantly more permissive than "should be silently discarded", turning
Jon Postel's Robustness Principle on its head. I'd either expect "SHOULD limit"
or "may/MAY be silently discarded", for starters.

I'm sure that's for a good reason, but perhaps it's worth explaining it in the
text. And I have the same confusion about

  A host MAY disallow unknown options in destination options or hop-by-
   hop options.  This should be configurable where the default is to
   accept unknown options and process them per [RFC8200].  If a packet
   with unknown options is received and the host is configured to
   disallow them, then the packet should be silently discarded.

A nit: "optines" for "options".

A nit: "resliency" for "resiliency".

I'm not sure that RFC 4821 would qualify as an extension to RFC 8201 in this
text - the functionality is similar, but the mechanism is different by design.

  An extension to Path MTU Discovery defined in RFC 8201 can be found
   in [RFC4821], which defines a method for Packetization Layer Path MTU
   Discovery (PLPMTUD) designed for use over paths where delivery of
   ICMPv6 messages to a host is not assured.

Perhaps "An alternative to Path MTU Discovery defined in RFC 8201 can be found
   in [RFC4821] ... "?

Thanks for including the reference to RFC 8311 in this text.

  Nodes that may be deployed in environments where they would benefit
   from such early congestion notification SHOULD implement [RFC3168].
   In such cases, the updates presented in [RFC8311] may also be
   relevant.

It may not be possible to do anything about this, but "may also be relevant"
seems weaker than I would have hoped. We were able to reclaim ECT(1) for
experimentation because we couldn't find more than a trace of evidence that
anyone on the Internet was using it, and this text doesn't quite discourage
someone from starting to use it now, which would prevent us from doing ECN
experiments. But do the right thing, of course.

This text

   Thus it is possible for 3rd
   party devices such nodes communicate with to track the activities of
   the node as it moves around the network.

wasn't easy for me to parse. Perhaps something like

   Thus it is possible for 3rd
   party devices to track the activities of a node they
   communicate with, as that node moves around the network.

would be clearer?

"Recently" may have been overtaken by events in this text.

  Recently, additional work has been done to support mobility in mixed-
   mode IPv4 and IPv6 networks [RFC5555].

I think

  If an IPv6 node is concerned about the impact of IPv6 message power
   consumption, it SHOULD want to implement the recommendations in
   [RFC7772].

might be clearer as

  If IPv6 implementers are concerned about the impact of IPv6 message power
   consumption in an IPv6 node, they SHOULD implement the recommendations in
   [RFC7772].