IANA Considerations for the IPv4 and IPv6 Router Alert Options
draft-manner-router-alert-iana-03

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'IANA Considerations for the IPv4 and 
         IPv6 Router Alert Option' to Proposed Standard 

The IESG has approved the following document:

- 'IANA Considerations for the IPv4 and IPv6 Router Alert Option '
   <draft-manner-router-alert-iana-04.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Jari Arkko.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-manner-router-alert-iana-04.txt

Technical Summary

   This document updates the IANA allocation rules and registry of IPv4
   and IPv6 Router Alert Option Values. It will also deprecate one of
   the values in the current IPv6 registry that seems to have been
   made in an error in RFC 3175.

Working Group Summary

   This was discussed on the INTAREA list. Questions to possible
   implementation effects were posted to 6MAN; from what we know
   today this will not affect implementations negatively.

Document Quality

   The document has been reviewed extensively.

Personnel

   There is no document shepherd. Jari Arkko is the sponsoring AD.

RFC Editor Note

   Please move [IANA-IPv6RAO] to be an informative reference.

Section 1., paragraph 4:
>    This document proposes updates to the IANA registry for managing IPv4
>    and IPv6 Router Alert Option Values, and proposes to remove one

  s/proposes updates to/updates/
  s/proposes to remove/removes/


Section 3., paragraph 1:
>    This section contains the proposed new procedures for managing IPv4

  s/proposed//


Section 3., paragraph 3:
>    This should not change, as there has been seen little

  s/This should not change/This document does not change this/
  s/has been seen/is/


Section 3.2., paragraph 1:
>    The registry for IPv6 Router Alert Option Values should continue to

  s/should continue/continues/


Section 3.2., paragraph 2:
>    In addition, the following value should be removed from the IANA

  s/should be removed/are removed/


Section 3.2., paragraph 5:
>    The following IPv6 RAO values should be made available for

  s/should be made/are made/

OLD:
   | 3        | Aggregated Reservation  | Aggregated Reservation       |
   |          | Nesting Level 3         | Nesting Level 0 [RFC3175]    |
   |          | [RFC3175]               |                              |
NEW:
   | 3        | Aggregated Reservation  | Aggregated Reservation       |
   |          | Nesting Level 3         | Nesting Level 0 [RFC3175](*) |
   |          | [RFC3175]               |                              |

OLD:
   Note (*): The entry in the above table for the IPv6 RAO Value of 35
   (Aggregated Reservation Nesting Level 32) has been marked due to an
   inconsistency in the text of [RFC3175], and that is consequently
   reflected in the IANA registry.  In that document the values 3-35
   (i.e. 33 values) are defined for nesting levels 0-31 (i.e. 32
   levels).

   It is unclear why nesting levels begin at 1 for IPv4 (described in
   section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of
   [RFC3175]).
NEW:
   Note (*): The entry in the above table for the IPv6 RAO Value of 35
   (Aggregated Reservation Nesting Level 32) has been marked due to an
   inconsistency in the text of [RFC3175], and that is consequently
   reflected in the IANA registry.  In that document the values 3-35
   (i.e. 33 values) are defined for nesting levels 0-31 (i.e. 32
   levels). Similarly, value 3 is duplicate, because aggregation
   level 0 means end-to-end signaling, and this already has an IPv6
   RAO value "1" assigned.

   Also note that nesting levels begin at 1 for IPv4 (described in
   section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of
   [RFC3175]).

   Section 3.2 of this document redefines these so that for IPv6,
   value 3 is no longer used and values 4-35 represent levels
   1-32. This removes the above inconsistencies.