Re: Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard

Jari Arkko <jari.arkko@piuha.net> Thu, 14 August 2008 16:07 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD1F3A6D42; Thu, 14 Aug 2008 09:07:12 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983533A6964 for <ietf@core3.amsl.com>; Thu, 14 Aug 2008 09:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.466
X-Spam-Level:
X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpY+LXgs+WR5 for <ietf@core3.amsl.com>; Thu, 14 Aug 2008 09:07:07 -0700 (PDT)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 6FE9028C153 for <ietf@ietf.org>; Thu, 14 Aug 2008 09:06:58 -0700 (PDT)
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 2D787198711; Thu, 14 Aug 2008 19:06:57 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id C1B3919867B; Thu, 14 Aug 2008 19:06:56 +0300 (EEST)
Message-ID: <48A45852.50806@piuha.net>
Date: Thu, 14 Aug 2008 19:07:46 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Jukka MJ Manner <jukka.manner@tkk.fi>
Subject: Re: Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard
References: <20080709164103.7733D28C1AF@core3.amsl.com> <16793.1215706092@epsilon.noi.kre.to> <0K5L00K10GREWD@smtp01.hut-mail> <48A449D7.2020004@tkk.fi>
In-Reply-To: <48A449D7.2020004@tkk.fi>
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: draft-manner-router-alert-iana@tools.ietf.org, ietf@ietf.org, Robert Elz <kre@munnari.OZ.AU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jukka,

> Both registries will use 32 values for the aggregation levels. For 
> IPv6 RAO, value 3 is removed but value 35 is kept. Thus, IPv6 will 
> have values 4-35 (=32 values) for the 32 levels.

OK

> We can make this more clear, yet, I already answered a question from 
> IANA about this a couple of weeks ago, so they are aware of how the 
> registry should be changed.
Which is good, but I was hoping the RFC itself would also be clear on 
this. How about this:

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 mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf