ietf
[Top] [All Lists]

Re: What RFC 2460 means (was: Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment ofan IPV6 Hop-by-hop Option))

2005-07-06 18:20:57


--On Wednesday, 06 July, 2005 20:37 -0400 John Leslie
<john(_at_)jlc(_dot_)net> wrote:

John C Klensin <john(_at_)jck(_dot_)com> wrote:
--On Wednesday, 06 July, 2005 17:28 +0200 Brian E Carpenter
<brc(_at_)zurich(_dot_)ibm(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf