Re: Opsdir telechat review of draft-ietf-6man-ndpioiana-02

[Ole Troan <[e-mail]>]

Al,

Thank you for the review!
Inline.

> Reviewer: Al Morton
> Review result: Has Nits
> 
> 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] |
>       +---------------+---------------------------------+-----------+

Yes, that makes sense.


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

We already have text like that under figure 2:

   The assignment of new flags in the PIO option header require
   standards action.

   The registry for these flags should be added to:
   http://www.iana.org/assignments/icmpv6-parameters


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

Yes, I guess you could say that. Good to have the meta date anyway.

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

OK, will add.

Best regards,
Ole