[Int-area] FW: Protocol Action: 'IANA Considerations for the IPv4 and IPv6 Router Alert Option' to Proposed Standard

[Jari Arkko <[e-mail]>]

FYI:

> The IESG has approved the following document:
>
> - 'IANA Considerations for the IPv4 and IPv6 Router Alert Option '
>    <draft-manner-router-alert-iana-03.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-03.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.
>
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
>
>   

_______________________________________________
Int-area mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/int-area