Subject: RE: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment ofan IPV6 Hop-by-hop Option)

From: "Christian Huitema" <[email-masked]>
Date: Tue, 5 Jul 2005 00:58:36 -0700

> I think as has already been suggested we are having two different
> discussions masquerade as one.  I obviously can't speak for Robert but
it
> seems to me he is not saying the IESG ought to approve every (or any)
> extension of IP, he is merely saying each should have an option number
> assigned.  Why assign a dangerous, harmful protocol an option?  For
the
> same
> reason sex offenders in the US have to register - so everyone can be
aware
> of their presence and take the appropriate precautions.

The problem is the really small size of the option type field in IPv6.
There really only are 5 bits available for numbering both the hop by hop
and the end to end options. That makes for a grand total of 32, of which
three are assigned by basic IPv6 specs. So, there really are good
reasons to be somewhat conservative with the assignments.

-- Christian Huitema

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 5 Jul 2005 07:02:11 -0500

Oh, great...

As Harald noted, draft-klensin-iana-reg-policy is pretty prescriptive 
about saying that if we're in conservation mode for a registry, we 
also need to be in evasive-action mode ("how do we get more room in 
this registry?").

If we are already in conservation mode on IPv6 options, given that it 
has taken quite some time to even get to the point that we're at with 
IPv6, the proposal in this draft seems entirely appropriate in the 
case under discussion.

>From the abstract:

     any assertions of scarcity to restrict registrations
   must be accompanied by a plan for eliminating the scarcity problem,
   and that, if such a plan is not possible, to establish criteria for
   making decisions that are as specific and objective as possible.

Spencer

From: "Christian Huitema" <[email-masked]>
Sent: Tuesday, July 05, 2005 2:58 AM

it
the
aware

The problem is the really small size of the option type field in IPv6.
There really only are 5 bits available for numbering both the hop by 
hop
and the end to end options. That makes for a grand total of 32, of 
which
three are assigned by basic IPv6 specs. So, there really are good
reasons to be somewhat conservative with the assignments.

-- Christian Huitema

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 5 Jul 2005 15:09:33 -0400

> IPv6, the proposal in this draft seems entirely appropriate in the 

Oh, great.  And so obviously, the IAB was right before the great Kobe
revolution, and we should have thrown out IP in favor of variable
length headers ala OSI so we can put in OID's everywhere, making it
hard to quickly and efficiently parse network headers in hardware.  

But at least all registries would be infinitely expandable, with no
need to conserve registry space.

NOT!

People seem to be forgetting that the 'E' in IETF standards
"Engineering", and that infinitely expandable registries in order to
obviate the need for responsible registration of code points may not
necessarily be the highest priority consideration, outranking all
others....

						- Ted

---

From: Robert Elz <[email-masked]>
Date: Tue, 05 Jul 2005 20:42:29 +0700

Date:        Tue, 5 Jul 2005 00:58:36 -0700
    From:        "Christian Huitema" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The problem is the really small size of the option type field in IPv6.
  | There really only are 5 bits available for numbering both the hop by hop
  | and the end to end options. That makes for a grand total of 32, of which
  | three are assigned by basic IPv6 specs. So, there really are good
  | reasons to be somewhat conservative with the assignments.

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.

Certainly it is possible (even likely) that those groups won't be filled
at the same rate, and that one will run out before the others (most likely
the one with 0's in the upper 3 bits), but pretending there are only 32
options available is taking it too far.

Beyond that, we need to consider the rate of allocation.   If IPv4 address
space was being used at the same rate as IPv6 options, even allowing for the
differences in the allocation spaces, we wouldn't have IPv6 today, we wouldn't
even be thinking about it.

This request is (or seems to be) the first new request for a v6 option
since options were invented.   At this rate it will be another couple of
hundred years before we have a problem (even if all the options were 000
options, which I think, this one was not).

When we get to about half full, which should be in another hundred years
or so, unless someone finds a sudden use for lots of IP level options that
has been eluding us for the past 20 years, we will need to extend the
option numbering space.   Methods to do that are trivial to design.  If
anything, the problem is that there are so many different reasonable ways.

Being all that ultra careful with this number space just isn't a requirement.

kre

---

From: John C Klensin <[email-masked]>
Date: Tue, 05 Jul 2005 18:20:08 -0400

--On Tuesday, 05 July, 2005 15:09 -0400 Theodore Ts'o
<[email-masked]> wrote:

>...
> "Engineering", and that infinitely expandable registries in
> order to obviate the need for responsible registration of code
> points may not necessarily be the highest priority
> consideration, outranking all others....

Ok, Ted.  Assume we agree (we probably do).  Then what we need
is criteria that 

(i) Will only allocate codes "responsibly".

(ii) Will not define "responsibly" in a way that _requires_ the
IETF to drop everything and perform an in-depth technical
evaluation, doing so in an open and transparent way, each time a
new allocation request come in.  (That is, I believe, part of
the problem the IESG is, quite properly, trying to avoid.)

(iii) Will not define "responsibly", and how we determine it, in
such a way that the decision as to whether to allocate or not
can be determined, in private, by a small group of people who
may or may not, as a group, be expert in the area for which the
allocation is requested.

(iv) Will not permit the gatekeeper function for the
registration process to take on aspects (or even the appearance)
of a "not invented here" or "we wouldn't want conflicts with our
work" model.

Now, that is probably not impossible, but it is hard.  Note that
no one, as far as I know, has advocated giving a code to any
lame request that comes along.  Several of us have argued for
strong criteria about clarify of application.   Borrowing from a
long and continuing discussion I've had with with RFC Editor, I
think it would be quite reasonable to require that anyone asking
for a new code have done a search and evaluation of alternatives
that are already out there and that the application contain a
critical review of those alternatives and point out why, in that
context, their proposed additional alternative is better... and
that such a review and explanation be able to pass at least a
laugh test among experts.  

One can make a fairly high threshold out of such things.   But
going further may be an engineering task that is more difficult
than designing code spaces that can be expanded --not
"infinitely" but sufficiently to meet any foreseeable need.

My suggestion is only that we need at least one of:

	* Fairly open registration processes
	
	* A moderately objective and open review process that
	concentrates on quality of definition as outlined above,
	and only secondarily on quality of protocol options.
	
	* A protocol proposal review process that involves real
	interaction with the community, with collectively open
	minds on the part of the IETF experts, and that will
	cumulate in registration, but presumably registration of
	a more informed and better-developed protocol or
	protocol option.   In that model, there might be an
	escape for "you don't get the code because you refused
	to let your experts talk, in good faith, with our
	experts" but, if we ever apply it, we had better apply
	it carefully and after open discussion and public
	attempts to engage.

I have trouble believing those options are unreasonable.

      john

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Jul 2005 17:28:28 +0200

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

     Brian

---

From: John C Klensin <[email-masked]>
Date: Wed, 06 Jul 2005 13:20:36 -0400

--On Wednesday, 06 July, 2005 17:28 +0200 Brian E Carpenter
<[email-masked]> 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.
>> 

Brian,

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?

   john

---

From: John Leslie <[email-masked]>
Date: Wed, 6 Jul 2005 20:37:46 -0400

John C Klensin <[email-masked]> wrote:
>> [Robert Elz wrote:]
>> 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).
> 

   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 <[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Wed, 06 Jul 2005 21:20:51 -0400

--On Wednesday, 06 July, 2005 20:37 -0400 John Leslie
<[email-masked]> wrote:

>>> 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).
>> 
>> 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.
>> 
>    It's rare that I find myself disagreeing with John Klensin,
> but in this case I must.
> 
> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Jul 2005 12:13:58 +0200

(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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Jul 2005 17:13:45 +0200

> I have trouble believing those options are unreasonable.

I think there's something missing here, which is the prudence
is required in the allocation of *all* namespaces. It's
pretty obvious in the case of small namespaces such as IP
options or diffserv codepoints. It wasn't initially obvious in
cases like IPv4 addresses, BGP AS numbers, or well-known port
numbers; but when you get half way through one of those spaces,
prudence suddenly becomes highly desirable. And even in
seemingly infinite namespaces like TLD names, it's very clear
that prudence is needed. I would argue that this duty of
appropriate prudence must be laid on whichever body gets to make
the decision. Exactly what criteria represent that prudence will
vary from case to case, of course.

     Brian

---

From: Robert Elz <[email-masked]>
Date: Fri, 08 Jul 2005 01:03:26 +0700

Date:        Wed, 06 Jul 2005 17:28:28 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

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

I'm glad that John Leslie pointed out that IANA isn't interpreting it
that way, which would be truly wild.

What 2460 says is ...

   The three high-order bits described above are to be treated as part
   of the Option Type, not independent of the Option Type.  That is, a
   particular option is identified by a full 8-bit Option Type, not just
   the low-order 5 bits of an Option Type.

I have no idea how you manage to interpret "identified bt a full 8-bit
Option Type, not just the low-order 5 bits" in the way you say you do,
but if that text isn't clear enough for you, I have no idea what could
possibly be, and perhaps we should just stop talking about anything that
relates to interpretation of the documents, as it seems likely to just
be a waste of time.

On the parenthetcal comment at the end of your message - yes, of course
an option can be both e2e and hbh, in fact, that's the normal case, the
options registered apply to both hbh & dst opt headers (though a particular
option can be defined to have meaning only in one of those situations,
Router Alert as an e2e option would be a fairly meaningless thing...)

What's more relevant here is how you're managing to convolute the
e2e/hbh issue, with the top 3 bits of the option code?   They're
orthogonal.  None of the top 3 bits have anything at all to do with
which header the option appears in (though the 0x20 bit being set in
an e2e opt header takes a little bit of understanding to appreciate
how it can apply - don't just assume it cannot, it certainly can, but
it isn't going to be common)

In any case, for John Klensin, there's no need to waste time clarifying
this, it is already just about as clear as it is possible to write it.

kre