(front posting for quicker reading)
I don't recall this being discussed in the IPv6 WG for a long
time, but if clarification of intent is needed, that's where
it should happen. RFC 2780 explicitly doesn't leave this in
IANA's hands. I agree that it affects the exact level of
prudence needed in prudent management of a namespace.
However, this was not a factor in the IESG discussion.
Brian
John C Klensin wrote:
--On Wednesday, 06 July, 2005 20:37 -0400 John Leslie
<john@xxxxxxx> wrote:
John C Klensin <john@xxxxxxx> wrote:
--On Wednesday, 06 July, 2005 17:28 +0200 Brian E Carpenter
<brc@xxxxxxxxxxxxxx> wrote:
[Robert Elz wrote:]
It isn't really that bad, the option with 17 in the low 5
bits and 0 in the upper 3 is a different option than the one
with 17 in the low 5 bits and 7 in the upper 3.
So, really there are 8 distint groups of 32 options each.
Well, that is not how I read the text in RFC 2460. It's
pretty clear to me that there are only 32 option codes and
that the other three bits don't extend the code space, but
rather they modify the meaning of the 32 basic options.
(e.g. the same option can have a hop-by-hop flavour and an
e2e flavour).
Please set aside, at least temporarily, the issues that got us
to this point. It seems to me that, if you and kre, both of
whom have considerable experience reading these sorts of
documents, can't agree on what 2460 means and how these bits
are to be interpreted, we have a really urgent need for some
clarification.
Can you get the appropriate AD to sign up for that job and get
it assigned to a WG as appropriate?
It's rare that I find myself disagreeing with John Klensin,
but in this case I must.
The clarification is already done, at:
http://www.iana.org/assignments/ipv6-parameters
Section 5b makes it clear that IANA considers Option Types to
be eight bits, and is assigning eight-bit values.
As a temporary policy, they are currently assigning unique
values in the 5-bit "rest" subfield.
We should consider IANA fully competent to interpret this
issue, and IMHO it would be wrong for IESG to ask anyone to
second-guess IANA here.
Well, we don't disagree about that, although I should have taken
the extra time to read IANA's interpretation and didn't do so,
for which I apologize.
However, IANA doesn't make these policies up -- they get them
from the IETF, generally with IESG signoff (here presumably on
the basis of the text in the IPv6 spec, which went through all
of the usual Last Call procedures). However, in the last week
or ten days, we have had at least two separate IESG members
claim that this really is a five-bit field, with those first
three bits being either irrelevant or qualifying (flavor)
modifiers as Brian suggests above.
So someone is confused. I am pleased that it appears to not be
IANA or the IPv6 WG. But, to the extent to which the IESG made
its decision on the assumption that the code space here was five
bits rather than some larger number (I suspect that, in
practice, the interpretations of the first three bits is such
that the entire 255 code points cannot be used), then it may be
appropriate to review both the decision itself and the question
of where that confusion came from. Independent of the other
flaws and issues in my I-D (as I have told others, I was serious
about its being posted as a focus for discussion -- there are
details in it with which I don't agree), this difference of
opinion is one of the reasons why it is important to be clear
which decisions are being made on an assumption of scarcity and
which are not influenced by that consideration.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf