Re: [Gen-art] Review of draft-ietf-6man-rfc2460bis-08

[Alissa Cooper <[e-mail]>]

Peter, thank you for your review! I have asked the authors/WG to consider your suggestions in my ballot.

Alissa

> On Mar 1, 2017, at 12:16 AM, Peter Yee <[e-mail]> wrote:
> 
> Reviewer: Peter Yee
> Review result: Ready with Nits
> 
> 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-6man-rfc2460bis-08
> Reviewer: Peter Yee
> Review Date: 2017-02-28
> IETF LC End Date: 2017-03-01
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready with nits.  This Internet-Draft is an update to RFC
> 2460, the specification for IPv6.  See the following note.
> 
> Note that I read this document in the context that it is an update of
> RFC 2460, primarily for the purpose of cleaning up minor items (things
> that to moved to other documents, for example) and addressing errata. 
> I did not do a top-to-bottom review of the document as though it were
> a wholly new work.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments: 
> 
> General:
> 
> For RFCs named outside of references (i.e., those that aren't found in
> square brackets), separate "RFC" from the following numbers with a
> space.  This is especially prevalent in Appendix B.
> 
>> From the mailing list discussion back in 2015, I can't determine if an
> actual decision was taken as to whether RFC 2119 recommended/expected
> language ought to be used in this document.  The discussion mentioned
> leaving the topic for IETF LC, but I can't even tell if there was
> consensus to do that.  This document does not use RFC 2119 language
> primarily because it is minor update to RFC 2460, which itself did not
> use RFC 2119 language.  There was a healthy debate on the mailing list
> and I feel it came down mostly on the side of using RFC 2119, but
> again no consensus was obvious, just a preponderance of opinions.  The
> thread starts here:
> https://www.ietf.org/mail-archive/web/ipv6/current/msg23284.html
> 
> Change all uses of "en-route" to "en route".  Usage is mixed in the
> document, but en-route is never used before a noun and as a borrowed
> word from French would arguably not even be hyphenated had it appeared
> before a noun.  We won't even get into italicizing it. ;-)
> 
> Change all uses of "behaviour" to "behavior".  Although both British
> and American English are permissible, it seems preferable that only
> form be used in any particular document.  Given so many other
> Americanized spellings in the document, I'm recommending going with
> American English in this case.
> 
> Specific:
> 
> Page 20, 5th bullet item, 2nd paragraph, 2nd sentence: delete "an"
> before "overlapping".
> 
> Page 22, Section 4.8, 1st paragraph, append a comma after "because".
> 
> Page 23, 1st partial paragraph, 1st full sentence: insert "be" before
> "a".
> 
> Page 23, 1st full paragraph, 2nd sentence: insert "be" before "a".
> 
> Page 23, 2nd full paragraph: consider changing "need to" to "must". 
> (Ignoring any decision taken on RFC 2119 usage.)  I don't believe the
> "need to" at the top of this page needs to(!) change as it describing
> what designers need to do, not placing a restriction on a protocol
> element.
> 
> Page 23, Header Specific Data definition: change the comma to a
> period.
> 
> Page 26, 2nd bullet item, 1st sentence: delete the comma after
> "node".
> 
> Page 26, 3rd bullet item, 2nd sentence: change "use" to "Use" in the
> title of RFC 6936.
> 
> Page 29, Section 12.1, [I-D.ietf-6man-rfc4291bis] reference: update
> -06 to -07 to reflect the current version of that draft.
> 
> Page 34, Appendix B title: change to "Changes since RFC 2460".
> 
> Page 35, 1st 07) item: change "IPSEC" to "IPsec".
> 
> Page 39, 01) item: delete an extraneous space before "and".
>