Last Call Review of draft-ietf-6man-rfc2460bis-08
review-ietf-6man-rfc2460bis-08-genart-lc-yee-2017-02-28-00

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