Stewart, thank you for your review, and thanks all for your engagement with Stewart. Alvaro has proposed a resolution to the 2119 issue which seems satisfactory. I have ballotted no-objection.
Alissa > On Apr 24, 2017, at 10:12 AM, Stewart Bryant <[email protected]> wrote: > > 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. > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
