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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf