Subject: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review

From: Donald Eastlake <[email-masked]>
Date: Wed, 25 Jan 2017 16:24:06 -0500

I am an assigned INT directorate reviewer for
draft-ietf-6man-rfc1981bis-03.txt. These comments were written
primarily for the benefit of the Internet Area Directors. Document
editors and shepherd(s) should treat these comments just like they
would treat comments from any other IETF contributors and resolve them
along with any other Last Call comments that have been received. For
more details on the INT Directorate, see
http://www.ietf.org/iesg/directorate.html.

This document appears to be Ready with Nits.

Add RFC 2119 to Reference and add corresponding boilerplate, probably
to the Terminology section.

Section 4, Page 6, next to last paragraph of Section 4: "should" -> "SHOULD"

Section 5.1, Page 7, 2nd sentence of next to last paragraph of Section
5.1: delete superfluous comma

Section 5.2, Page 7: just a wording suggestion: "must in fact
represent" -> "represents"

Section 5.2, Page 8: The indented Note about "security
classifications" strikes me as probably an archaism left over from
when it was the "US Department of Defense Internet". I suggest
replacing "security classifications" with "quality of service
markings" or the like. Security seems like one "quality" of service so
I believe the new wording I am suggesting is a superset of the old.

Section 5.2, Page 9: I am not entirely comfortable that earlier in the
document it says that a Packet Too Big reporting a next hop MTU less
than the IPv6 minimum link MTU should be discarded and that a node
MUST NOT reduce its estimate of the Path MTU below the IPv6 minimum
link MTU but in the top paragraph on page 9 it talks in an
unrestricted way about reducing the PMTU based on Packet Too Big
message next hop size. I suggest, at the top of page 9: "uses the
value in the MTU field in the Packet Too Big message as a tentative
PMTU" -> "uses the value in the MTU field in the Packet Too Big
message, or the minimum IPv6 next hop MTU if that is larger, as a
tentative PMTU"

Section 5.3, Page 10, right after the indented Note: "must not" -> "MUST NOT"

Section 5.4, Page 10: "should not" -> "SHOULD NOT"

Section 5.4, Page 11, 1st paragraph: Expand "MSS" on first use; "must
not" -> "MUST NOT"

Section 5.4, Page 11, indented Note: in 1st paragraph "must not" ->
"MUST NOT"; in 2nd paragraph "must" -> "MUST"

Section 5.5, Page 12, 1st paragraph: "should" -> "SHOULD"

Section 5.5, Page 12, 3rd paragraph: "recommended" -> "RECOMMENDED"

Section 5.5, Page 12, 4th paragraph: If some NFS operations cannot be
fragmented, "should not" -> "MUST NOT"

Appendix B, 2nd sentence: "version that the change was made.:" ->
"version where the change was made."

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Wed, 25 Jan 2017 14:42:35 -0800

Donald,

Thanks for your comments!

To set the background this, this is part of 6MAN work to advance the core IPv6 specs from Draft Standard to Internet Standard.  As part of this, we were only trying to change things that where there were RFCs that updated it, errata, and to make it consistent with the other RFCs being advanced (for example rfc2460bis and rfc4291bis). We were trying to change as little as possible.

That why we kept the must/should language intact and did not include a reference to RFC2119.  RFC1981 was, of course, written before RFC2119.  It uses a mix of upper and lower case words, I am am reluctant to try to change that.   This is also consistent with how the w.g. handled this issue with rfc2460bis and rfc4291bis.

Comments inline below.

Bob

> On Jan 25, 2017, at 1:24 PM, Donald Eastlake <[email-masked]> wrote:
> 

See note above.

> 
> Section 4, Page 6, next to last paragraph of Section 4: "should" -> “SHOULD"

ditto

> 5.1: delete superfluous comma

Thanks, will fix.

> represent" -> “represents"

Makes sense to me, I will change.

> I believe the new wording I am suggesting is a superset of the old.

While I tend to agree with you, I think this is a change we don’t have very much justification to make.

> tentative PMTU”

I agree, thanks for catching this.  This makes it consistent with the earlier text in Section 4.

> not" -> "MUST NOT”

Agree about MSS.

> "version where the change was made.”

Thanks, will fix.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 25 Jan 2017 23:15:36 +0000

Bob:

