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

[Jukka MJ Manner]

Got it, thanks.

Jukka

On Thu, 14 Aug 2008, Jari Arkko wrote:


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

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

[Jukka MJ Manner]

Hi,

About cutting most of the Security Considerations section, I don't 
personally have a preference, either is fine. Yet, I tend to agree with 
Jari that stating the obvious isn't such a big problem, it just reminds 
people that there are issues to consider. (Whether the use of an 
arbitrary RAO value kills routers, I don't know - if we ask router 
manufacturers surely they will not tell us. ;) )


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.


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.


Jukka

Jari Arkko wrote:

Kre, authors,


First (last sentence of section 2):

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

isn't the kind of sentence that belongs in a doc like this.   If the
authors are mystified, just omit the sentence, including it adds nothing.
Better, of course, would be to ask, and discover, and provide an
explanation.

But, this doc deletes aggregation level 0 from IPv6 anyway, which makes
all of this even stranger.
  


There has been an effort to determine why the values do not match and 
why there's 33 instead of 32 values. We still do not know. I think it is 
valuable to point out problems (like the 33 values) and the fact that 
implementations have to use different values for v4 and v6.


However, your question about level 0 deletion prompts me to ask the 
authors: given that you are doing this, does this restore both the 
alignment to both using the range 1-32 and exactly 32 values? Does that 
mean that in IPv6 the value 35 (3+32) is used? If yes, maybe that should 
be clearer from the doc. Or is the intent that IPv6 will use 1-31?



Second (section 4, security considerations):
  
It has been a long standing practice that we allocate experimental code 
points for different protocol fields.


I agree that the security considerations section is largely about common 
sense. I do not necessarily agree that the considerations can be 
removed, however. The fact of the matter is that experiments can collide 
and it may even be possible that some equipment has interesting failure 
modes when it sees previously untested values. Worth the two paragraphs? 
I'd rather err on the side of stating the obvious.


Jari


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf