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".