While it is great that you know this issue with RFC 2119 key words ... others reading this document when it becomes an RFC may not know that (and RFC8xxx or whatever it will be does not predate 2119) and even if the RFC 2119 reference isn't directly in the document, what will they assume (I mostly assume if I see MUST in an IETF document, it is a RFC 2119 key word)?

I would think that at a minimum, adding a note that this document does NOT make explicitly use of RFC 2119 key words and therefore how a reader interprets MUST vs must is up to them (presumable MUST is more of a must than the lower case version).

I think it might also be possible to argue that 2119 might have been on the horizon at the time and as it did not yet exist ... 02 of the 2119 draft (oldest available at tools.ietf.org) was published in August 1996 which is the same month in which 1981 was published. So seems likely that there is some influence from that work here?

I guess one conclusion is that even if not explicitly indicated, the assumption that they are (in the spirit of) 2119 key words is likely correct.

- Bernie

-----Original Message-----
From: Int-dir [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Wednesday, January 25, 2017 5:43 PM
To: Donald Eastlake <[email-masked]>
Cc: Bob Hinden <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review

Donald,

Comments inline below.

Bob

See note above.

ditto

Thanks, will fix.

Agree about MSS.

Thanks, will fix.

> 155 Beaver Street, Milford, MA 01757 USA [email-masked]

_______________________________________________
Int-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-dir

---

From: Bob Hinden <[email-masked]>
Date: Thu, 26 Jan 2017 12:06:38 -0800

Hi Bernie,

inline

> On Jan 25, 2017, at 3:15 PM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Bob:
> 

I don’t object to a note.  However, RFC2119 does not require upper case, so making statements about the precedence of upper vs. lower case it’s warranted.

How about something like this:

Note:  This document is an update to RFC1981 that was published prior to RFC2119 being published.  Consequently while it does use "should/must" style language in upper and lower case, the document does not cite the RFC2119 definitions.  This update does not change that.

I guess this means I will have to add a reference to RFC2119 :-)

> I guess one conclusion is that even if not explicitly indicated, the assumption that they are (in the spirit of) 2119 key words is likely correct.

I suspect that is true.  The reason why we didn’t cite RFC2119 in rfc1981bis, is that RFC1981 is very widely implemented using the current language, and starting to change the “must/should/etc.” to upper case, will likely cause some to think that this document is intended to change implementation behaviour.  That was not the intent of the w.g.  The changes in the bis document are very limited.

Thanks,
Bob

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 26 Jan 2017 20:30:48 +0000

Hi Bob:

Your note would work well for me.

- Bernie

-----Original Message-----
From: Bob Hinden [mailto:[email-masked]] 
Sent: Thursday, January 26, 2017 3:07 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Donald Eastlake <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review

Hi Bernie,

inline

Thanks,
Bob

> Cc: Bob Hinden <[email-masked]>; 
> [email-masked]; [email-masked]
>> would treat comments from any other IETF contributors and resolve 
>> them along with any other Last Call comments that have been received. 
>> For more details on the INT Directorate, see 
>> markings" or the like. Security seems like one "quality" of service 
>> so I believe the new wording I am suggesting is a superset of the old.
> 
>> Section 5.2, Page 9: I am not entirely comfortable that earlier in 
>> the document it says that a Packet Too Big reporting a next hop MTU 
>> less than the IPv6 minimum link MTU should be discarded and that a 
>> node MUST NOT reduce its estimate of the Path MTU below the IPv6 
>> minimum link MTU but in the top paragraph on page 9 it talks in an

---

From: Bob Hinden <[email-masked]>
Date: Thu, 26 Jan 2017 12:34:33 -0800

Great!

Thanks,
Bob

> On Jan 26, 2017, at 12:30 PM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Hi Bob:
>

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 26 Jan 2017 22:16:36 +0000

Hi Bob,

> On Jan 26, 2017, at 3:34 PM, Bob Hinden <[email-masked]> wrote:
> 
> Great!

A note in the shepherd writeup would have worked for me as well. The one concern I have is that if such text is added to this document, should it be added to 2460bis as well? 

Thanks
Suresh

---

From: Bob Hinden <[email-masked]>
Date: Thu, 26 Jan 2017 14:53:38 -0800

Suresh,

> On Jan 26, 2017, at 2:16 PM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Bob,
> 

That’s a good point.  I would also be fine with adding it to the writeup.

Your call.

Thanks,
Bob