Genart telechat review of draft-ietf-6man-rfc1981bis-06

[Stewart Bryant <[e-mail]>]

Reviewer: Stewart Bryant
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-6man-rfc1981bis-??
Reviewer: Stewart Bryant
Review Date: 2017-04-24
IETF LC End Date: 2017-03-01
IESG Telechat date: 2017-05-11

Summary: This is can be published as is, but I think could be
improved.

I thank the authors you for dealing with most of my comments in the
previous round.
There are two unaddressed points that the IETF Chair may wish to
consider, and one
that I missed.

Major issues:
The text has a lot of RFC2119 language, but no RFC2119 declaration.
and the document seems inconsistent about when it uses RFC2119
language and
when it does not. This sends a mixed messages to authors if we are not

consistent on this point throughout the RFC Series.

=======

5.3.  Purging stale PMTU information

   Internetwork topology is dynamic; routes change over time.  While
the
   local representation of a path may remain constant, the actual
   path(s) in use may change.  Thus, PMTU information cached by a
node
   can become stale.

   If the stale PMTU value is too large, this will be discovered
almost
   immediately once a large enough packet is sent on the path.  No
such
   mechanism exists for realizing that a stale PMTU value is too
small,
   so an implementation should "age" cached values.  When a PMTU
value
   has not been decreased for a while (on the order of 10 minutes),
the
   PMTU estimate should be set to the MTU of the first-hop link, and
the
   packetization layers should be notified of the change.  This will
   cause the complete Path MTU Discovery process to take place again.

SB> I still worry that the impact of this advice is going to be a
disruption to what might
SB> be a critical service every 10 mins, and wonder if there should be
some advice along the 
SB> lines of noting the importance of service delivery as part of
deciding whether to
SB> test for bigger PMTU vs improving efficiency?

Minor issues:

 A node MUST NOT reduce its estimate of the Path MTU below the IPv6
 minimum link MTU.

SB> I missed this last time.
SB>
SB> Presumably you mean "A node MUST NOT reduce its estimate of the 
SB> Path MTU below the IPv6 minimum link MTU in response to such
SB> a message."
SB> 
SB> Otherwise I would have thought that this was entirely a matter 
SB> for the host whether it wanted to use a Path MTU below the IPv6 
SB> link minimum. Nothing breaks if the host takes a more conservative

SB> decision.
SB> 

Nits/editorial comments:  None.