Last Call Review of draft-ietf-6man-rfc4291bis-07

Request Review of draft-ietf-6man-rfc4291bis
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-03-01
Requested 2017-02-01
Authors Bob Hinden, Steve Deering
Draft last updated 2017-02-13
Completed reviews Intdir Early review of -06 by Brian Haberman (diff)
Secdir Last Call review of -07 by Rich Salz (diff)
Genart Last Call review of -07 by Robert Sparks (diff)
Opsdir Last Call review of -07 by Menachem Dodge (diff)
Rtgdir Last Call review of -07 by John Drake (diff)
Assignment Reviewer Robert Sparks
State Completed
Review review-ietf-6man-rfc4291bis-07-genart-lc-sparks-2017-02-13
Reviewed rev. 07 (document currently at 09)
Review result Ready with Nits
Review completed: 2017-02-13


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


Document: draft-ietf-6man-rfc4291bis-07
Reviewer: Robert Sparks
Review Date: 2017-02-13
IETF LC End Date: 2017-03-01
IESG Telechat date: 2017-03-02


I have three small points for the group to consider:

1) In editing for this bis document, one bit of text was lost. 
RFC4291 said this in its section 2.4.5:
"Global Unicast addresses that start with
 binary 000 have no such constraint on the size or structure of the
 interface ID field."
Without it, the various places remaining the the document that say
things like "except those that start with the binary value 0000"
such as that appearing in section 2.4 of _this_ document leave
the reason behind the exception a mystery.

2) At the point in the text where the modified EUI-64 format interface
identifier text was moved to the appendix, this document notes that 
these derived interface identifiers are no longer recommended (end of
2.4.1). Consider repeating that at the first line of the new Appendix A.

3) Appendix B looks like something groups normally ask the RFC Editor to
delete. If that was your intent, please add instructions to the RFC Editor
so they don't have to ask. If you planned to leave it, a summary of the
changes rather than a chronolog of what draft version changes were made
in would be much more useful to future readers. (Such a summary would
be welcome in any case.)