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