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. -- John Leslie <john@xxxxxxx> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf