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

[Bob Hinden <[e-mail]>]

Great!

Thanks,
Bob

> On Jan 26, 2017, at 12:30 PM, Bernie Volz (volz) <[e-mail]> wrote:
> 
> Hi Bob:
> 
> Your note would work well for me.
> 
> 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.
> 
> - Bernie
> 
> -----Original Message-----
> From: Bob Hinden [mailto:[e-mail]]
> Sent: Thursday, January 26, 2017 3:07 PM
> To: Bernie Volz (volz) <[e-mail]>
> Cc: Bob Hinden <[e-mail]>; Donald Eastlake <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review
> 
> Hi Bernie,
> 
> inline
> 
>> On Jan 25, 2017, at 3:15 PM, Bernie Volz (volz) <[e-mail]> wrote:
>> 
>> 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 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 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.
> 
> 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
> 
>> 
>> - Bernie
>> 
>> -----Original Message-----
>> From: Int-dir [mailto:[e-mail]] On Behalf Of Bob
>> Hinden
>> Sent: Wednesday, January 25, 2017 5:43 PM
>> To: Donald Eastlake <[e-mail]>
>> Cc: Bob Hinden <[e-mail]>;
>> [e-mail]; [e-mail]
>> Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review
>> 
>> 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 <[e-mail]> wrote:
>>> 
>>> 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.
>> 
>> See note above.
>> 
>>> 
>>> Section 4, Page 6, next to last paragraph of Section 4: "should" -> “SHOULD"
>> 
>> ditto
>> 
>>> 
>>> Section 5.1, Page 7, 2nd sentence of next to last paragraph of
>>> Section
>>> 5.1: delete superfluous comma
>> 
>> Thanks, will fix.
>> 
>>> 
>>> Section 5.2, Page 7: just a wording suggestion: "must in fact
>>> represent" -> “represents"
>> 
>> Makes sense to me, I will change.
>> 
>>> 
>>> 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.
>> 
>> While I tend to agree with you, I think this is a change we don’t have very much justification to make.
>> 
>>> 
>>> 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”
>>> 
>> 
>> I agree, thanks for catching this.  This makes it consistent with the earlier text in Section 4.
>> 
>> 
>>> 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”
>> 
>> Agree about MSS.
>> 
>>> 
>>> 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, will fix.
>> 
>>> 
>>> Thanks,
>>> Donald
>>> ===============================
>>> Donald E. Eastlake 3rd   [phone] (cell)
>>> 155 Beaver Street, Milford, MA 01757 USA [e-mail]
>> 
>> _______________________________________________
>> Int-dir mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-dir
>