Re: [Gen-art] Genart telechat review of draft-ietf-6man-rfc1981bis-06

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 <stewart.bryant@gmail.com> 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
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art