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

[Bob Hinden <[e-mail]>]

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]