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