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

Robert Sparks <> Mon, 13 February 2017 21:08 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 69141129526; Mon, 13 Feb 2017 13:08:09 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Sparks <>
Subject: Review of draft-ietf-6man-rfc4291bis-07
X-Test-IDTracker: no
X-IETF-IDTracker: 6.43.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Mon, 13 Feb 2017 13:08:09 -0800
Archived-At: <>
X-Mailman-Version: 2.1.17
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Feb 2017 21:08:09 -0000

Reviewer: Robert Sparks
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


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

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