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

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
>