Subject: Re: <draft-ietf-6man-rfc1981bis-05.txt>

From: Tim Chown <[email-masked]>
Date: Mon, 3 Apr 2017 11:20:43 +0000

Hi Bob,

These generally look good, a few comments in-line...

> On 31 Mar 2017, at 16:32, Bob Hinden <[email-masked]> wrote:
> 
> Hi,
> 
> I published a new version of rfc1981bis (-05).  Links to the document below.
> 
> The changes in this version are based on comments in IETF last call reviews by Gorry Fairhurst, Joe Touch, Susan Hares, Stewart Bryant, Rifaat Shekh-Yusef, and Donald Eastlake.  Many thank to the reviewers as I think the document is significantly improved, it is much better aligned with current transport practice.
> 
> The changes include:
> 
>   o  Clarify that the purpose of PMTUD is to reduce the need
>      for IPv6 Fragmentation.
> 
>   o  Added text to Introduction about effects on PMTUD when
>      ICMPv6 messages are blocked.

I think "are susceptible to loss if" should read “are susceptible to packet loss if” or perhaps "are susceptible to problematic connectivity if “

I notice that some text in RFC1981bis uses RFC2119-style MUST/SHOULD/etc text, but the document doesn’t include the 2119 “boilerplate”.  Should this be added?  And should the use of should/SHOULD, must/MUST, etc be reviewed through the document?

There’s a discrepancy between 1981bis and 2460bis on PMTUD implementation.  1981bis says SHOULD implement, 2460bis says implementation is “strongly recommended” - perhaps be consistent?

>   o  Clarified in Section 4. that nodes should validate the
>      payload of ICMPv6 PTB messages per RFC4443.
> 
>   o  Removed text in Section 5.2 about the number of paths to a
>      destination.
> 
>   o  Changed title of Section 5.4 to "Packetization layer
>      actions".
> 
>   o  Clarified first paragraph in Section 5.4 to to cover all
>      packetization layers, not just TCP.
> 
>   o  Clarified text in Section 5.4 to use normal retransmission
>      methods.
> 
>   o  Add clarification to Note in Section 5.4 about
>      retransmissions.
> 
>   o  Removed text in Section 5.4 that described 4.2BSD as it is
>      now obsolete.
> 
>   o  Removed reference to TP4 in Section 5.5.
> 
>   o  Updated text in Section 5.5 about NFS including adding a
>      current reference to NFS and removing obsolete text.
> 
>   o  Revised text in Section 6 to clarify first attack
>      response.
> 
>   o  Added new text in Section 6 to clarify the effect of
>      ICMPv6 filtering on PMTUD.

Perhaps reference RFC4890 here?

>   o  Aligned terminology for the packetization layer
>      terminology.
> 
>   o  Editorial changes.
> 
> A diff from the previous version can be found at:
> 
>   https://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc1981bis-05.txt
> 
> Please review.
> 
> This is part of the project to move the core IPv6 specifications to Internet Standard.

Best wishes,
Tim

> 
> Thanks,
> Bob
> 
>> A new version of I-D, draft-ietf-6man-rfc1981bis-05.txt
>> has been successfully submitted by Robert M. Hinden and posted to the
>> IETF repository.
>> 
>> Name:		draft-ietf-6man-rfc1981bis
>> Revision:	05
>> Title:		Path MTU Discovery for IP version 6
>> Document date:	2017-03-31
>> Group:		6man
>> Pages:		18
>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc1981bis-05.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-05
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc1981bis-05
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc1981bis-05
>> 
>> Abstract:
>>  This document describes Path MTU Discovery for IP version 6.  It is
>>  largely derived from RFC 1191, which describes Path MTU Discovery for
>>  IP version 4.  It obsoletes RFC1981.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Mon, 3 Apr 2017 12:54:03 -0700

Tim,

> On Apr 3, 2017, at 4:20 AM, Tim Chown <[email-masked]> wrote:
> 
> Hi Bob,
> 
> These generally look good, a few comments in-line…

Thanks.  Comments below.

Bob

> I think "are susceptible to loss if" should read “are susceptible to packet loss if” or perhaps "are susceptible to problematic connectivity if “

I prefer the latter.  I will hold that for the next update.

> I notice that some text in RFC1981bis uses RFC2119-style MUST/SHOULD/etc text, but the document doesn’t include the 2119 “boilerplate”.  Should this be added?  And should the use of should/SHOULD,…

That style was inherited from RFC1981, which was written before RFC2119.  I am hesitant to add RFC2119 and then have to do a review of all RFC2119 words and not break interoperability.

> There’s a discrepancy between 1981bis and 2460bis on PMTUD implementation.  1981bis says SHOULD implement, 2460bis says implementation is “strongly recommended” - perhaps be consistent?

SHOULD and “strongly recommended” are very close if not equivalent.

> Perhaps reference RFC4890 here?

Thanks.  I think that makes sense.