Telechat Review of draft-ietf-6man-ndpioiana-02
review-ietf-6man-ndpioiana-02-opsdir-telechat-morton-2018-02-05-00

Request Review of draft-ietf-6man-ndpioiana
Requested rev. no specific revision (document currently at 04)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2018-03-06
Requested 2018-02-05
Other Reviews Intdir Early review of -02 by Carlos Bernardos (diff)
Secdir Telechat review of -02 by Barry Leiba (diff)
Genart Telechat review of -02 by Dan Romascanu (diff)
Review State Completed
Reviewer Al Morton
Review review-ietf-6man-ndpioiana-02-opsdir-telechat-morton-2018-02-05
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/aWO25n9kiPekij7-EomGDpqTKqQ
Reviewed rev. 02 (document currently at 04)
Review result Has Nits
Draft last updated 2018-02-05
Review completed: 2018-02-05

Review
review-ietf-6man-ndpioiana-02-opsdir-telechat-morton-2018-02-05

IPv6 ND PIO Flags IANA considerations
draft-ietf-6man-ndpioiana-02

Reviewer: Al Morton
Review Result: Almost Ready/Has Nits

I have reviewed this document as part of the Operational directorate's 
ongoing effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving the operational aspects of the 
IETF drafts. Comments that are not addressed in last call may be included in AD reviews 
during the IESG review.  Document editors and WG chairs should treat these comments 
just like any other last call comments.

Summary:
Mobile IPv6 extends Neighbor Discovery to allow a router to advertise
its global address, by the addition of a single flag bit in the
format of a Prefix Information option for use in Router Advertisement
messages. RFC6275 modified the original RFC4861 Neighbor Discovery (ND) 
Prefix Information Option format, allocating a "Reserved1" bit to "R"
for this purpose, but did not establish an IANA registry to track such
extensions (and did not indicate this as an update of RFC4681, possibly
creating issues for further allocation of the "Reserved1" bits (note that
there are two Reserved fields in the Prefix Information Option, the other
is denoted "Reserved2"). 

This memo requests IANA to create a new registry that brings the 
extension of "Reserved1" bits under control, and therefore solves
a potential future Operations problem.

Suggestions in Section 4, IANA Considerations:

Usually, the reserved bits are indicated in the Registry:

       +---------------+---------------------------------+-----------+
       | RA Option Bit | Description                     | Reference |
       +---------------+---------------------------------+-----------+
       | 0             | L - On-link Flag                | [RFC4861] |
       | 1             | A - Autonomous Address          | [RFC4861] |
       |               |     Configuration Flag          |           |
       | 2             | R - Router Address Flag         | [RFC6275] |
       +---------------+---------------------------------+-----------+
|      | 3-7           | Reserved1                       | [RFC6275] |
       +---------------+---------------------------------+-----------+

                                 Figure 2

Also, it is useful to indicate the Registration Procedure in this section,
such as:

Registration Procedure(s)
    Standards Action or IESG Approval

(IANA will ask for this, and may ask for the explicit registry name, too)

Nits:
Updates: 4861  (and also 6275, by establishing the ND PIO Flag registry, right?)

Introduction: two explicit section references would have been helpful, such as 
https://tools.ietf.org/html/rfc4861#section-4.6.2
https://tools.ietf.org/html/rfc6275#section-7.2
as both are long RFCs.

regards,
Al