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 17:37:54
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.

--
John Leslie <john(_at_)jlc(_dot_)net>

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf