Subject: Re: Genart telechat review of draft-ietf-6man-rfc1981bis-06

From: Bob Hinden <[email-masked]>
Date: Fri, 5 May 2017 15:32:12 +0300

> On Apr 25, 2017, at 9:26 PM, Joe Touch <[email-masked]> wrote:
> 
> Hi, Stewart,
> 
> 
> On 4/24/2017 10:12 AM, Stewart Bryant wrote:
>> 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."
> This seems fine to me, FWIW - i.e., limiting the advice in this doc to
> the mechanism in  this doc.

I will add something, but this sentence follows:

   If a node receives a Packet Too Big message reporting a next-hop
   MTU that is less than the IPv6 minimum link MTU, it MUST discard it.

so I think the context was clear.

Bob

> 
>> 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.
> I don't agree; the host at that point is violating RFC2460. It should
> never think that an IPv6 link or path with an MTU below what RFC2460
> requires is valid.
> 
> Joe
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 5 May 2017 10:04:45 -0700

Hi, Bob,

AOK. Thanks,

Joe

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 10 May 2017 16:43:21 -0700

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-masked]> 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:
> 
> Nits/editorial comments:  None.
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art