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

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