Skip to main content

Telechat Review of draft-ietf-6man-rfc1981bis-06

Request Review of draft-ietf-6man-rfc1981bis
Requested revision No specific revision (document currently at 08)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-04-25
Requested 2017-04-07
Authors Jack McCann <>, Stephen E. Deering <>, Jeffrey Mogul <>, Bob Hinden
Draft last updated 2017-04-24
Completed reviews Intdir Early review of -03 by Donald E. Eastlake 3rd (diff)
Secdir Last Call review of -04 by Rifaat Shekh-Yusef (diff)
Genart Last Call review of -04 by Stewart Bryant (diff)
Opsdir Last Call review of -04 by Susan Hares (diff)
Tsvart Telechat review of -04 by Dr. Joseph D. Touch (diff)
Rtgdir Last Call review of -06 by Ines Robles (diff)
Secdir Telechat review of -06 by Rifaat Shekh-Yusef (diff)
Genart Telechat review of -06 by Stewart Bryant (diff)
Assignment Reviewer Stewart Bryant
State Completed
Review review-ietf-6man-rfc1981bis-06-genart-telechat-bryant-2017-04-24
Reviewed revision 06 (document currently at 08)
Result Ready with Issues
Completed 2017-04-24
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


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

Nits/editorial comments:  None.