--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