Subject: Re: S stands for Steering [Re: Should the IESG rule or not?]

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 30 Jun 2005 23:11:25 -0500

If I may plead for a moment of silence ...

There is an Internet Draft that is intended to give the community a 
chance to provide comments on what the IETF vision of option 
registration might be - or, might not be.

If we could discuss this draft, and say things like "I agree", "I 
disagree", "goes too far", "doesn't go far enough", it seems to me 
that we might actually be able to come closer to closure in this 
thread (and its predecessors), one way or the other.

That URL, again, is 
http://www.ietf.org/internet-drafts/draft-klensin-iana-reg-policy-00.txt.

And I apologize for having nothing whatsoever to say about spamops, 
killfiles, or steering.

Thanks,

Spencer 

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 01 Jul 2005 01:03:07 -0400

As a general statement, I think this document goes too far.
Several issues occur to me reading it.  A sampling follow.

1) As written, the document seems to say that all small allocation spaces 
should be "repaired".  This does not always follow.  Making the IP version 
space bigger does not seem a desirable approach to interoperability, for 
example.

2) There are issues of appropriateness that are complex, and need to be 
considered.   For example, there is an ongoing debate in the routing area 
as to how much information, and of what kinds, ought to be carried in the 
routing protocols.  (The problem exists for both BGP and our intra-domain 
link state routing protocols.)  It would really complicate such a 
discussion if the working groups did not have the ability to say "no, there 
are uses of these fields which are wrong, and we will not encourage them be 
registering them."

3) No matter how much we claim that registration is not endorsement, it 
will frequently be seen as endorsement.

4) Allowing arbitrary values in fields which need to be understood for 
interoperability can make life very difficult.  It turns out that even when 
the protocol has planned well for unknown values, the negotiations and 
exchanges can get very tricky.  And the more extensive the set of options, 
the harder it gets.

5) There are sometimes subtleties about who is appropriate to provide the 
definitions for some values.  Particularly if the meaning relates to 
proprietary activities.  Just having clear documentation is not always 
sufficient.

6) For some purposes it is important that the document actually be right, 
not just clear.  To use a historical case, there was a request for 
registration of a number space at one time which was accompanied by I-Ds, 
etc.  It was however mathematical falsehood.  It would not 
work.  Registering it would have been a disservice to the community.  In 
that particular case, the problem was clear.  But other cases may not be so 
clear.
6') We are usually fairly careful about registering cryptographic 
algorithms, and we try to make sure that our experts think the algorithms 
make sense.  This document would seem to do away with such checks.  (I 
believe this is an example of one way that a document may be extant, and 
readable, but subtly harmful or false.)

7) There are clearly spaces / applications / domains where people can and 
should be encouraged to experiment.  But not all spaces have that 
property.  We have enough trouble with junk in spaces like DNS without 
agreeing to register any type code / meaning that someone wants to write up.

Yours,
Joel M. Halpern

At 12:11 AM 7/1/2005, Spencer Dawkins wrote:
>There is an Internet Draft that is intended to give the community a chance 
>to provide comments on what the IETF vision of option registration might 
>be - or, might not be.
>
>disagree", "goes too far", "doesn't go far enough", it seems to me that we 
>might actually be able to come closer to closure in this thread (and its 
>predecessors), one way or the other.
>
>That URL, again, is

---

From: Robert Elz <[email-masked]>
Date: Fri, 01 Jul 2005 12:53:33 +0700

Date:        Thu, 30 Jun 2005 17:21:10 -0400
    From:        Sam Hartman <[email-masked]>
    Message-ID:  <[email-masked]>

  | The RFc 2780 procedures are a sparse.  We'd all be happier if the
  | community had given us more advice on what criteria to use when
  | evaluating hop-by-hop option requests and on what procedures were
  | desirable.

2780 refers to 2434 for its definition of terms,   Everything in 2434
is about the amount and type of documentation that is required.
What's more, that is as it should be, this is IANA considerations after
all - what we're doing (what IANA would be doing) is registering
parameters.   The point of that registration is to avoid conflicts
(both one name or number used in two different ways, and two different
names/numbers that mean essentially the same thing).   That's it.

The IESG has been acting as if it had been asked to approve the protocol
that was going to use the option.   That would certainly have required
community review, and deciding not to allocate resources to such a review
may have been a justifiable decision.

But that is not what was requested, the protocol for which the parameter
was requested may be totally hopeless.   That isn't going to stop it
being used, if its advocates feel strongly enough about it.   Whether
they do in this case I cannot tell for sure.   But there will certainly
come a case where they do.

Failing to register whatever parameter they need, because the protocol
proposed is disgusting, even if true, helps absolutely no-one.  On
the other hand, if the documentation of what the parameter means, or
how to use it, is inadequate, then refusing registration makes sense.
It is also immediately clear to the applicant what they need to do to
correct the problem - simply fix the quality of their documentation.

  | The IESG is under significant pressure to improve the management of
  | the IETF.  The community believes that the IESG has management
  | responsibility for the timeliness ande appropriateness of the output
  | of the IETF.  If the IESG is going to have this responsibility it
  | should be given the tools to act on this responsibility.

I agree with all of that, the IESG should be driving and helping the
working groups produce quality output.   They should spend more of
their available resources doing just that, and much less quibbling with
the results of what the community has produced.

  | One tool the IESG needs is to be able to set the bar fairly high for
  | new work in the IETF that is unlikely to gain consensus.

That's fine.   But notice that nothing here was asking the IETF to do
new work.   That was something the IESG invented for itself.  All that
was requested as assignment of an integer in a particular IANA registry.
I am confident that IANA has both the expertise, and probably the resources,
to preform that task, once told to go ahead and do it.

  | This is
  | especially true when there is existing conflicting work in the IETF.
  | We don't value multiple protocols for doing the same thing for the
  | sake of having multiple protocols.  Clearly we sometimes do charter
  | multiple efforts to do the same thing, but we tend to require a higher
  | bar when that is the case.  If the IESG does not have this ability,
  | then it will be forced to charter work that is more likely to
  | ultimately fail, consuming significant resources in the process.

Again, all that is fine, but irrelevant, as no-one was asking the IETF
to do any work, there were no IETF resources to be wasted here.   If
the other group are wasting their resources defining a protocol that
untimately doesn't get used, because it is junk, that's their issue,
not the IETF's.

  | Committing to review any proposal that comes in from another standards
  | organization is not compatible with efficient management of the IETF.

Of course not.   They didn't ask you to review it.

  | I do not feel comfortable discussing the reasoning that lead to the
  | particular management decision not to allocate resources to this work
  | item on a public list.  There are parts of any discussion of this type
  | that do involve politics.

Yes, there's a bad smell of "that is our turf, how dare they step into it"
being at least a part of the reasoning (perhaps unconscious, perhaps
deliberately stated, those not in the meeting will likely never know).

  | However I would like to look at what options the community has in
  | order to disagree with this decision.  First, while the option of
  | appeal does exist, it seems like an inefficient option to employ and
  | there are better alternatives.  Someone could write an internet draft
  | allocating the codepoint; if they believe that we should allocate the
  | codepoint without technical review of the proposal, then they could
  | contain few details on that draft about the proposal but instead
  | reference the existing specification.

How exactly would that change anything?   The IESG apparently believes that
the protocol is no good, and that that fact (whether true or not, I have
no idea) should govern the assignment of option codes.   How can a draft
cause that to alter?

If you mean that the IETF should review the protocol they're proposing,
why?   That isn't what they requested.  Why would we care?   It might
be different if we could expect to be able to prevent the protocol being used 
by legislating against it, but we cannot.  If they like it, they will use it, 
whatever we (the IETF) thinks about it, and whether or not IANA issues
them a code point (recall, that is just a number, it takes no particular
skill to pick a number out of the hat).

  | If people believe that the guidelines in RFC 2780 should
  | encourage the IESG to assign options whenever the use is sufficiently
  | specified and there is likely to be a significant deployment, then
  | they could propose revising RFC 2780 with those requirements.

There is no need to do that, that's what it effectively already says.
The problem is that the IESG read he words "IESG approval" and took
that to mean "we can judge however we like".   But that's not what rfc2434
is all about, it nowhere suggests that the IANA, or those making decisions
on the IANA's behalf, should be investigating the technical merits of
the proposals.

It is possible for a field to require that, if it requires a standards
action RFC, or slightly less, if it requires IETF consensus.  In both
of those cases, the review happens as part of making the required documentation
available, not as a part of doing the IANA allocation of the code point.

For IESG approval, there's no particular documentation required, just
whatever the IESG deems necessary.   Once that documentation is available,
the code point should be allocated.

That is the current state of the 2780/2434 combination.

  | I would like you to consider one thing with regard to the specific
  | proposal.  We both seem to believe it is reasonable for the IESG to
  | require community review.

In this case, I don't.   There was nothing that needed to be reviewed.
The IESG can certainly seek outside assistance in doing its job, that's
not the same thing as community review.   This is not a case where there
is anything that needs much reviewing.   Either the documentation is
adequate, or it is not.   If it isn't, it can certainly be fixed to
make it adequate.

  | So far, I'm not hearing requests either from the
  | IPV6 or QOS communities for the opportunity to review this proposal.

Which may mean that they don't care (or all kind of other things).   If
they don't care, why should anyone else?

  | If those communities don't want to support the proposal, it will
  | ultimately go nowhere within the IETF.

As a protocol in the IETF, that would be true.   But the community who
took this request to the IESG (via IANA) didn't ever say they wanted
IETF approval.

That is, this is most definitely not a case of someone wanting to gain
apparent IETF blessing of their shoddy work by getting an RFC number
assigned to it.

  | Why should we be spending
  | effort on the proposal without interest from the areas of the IETF
  | that would ultimately review it? 

You should not.   The IESG already spent far too much time on this.
All it should have done was looked through the documents presented, and
determined whether or not they were adequate to document the option.
It could reasonably have asked for more documentation, for clarification of 
the current state of the documentation (whether it was likely to change
further) and other issues like that.   No-one (here) should be wasting
any time on the actual protocol quality, unless someone asks for that
to be done.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 01 Jul 2005 12:56:42 +0700

Date:        Wed, 29 Jun 2005 17:39:37 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <p0620070ebee8c42a0174@[10.0.0.171]>

  | The arguments against what the IESG has done seem, 
  | mostly, to be that we should have gotten IETF consensus before
  | making  a decision.

That is absolutely not it.

The argument is that the IESG used the wrong criteria in making
their own decision.

kre

---

From: Dave Crocker <[email-masked]>
Date: Thu, 30 Jun 2005 23:43:20 -0700

> And I apologize for having nothing whatsoever to say about spamops, 

as well you should.

"we" will let it slide this time, Mr. Dawkins.

but don't let it happen again.

-- 
 
   d/

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

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

Date:        Thu, 30 Jun 2005 18:50:01 -0400
    From:        Jeffrey Hutzelman <[email-masked]>
    Message-ID:  <[email-masked]>

  | Have you read the spec in question?

I have not, and I expressly will not, because that cannot possibly be
relevant.

  | The issue is not that the presence of an unknown option interferes with 
  | congestion control.  The problem is that when the endpoints _do_ implement 
  | the option, they can sometimes decide to disregard TCP congestion control 
  | procedures such as slow-start, which while implemented on an end-to-end 
  | basis nonetheless affect congestion control on all intervening segments.

You mean the network dies if end nodes don't do the TCP congestion
control that TCP normally expects to be done?    That's wonderful
news for the "bad boy" brigade I would have thought.  How many days
from now before they have TCP implementations that ignore congestion
control, and by so doing, apparently, totally cripple the net?

They don't need a new option to ignore congestion control, they
just adjust their TCP stack code a little.   In fact, they'd do
better (from their point of view) without using a new option - that
would make the packets readily identifiable, and easy to filter, if
they were doing harm that anyone could detect.

Or could it perhaps just be that the net might survive this, it seems
to survive UDP packet streams from time to time, and as best I recall
it, there isn't a lot of congestion control (or feedback even) in UDP.

kre

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 01 Jul 2005 11:32:41 +0200

You won't get your silence, Spencer, but thanks for trying!

I've now scanned the document, and I have found a number of points I 
disagree with; most of them have to do with the crispness of the criteria 
proposed.

I think the debate we're having is a good one - it's one of those conflicts 
that's been lying like an undetonated land mine in our back yard for the 
longest time. Now that we've finished dancing on the "IASA" land mine, we 
may have the energy (and the amount of hospital supplies) needed for 
dancing on the "using the IANA functions for control" one......

My opinion, in short:

1) I think the idea of describing *why* we are requiring registration is a 
good one. I also think that this dimension is nearly orthogonal to the 
dimension of *who* decides on a registration, which is what 2434 describes.

2) Objection to the history description: We have a LONG tradition (reaching 
back at least to 1991, when I joined the IETF) of trying to use control 
over registration as a means of guiding protocol developments. The 
"experimental/standard" arcs of the OID tree in SMI, the very restrictive 
requirements for new MIME top level types, the insistence that new charset 
registrations be of charsets that already exist, and the requirements for 
SMTP extensions are all living examples. So claiming that this is a "new" 
development strikes me as strange - it would be better to say either that 
this a practice of the last 15 years that should end, or that this is a 
long-running conflict that ought to be resolved. (Others will have to speak 
to the "before 1991" timeframe)

3) Documentation quality: "Documented" is a slippery word. I would suggest 
that here too, a specific set of criteria be established, for example:
- the identity of the assignee and value requested/assigned is documented; 
what it's used for is not. Example is the "private use OID space".
- some indication of the purpose of the thing is also given, but nothing 
that would permit interoperability. Example: Port numbers.
- documentation sufficient to build interoperable implementations exists. I 
fervently hope that all "standards action" assignments are in this category!

4) Scaling is good. But I think it the advice here ought to be much more 
specific. We should be saying things like "Mitigation efforts need to start 
NOW if there's less than 5 years' life in an existing namespace".
We know that standards take 2 years, and that changes to established 
standards take a long time to get out.
(I'm also quite skeptical of all these MUSTs requiring action to avert 
disasters - we know for certain that the AS number namespace is headed for 
a crisis within finite time unless things change, we've got a WG that is 
charged with doing something about it, but despite this, the mitigation 
efforts (4-byte AS numbers) seem to have stalled. Different topic.)

5) I am quite unhappy with section 5.

A blanket redefinition of "IESG approval" as "documentation (satisfying an 
IESG review) required" is, to my mind, wrong. People have written this 
sentence into IANA considerations thinking that the IESG would make a 
technical judgment on the parameter registration request. Changing the 
meaning for all cases without asking the owning WG of each individual case 
is, to my mind, a retrofit that goes too far.

The other part of section 5 is to require a Last Call for all rejections 
done by the IESG; this is, to my mind, reasonable on its own - however, the 
idea that the IESG can then take a solid IETF consensus that this 
registration should be rejected because the technology is abhorrent, 
harmful, damaging, immoral or something else that is important to the IETF 
at the time, and then saying "yes" because the IESG was unable to find an 
argument matching this document's criteria strikes me as "somewhat strange".

But this too is a change; if the people writing the IANA considerations 
section had desired public review of requests, they would presumably have 
used "IETF consensus" as the registration criteria; to me, the choice of 
"IESG review" indicates that the writers of the IANA considerations section 
thought that the IESG was able to come to a correct decision *without* 
having to ask for an IETF consensus.

My suggestion for a change would be a bit shorter:

  As an experiment, the IESG will send out Last Calls for all requests
  requiring IESG approval that it wants to reject from <date> to <1 year
  later>. At the end of that time, it will evaluate the result, and
  either abandon the practice, modify the practice or make it a standard
  procedure.

Summary: I think the document offers very good advice for future registry 
management.
I think that a blanket retrofitting of a new meaning on the "IESG approval" 
IANA considerations is a thoroughly bad idea.

--On 30. juni 2005 23:11 -0500 Spencer Dawkins <[email-masked]> 
wrote:

> chance to provide comments on what the IETF vision of option registration
> might be - or, might not be.
>
> disagree", "goes too far", "doesn't go far enough", it seems to me that
> we might actually be able to come closer to closure in this thread (and
> its predecessors), one way or the other.
>
> That URL, again, is

---

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

Date:        Thu, 30 Jun 2005 21:12:07 -0400
    From:        Jeffrey Hutzelman <[email-masked]>
    Message-ID:  <[email-masked]>

  | Note that I would consider it entirely reasonable for the IESG to say that 
  | something "conflicts with work in the IETF" on the grounds that its 
  | deployment would break the Internet, since preserving the stability of the 
  | Internet is a fundamental part of _all_ IETF work.

I cannot agree with that.   Preserving the stability of the internet is
the responsibility of the internet operators.   There's nothing the IETF
can do, one way or the other, to affect that.   There may be times when
the internet operators seek assistance in developing protocols to assist
with particular problems, but that doesn't make solving them the IETF's
responsibility.

When the IETF develops protocols, they generally need to work on the
internet, and if the protocol is going to (or even could) prevent the
internet from working, then the protocol itself isn't going to be
very effective (like designing a truck, that you want to run over
regular streets, but which destroys the streets as it passes over
them - it is very quickly useless).

If some packet, or data, causes harm to the network, the network operators
should be making sure that packet doesn't enter their network (for self
survival purposes).   This is whether or not the packet in question is
being used by a blessed IETF protocol, or something different.

That is, I have no problem whatever if all of the network operators were
to install filters to prevent any packets containing this proposed new
option from ever entering their networks.   Of course, to do that, they
are going to have to know how to recognise the option.  A listing in the
IANA registry would sure make that simpler, wouldn't it?

  | I don't think that is the case here.  The IESG is not blocking the 
  | registration; it is simply declining to allow it without community review 
  | and consensus.

And they also said they wouldn't be allowing that review, because they
have pre-decided that it would not succeed, but would be a waste of
resources.    The IESG is unquestionably blocking the registration.

  | But, I also think the IESG's advice is at least partly accurate.  Reviewing 
  | something of this size and complexity in the IETF is likely to take quite 
  | some time.  It would likely result in changes, some incompatible, and some 
  | parts might be scrapped altogether.  I'm not in a position to evaluate the 
  | argument that it would probably not gain community consensus, and I'm 
  | beginning to believe the IESG should not have said that -- not because of 
  | whether it's true or not, and not because of the resulting controversy, but 
  | because of the chilling effect created.

Now you are starting (just beginning...) to see some of the reasons that
I complained about the IESG's response initially.   Not because the code
point should actually be registered (I have no idea on that, though I
certainly lean towards registering most things) nor because I care about
the protocol one way or the other, but because the approach that they took
was so fundamentally wrong.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 01 Jul 2005 19:11:34 +0700

Date:        Fri, 01 Jul 2005 11:32:41 +0200
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <D07251C5026B6872A94D3256@B50854F0A9192E8EC6CDA126>

I have yet to read John's draft, but there's one comment that you
made that I want to comment on.

  | Summary: I think the document offers very good advice for future registry 
  | management.
  | I think that a blanket retrofitting of a new meaning on the "IESG approval" 
  | IANA considerations is a thoroughly bad idea.

I would agree with that, as a general principal.   New methods and
specifications should apply to those who use it later, not retrospectively 
to what has been done before.

There are two exceptions, one is where what has been specified before
turns out to be so broken that it cannot be allowed to continue.
I don't think that applies here (despite the controversy, and despite
that I'm on the side of the controversy opposite to that you're apparently 
on...)

And second, when the specification before has been ambiguous, or unclear,
and all possible interpretations that have been made cannot possibly be
correct simultaneously.

That one may be appropriate here.   That is, I certainly believe that
2434 means "verify the documentation is adequate" just as John's draft
is apparently proposing.   That is, for me, not a change at all.

I certainly would never have ignored a proposal to register trivial
things like IPv6 option codes if it required approval of the use of
the option, rather than documentation of the thing.   That is, when
2780 was proposed, I assumed it was using 2434 in the way I interpret
2434, and IESG approval meant a check that the documentation was of
adequate quality for the purpose, and no more than that.

Others apparently thought it meant something different that that, anything
from examination of the quality of the option proposed (making the
IESG judge and jury), to being an "escape route" or fallback, though
from just what I am not sure.

In this situation, both cannot remain, and leaving ambiguity in place for
all those existing documents doesn't help anyone.   Any clarification
is going to be seen as a change by some people, the question is, what
change is best to make, or what is the best actual definition.

For what it is worth, I agree with you that "IESG approval" should not
mean "with community consent", that would (almost) be "IETF consensus"
(though perhaps without requiring an RFC to emerge at the end).

For me, IESG approval, and Expert review demand essentially the same
examination - the only difference between them is that it doesn't
make a lot of sense to appoint an expert to look after a space in which
it is not expected that any registrations will actually be requested (pr
where the number is very small).   That is, in the period between 
registrations the expert can be expected to have retired/resigned, so
each new request would require finding and appointing a new expert.
That's more work than just doing the review.    This is what I would
expect of IPv6 option codes (I believe, in about 10 years now, aside
from Router Alert, this one is the one and only addition requested).

As far as history goes, and the OID tree - do remember that the OID tree
has vendor space, in which anyone can trivially register anything.
Once there, the OID is just as good as any other OID.

The Vendor space gets used two ways - one is to actually identify
vendors, and their products (etc).   For that it is just fine.

The other is for vendor private MIB variables - for that I (with
hindsight, naturally) believe it has been a failure.   All it does
is require data to be sought in multiple different places, depending upon 
which vendor's equipment is being managed.  Certainly, some of what is
there is truly vendor specific information, but much of it is just
general data that could have been in the standard MIB, but either
wasn't considered, or someone thought it a poor idea.   Yet the
customers apparently want it, so into the vendor private MIB it goes.

The IETF may have tried to control MIB contents using registration
control, but at that it failed miserably.   That isn't surprising,
it is a tool not suited to the task.

kre

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 01 Jul 2005 21:23:16 +0900

kre;

> with particular problems, but that doesn't make solving them the IETF's

Agreed.

Given that the specific problem is on assignment of IPv6 hop-by-hop
option value for QoS assurance, there is nothing for IESG to worry
about, because IPv6 is not really deployed.

Let the operators decide.

It should be noted that the decision by the most operators is
that IPv6 does not worth deploying.

So, I can argue that, this time, IESG behaved very properly to
discard IPv6 by discouraging further effort on it. 

However, I can also argue that TCP congestion control mechanisms
for best effort traffic has little to do with QoS assured
communication.

						Masataka Ohta

PS

The fundamental problem is that management framework to have been
making IETF products less timely and less useful can not produce
timely and useful ways to improve IETF. Actually, IETF has been
damaged by increasing steering power of IESG.

---

From: Keith McCloghrie <[email-masked]>
Date: Fri, 1 Jul 2005 06:07:38 -0700 (PDT)

> customers apparently want it, so into the vendor private MIB it goes.

On the contrary, having vendor OID space has been a tremendous success.
Despite all the IETF's work in defining MIBs, there are many, many areas
of technology for which no standard MIBs exist.  It's impossible for the
IETF to standardize everything; if vendors didn't have their own OID space,
then the use of MIBs would be limited, would not be nearly as ubiquitous
as it is, and therefore less valuable.  Even those areas in which the IETF
does specify standard MIBs, the time taken by the IETF process gets
longer and longer as the years go by; if vendors had to wait until the
IETF published a MIB in an RFC(*), MIBs would be so late, that they
would be even more of an afterthought than they already are -- network
management suffers on those occasions when devices don't have
management support from day-1; if vendors didn't have their own space
such suffering would necessarily happen *all* the time.  Using OID
space has allowed other SDOs (e.g., IEEE, ATM Forum, etc.) to define
their own MIBs, which has also been a success.

(*) Bad experiences often occur when implementing MIBs based on I-D's,
because I-D's are not permanent and do not have change control to prevent
illegal changes.  The only way to ensure that an implementation of a
MIB, specified in an I-D, will still be valid 6 months later is for a
vendor to copy the MIB into the vendor's private OID space so that the
vendor has change control.

> it is a tool not suited to the task.

No and yes.  The IETF did not try for such control, because such
control would have failed in many cases, precisely because the tool is
not suited to the task.  Many vendors would have found other ways to
have OIDs -- exactly as you are suggesting they would find other ways
to have option codepoints.

Keith.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 01 Jul 2005 15:55:21 +0200

> it is a tool not suited to the task.

quick reply.... not the only thing I want to reply to, but.....

I was thinking of the process that Marshall Rose instituted, where 
internet-draft MIBs get OIDs out of "experimental", while RFC MIBs get OIDs 
out of "mib-2" (or wherever it is; my detail memory is awful).

That's had the result that people KNOW that their implemetations of the 
internet-draft won't conform to the RFC - which means that they either 
stand ready to implement the RFC (including any last-minute tweaks) or that 
they make a conscious decision to ship stuff that uses experimental OIDs.

Both outcomes are fine with me... I wasn't thinking of OIDs in general.

                Harald

---

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Jul 2005 11:24:06 -0400

>>>>> "John" == John C Klensin <[email-masked]> writes:
    >> Yes, the IESG could abuse its power in the future.  For example
    >> if it failed to charter work for one of the previous options in
    >> the presence of significant community support, then the IESG
    >> would be abusing its power.  If the IESG blocked such a
    >> document with discusses that challenged the fundamental premis
    >> of the document while there was community support then the IESG
    >> would be abusing its power.  If the IESG constructed
    >> unreasonable process blocks or unfairly enforced process issues
    >> against these documents then it would be abusing its power.
    >> But if the IESG is going to have management responsibility, it
    >> needs the authority to recommend against things it believes are
    >> wastes of time.  Some times the community will disagree with
    >> those recommendations; so long as the IESG does not block the
    >> community that's entirely fine and will be a result of an open
    >> process.

    John> We are in complete agreement here.  And I notice that you
    John> use the term "recommend", which appears to me to be rather
    John> different from the decision made in this particular case.

No, actually, recommend was the term that the IESG used.  The IESG
declined to approve the request on the spot because the IESG believed
that a protocol option changing TCP congestion control (among other
things) required review within the IETF community.  Even if we thought
Scott claims we could have the proposal was great and would easily achieve consensus we would
have declined the request for this reason.  The remaining critical
question is what we recommend happen next.

In this instance we recommend against pursuing the proposal because we
don't believe it will achieve consensus.

In other instances we might have declined the request and recommended
that the proposal be taken to the IPV6 working group for review on the
IETF consensus or standards action path.

The distinction between what part of the response was a recommendation
and what part was active text is quite important.  There are numerous
cases wher people in the IETF do things the IESG recommends against.

--Sam

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 1 Jul 2005 11:39:05 -0400

Hi,

>correct the problem - simply fix the quality of their documentation.

You seem to be arguing that the only thing that the IESG _should_ 
have done regarding this allocation was to determine whether or not a 
document exists.  You have indicated that the IESG should not have 
assessed the technical properties of this specification, but, IMO, 
your view is not supported by the categories in RFC 2434.

There are two different categories that will allow allocation based 
on a non-RFC specification:

       Specification Required - Values and their meaning must be
            documented in an RFC or other permanent and readily available
            reference, in sufficient detail so that interoperability
            between independent implementations is possible.

            Examples: SCSP [SCSP]

       IESG Approval - New assignments must be approved by the IESG, but
            there is no requirement that the request be documented in an
            RFC (though the IESG has discretion to request documents or
            other supporting materials on a case-by-case basis).

The first of these (Specification Required) only means that the 
specification must exist in a "permanent and readily available" form 
and be sufficient detailed for interoperability.  If the community 
had wanted to allocate an IP option number to any individual or 
standards body that could point to a permanent and readily available 
document, then I personally assume that the community would have been 
competent enough to make that choice, and would have left the 
question of IESG approval out of this altogether.

But, what _the community_ actually chose as the lowest level of entry 
to obtain an IP option number is "IESG Approval".  IESG approval 
can't mean that we have simply determined that there is a detailed 
document -- that would be covered by "Specification Required".  IESG 
approval means that the IESG _approves_ of the allocation.  And, in 
this case, we did not do so.

According to my local Webster's dictionary, the word "approve" means: 
"to have or express a favorable opinion of", "to accept as 
satisfactory", or "to give formal or official sanction to".

So, it doesn't seem to me that someone can obligate me to approve of 
something by pointing to the existence of a document.  If you ask me 
to approve something, you are asking me to exercise my judgement -- 
in this case, my judgement about whether an IP option number should 
be allocated for this purpose without requiring an IETF consensus 
document.  If the community did not want the IESG to exercise 
judgment in this particular situation, they should have chosen a 
different threshold for IP option number allocation.

As an aside, I am not sure that this particular request would meet 
the requirement for "Specification Required", either, as we have been 
pointed to a non-archival document on Larry Robert's web site.  If 
there is a version of this document that currently exists in a 
"permanent and readily available" form, I am not certain that I have 
received a pointer to it.  (I did get a pointer to another version of 
the document, but I am not sure if that version is either archival or 
publicly available).

BTW, for the people who may be asking "If the IESG didn't think they 
could approve this themselves, why didn't they just immediately start 
an IETF review process?"  We can't start that process without an I-D.

The two available options are:

       IETF Consensus - New values are assigned through the IETF
            consensus process. Specifically, new assignments are made via
            RFCs approved by the IESG. Typically, the IESG will seek
            input on prospective assignments from appropriate persons
            (e.g., a relevant Working Group if one exists).

            Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address
            Family Identifiers [BGP4-EXT].

       Standards Action - Values are assigned only for Standards Track
            RFCs approved by the IESG.

Both of these options would require Larry Roberts (or someone) to 
submit an I-D.  As I read the first one, I believe that he could 
submit an I-D that makes the allocation and normatively refers to an 
archival, publicly-available ITU specification (if one exists) for 
information about how this option should be interpreted/used -- as 
long as the ITU specification is permanent, readily available and 
sufficiently detailed, I believe that this could consist of little 
more than an IPR section, a reference to the ITU specification,an 
IANA Considerations section and a normative reference.

The second choice would require that Larry (or someone) produce an 
I-D for the option itself for standardization within the IETF.  This 
would seem like an odd choice for something that is under development 
within the ITU.

I suppose that the IESG could have written back to Larry and said 
"the IESG did not approve this document, please submit an I-D so that 
we can bring it to the IETF for review", but we instead thought that 
it would be wrong to encourage Larry to do more work when we consider 
the possibility of IETF Consensus to be very low.  Maybe it was wrong 
(or confusing) of us to communicate that opinion in our response (and 
if so, I apologize for my part in that).

At this point, the only decision that the IESG has actually made is 
that we (the IESG) do not choose to approve this IP option number 
allocation via the "IESG Approval" mechanism, and that any allocation 
of this number will have to be done via the "IETF Consensus" or 
"Standards Action" mechanisms.  It is now up to Larry Robert's to 
decide if he wishes to pursue one of the other options listed in RFC 
2780 (and above).

Margaret

---

From: Robert Elz <[email-masked]>
Date: Sat, 02 Jul 2005 00:38:14 +0700

Date:        Fri, 1 Jul 2005 06:07:38 -0700 (PDT)
    From:        Keith McCloghrie <[email-masked]>
    Message-ID:  <[email-masked]>

  | On the contrary, having vendor OID space has been a tremendous success.

OK, I didn't mean what I said in the way you clearly interpreted it.

I absolutely understand the need to be able to quickly define new MIBs
to respond to demand.   And I understand how the vendor MIBs have enabled
that to happen.   Wen I was intending to covey was that vendors could
have shared the same MIB definitions had these new, rapidly defined MIBS
(which certainly exist, and are certainly useful, as you indicate) had
been placed directly into the standard MIB tree.   That way, management
stations wouldnot need to look to discover what vendor's equipment was
being managed, then go find the appropriate data in that particular vendor's
private MIB space.   I know, I've tried doing that, and it isn't pleasant.

kre

---

From: Keith Moore <[email-masked]>
Date: Fri, 1 Jul 2005 14:08:42 -0400

> can do, one way or the other, to affect that.  

Rubbish.  IETF can make recommendations to Internet operators, based on
its extensive knowledge of how Internet protocols were designed to work
and how they tend to be used, and its ability to understand the likely
effects of a particular change on Internet stability and
interoperability.  IETF's recommendations are influential partially
because operators recognize the collective expertise of IETF
participants and IETF's ability to make sane compromises between
competing interests. The recommendations are also influential because
even though IETF doesn't always make the best recommendations, there's
something to be said for uniformity in operations across the Internet
and most operators understand this. (note that I didn't say that
operators bow and scrape to follow IETF recommendations, just that the
recommendations are influential).

in a nutshell: IETF doesn't have control, but it does have influence.

Keith

---

From: Robert Elz <[email-masked]>
Date: Sat, 02 Jul 2005 01:18:31 +0700

Date:        Fri, 1 Jul 2005 11:39:05 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <p06200745beeb0518c843@[10.0.0.171]>

  | You seem to be arguing that the only thing that the IESG _should_ 
  | have done regarding this allocation was to determine whether or not a 
  | document exists.

No, I didn't say that at all, ever.   What I said was that the IESG should
have determined whether there was adequate documentation for the option.
That is, whether the documentation was clear, unambiguous, complete, and
would allow an implementation of the option by someone who wanted to
do that, or for someone to understand what the bits in the packets
passing through their network are suppsred to mean.

  |        Specification Required - Values and their meaning must be
  |             documented in an RFC or other permanent and readily available
  |             reference, in sufficient detail so that interoperability
  |             between independent implementations is possible.

yes, that one is "there must be some documentation"

  |        IESG Approval - New assignments must be approved by the IESG, but
  |             there is no requirement that the request be documented in an
  |             RFC (though the IESG has discretion to request documents or
  |             other supporting materials on a case-by-case basis).

And that one is "there must be adequate documentation".  Observe how
the IESG is expressly empowered to request more, or other materials
as required, and then obviously, should that not be forthcoming, or
still be inadequate, to refuse the registration.

  | But, what _the community_ actually chose as the lowest level of entry 
  | to obtain an IP option number is "IESG Approval".  IESG approval 
  | can't mean that we have simply determined that there is a detailed 
  | document -- that would be covered by "Specification Required".  IESG 
  | approval means that the IESG _approves_ of the allocation.

That's true.   But once again, you're asusming that you (the IESG) get
to choose the criteria to use when making that decision.  That is, you
get to do whatever you like, without recourse.   That would truly be
amazing, as it would be the only place in the IETF where that kind of
power was given to the IESG.   That is not supportable.

  | According to my local Webster's dictionary, the word "approve" means: 
  | "to have or express a favorable opinion of", "to accept as 
  | satisfactory", or "to give formal or official sanction to".

That's fine.   I prefer the Oxford myself (occasionally Macquarie), but I
doubt it is going to make a difference to the definition of that term.
Nor is it the issue - the question is what should be examined when
deciding if the request is approved, and what should not be.

  | So, it doesn't seem to me that someone can obligate me to approve of 
  | something by pointing to the existence of a document.  If you ask me 
  | to approve something, you are asking me to exercise my judgement -- 

Yes.

  | in this case, my judgement about whether an IP option number should 
  | be allocated for this purpose without requiring an IETF consensus 
  | document.

No, the working group already made that decsion for you.  They already
said that was OK, or they would have required IETF Consensus or standards
action processes to allocate the option.   You don't get to simply
override the already published IETF processes, however much you would
like to.

  | If the community did not want the IESG to exercise 
  | judgment in this particular situation, they should have chosen a 
  | different threshold for IP option number allocation.

They did want judgement exercised.   They wanted to make sure that
the option was properly documented, not just a web page somewhere that
hints at what the option might be used for.

  | As an aside, I am not sure that this particular request would meet 
  | the requirement for "Specification Required", either, as we have been 
  | pointed to a non-archival document on Larry Robert's web site.

That's fine.  And if that had been the basis for the IESG's decision,
I would not have complained.   And Dr Roerts would have known exactly
what was required of him in order to get the option allocated.  As I
said, many times now, I haven't read any of the documentation, I have
no idea if an option code should have been allocated or not, all I know
is that the IESG followed the incorrect path in rejecting it.  There
may easily have been a perfectly reasonable way to do that (this time --
one expects that if the reason had been that the doc was inadequate,
it would only have taken a month or so to rectify that and ask again).

  | At this point, the only decision that the IESG has actually made is 
  | that we (the IESG) do not choose to approve this IP option number 
  | allocation via the "IESG Approval" mechanism, and that any allocation 
  | of this number will have to be done via the "IETF Consensus" or 
  | "Standards Action" mechanisms.  It is now up to Larry Robert's to 
  | decide if he wishes to pursue one of the other options listed in RFC 
  | 2780 (and above).

I actually recommend that he follow the appeal procedures in rfc2026
instead. and have the IAB tell you that you processed this incorrectly.

That way, the same issue won't arise again, the next time someone
follows this course of action (for this code point space, or another).

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 1 Jul 2005 15:16:09 -0400

Hi Robert,

>passing through their network are suppsred to mean.

In what way would that differ from "Specification Required"?

This is _not_ the choice that was made in RFC 2780.  They chose "IESG 
Approval" instead.

>yes, that one is "there must be some documentation"

No.  That one ("Specification Required") explicitly states that the 
document must be permanent, readily-available and in sufficient 
detail so that interoperability is possible.

>still be inadequate, to refuse the registration.

There is absolutely no indication here regarding what criteria the 
IESG should use to approve (or not approve) an IANA allocation.  You 
have arbitrarily decided that availability of the same documentation 
described in "Specification Required" is the only criteria that the 
IESG should be allowed use, and I don't know where that is coming 
from...  That would make "Specification Required" and "IESG Approval" 
exactly the same requirement.

I personally believe that the IESG should use the same criteria that 
we use for all of the other IESG decisions in the IETF (absent other 
direction) -- we try to decide what is in the best interests of the 
IETF and the Internet.

In this particular case, we felt that it was not in the best 
interests of the IETF and the Internet for the IESG to approve this 
allocation.  If you disagree with that decision (although I think you 
should read the document first before forming that opinion), you 
could choose to appeal that decision.  Alternatively, you could try 
one of the other paths, probably "IETF Consensus" to request this 
allocation.

>override the already published IETF processes, however much you would

The working group did _not_ make a decision about whether an IP 
option number should be allocated _for this purpose_ (i.e. for this 
particular option) without requiring an IETF consensus document. 
They delegated that decision to the IESG by including "IESG Approval" 
as one option in their IANA considerations section.  If they  wanted 
to allocate a number to everyone who produces a permanent,
publicly available, detailed document, they would have chosen 
"Specification Required".

The fact that a document gives the IESG the authority to approve 
allocations in a particular registry does not obligate the IESG to 
say 'yes' to every request that is received for that registry -- what 
would be the point of that?.  On the contrary, I think that the IESG 
should be very conservative about taking action (such as allocating a 
code point) on our own authority, and I personally believe that there 
are enough complexities in this situation that an IETF Consensus 
document and IETF-wide discussion should be required for this 
particular allocation, if the allocation is made at all.  IMO, this 
is not a case of the IESG over-exercising our authority, it is a case 
of us being conservative about exercising our authority in a complex 
situation.

>hints at what the option might be used for.

This is a good description of "Specification Required".  "IESG 
Approval" indicates that the IESG may use our judgement about whether 
(or not) to approve an allocation.

>instead. and have the IAB tell you that you processed this incorrectly.

That is a choice that is open to you, Larry or anyone else who 
disagrees with a decision of the IESG.

Margaret

---

From: David Hopwood <[email-masked]>
Date: Fri, 01 Jul 2005 20:55:05 +0100

> adequate quality for the purpose, and no more than that.

If RFC 2870 had been meant to allow assignment of hop-by-hop options using
"Specification Required", it would have said so. In that case we would not
be having this discussion (subject to public and archival availability of
the relevant documentation).

There is no possibility that the authors of RFC 2870 were not aware of a
difference between "Specification Required" and "IESG Approval", since that
RFC does allow "Specification Required" (in addition to most of the other
possibilities) for allocation of port numbers -- where the allocation
requirements are obviously intended to be weaker.

-- 
David Hopwood <[email-masked]>

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 1 Jul 2005 16:19:13 -0400

> yes, that one is "there must be some documentation"

Doesn't "interoperability between independent implementations" mean
"clear, unambiguous, complete"?

My interpretation of "Specification Required so that interoperability
between independent implementation" certainly implies everything which
you claim "IESG approval" means.

Your interpretation of "Specification Required" as "it's OK if the
specification is crappy and might lead to non-interoperable
implementation" seems to be belied by the definition of "Specification
Required" which you quoted above.

So if that is the case, then IESG Approval should mean something else,
and hopefully something implies more than "the idea, good or bad, has
a complete specification."  "Doesn't destroy the internet" seems like
a good reasonable criteria, and there problably should be others that
the IESG might want to apply --- and I for one am quite willing to
give that discretion to the IESG as to what criteria they believe
should be applied.  If they abuse that power, well that's what the
appeals process and the nomcom process is all about.

And of course, at the end of the day, implementors can always ignore
IANA.  Lack of registration certainly has not stopped various vendors,
including Microsoft, to create and sell products with unregistered
code points in Telnet, DHCP, and other IETF protocols.  But if the
IESG is going to "approve", that certainly implies a certain
assumption of the quality of the assignment.  Otherwise, IMHO, we
should just say "Specification Required".

						- Ted

---

From: Pete Resnick <[email-masked]>
Date: Fri, 1 Jul 2005 15:57:38 -0500

On 7/1/05 at 3:16 PM -0400, Margaret Wasserman wrote:

>>...the IESG should have determined whether there was adequate 
>>documentation for the option. That is, whether the documentation 
>>was clear, unambiguous, complete, and would allow an implementation 
>>of the option by someone who wanted to do that, or for someone to 
>>understand what the bits in the packets passing through their 
>>network are suppsred to mean.
>

"Specification Required" requires "an RFC or other permanent and 
readily available reference". In other words, an I-D (however 
complete the work it documents) or a web page (however fully 
specified the protocol it describes) or copyrighted proprietary 
material (which could never be "readily available") would not suffice 
for "Specification Required".

And in all honesty, I had always read the "IESG Approval" clause in 
2434 to be an escape clause for those sorts of folks who did not have 
an RFC (or other *permanent* document), such that the IESG could say 
to IANA, "This registration request is from folks who have enough 
documentation to satisfy the registration requirements even though it 
is not the sort of documentation that IANA can independently verify 
is 'permanent and readily available' enough to satisfy the 
'Specification Required' requirement." I never expected IESG to be 
judging the technical merits and worthiness of any such request. And 
I do remember reviewing 2434 when it was being worked on.

>direction) -- we try to decide what is in the best interests of the 

Personally, I find nothing in 2026 which indicates "in the best 
interests of the IETF and the Internet" as a criteria for the IESG to 
evaluate much of anything. And I think that is part of the concern 
you are hearing expressed in the objections to the decision process.

>say 'yes' to every request that is received for that registry

Nobody, and I mean *nobody*, has ever suggested this. Why is this 
repeatedly being brought up as an argument against folks who disagree 
with the IESG decision process? The question is over the basis for 
the "no", not that "no" is an impossibility.

Yes, that fish in the school is awfully red. Let's move along and 
ignore it now, shall we?

On 7/1/05 at 4:19 PM -0400, Theodore Ts'o wrote:

>IANA.  Lack of registration certainly has not stopped various 
>vendors, including Microsoft, to create and sell products with 
>unregistered code points in Telnet, DHCP, and other IETF protocols.

Well, exactly. And we have even learned in the past that when the 
registration process is perceived as too burdensome for some, we not 
only end up with unregistered code points, we end up with them 
purposely conflicting with IETF registered code points (cf. VRRP and 
CARP).

>But if the IESG is going to "approve", that certainly implies a 
>certain assumption of the quality of the assignment.

No. Assignments don't have a "quality". You don't mean "quality of 
the assignment", you mean "quality of the protocol". Any that's not 
what the IESG is asked (in 2434) to judge. To repeat: My 
understanding is that if there's a choice of "Specification Required" 
and "IESG Approval" in a document IANA is to go to the IESG if they 
can't find "an RFC or other permanent and readily available 
reference". Approval of a registration is not equivalent to approval 
of a protocol. And I think people who keep saying, "Approval of the 
registration will be equated with approval of the protocol and people 
will start deploying it even if it's a bad idea" really need to 
present some evidence that such has happened with IANA registrations 
in the past.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 1 Jul 2005 19:41:09 -0400

I agree with all of Joel's points, below, and add the following comments.

The fundamental philosophical assumption made by
draft-klensin-iana-reg-policy-00.txt goes too far is that registration
of code points is always a good thing, and it is never bad thing to
reserve a code point in the interests of interoperability and to avoid
problems caused by code point collision.  I disagree with this
assumption; as Joel points out, "as much as we claim registration is
not endorsement, it will frequently be seen as endorsement".  The
validity of this principle has been accepted by the IETF community and
its general practice, when in RFC 2026 (BCP 9), section 4.2.3, we
allow the suppression of experimental RFC's that are submitted with
the intent to subvert the standards process, by diverting them to the
relevant working group.  Why do we allow this, despite our belief that
just because it is an RFC does not give any text any special standing.
While the IETF cognescenti may know this to be true, most people do
not, and automatically give text with the "RFC" label force of a
standard.  (Given that most of us still refer to standards via their
RFC number rather than by its STD or BCP number, we help perpetuate
this problem, but that's a debate for another day.)

Beyond the endorsement issue, it can be very valuable to be able to
promote interoperability by trying to elimiate duplicate or
near-duplicate code point registrations.  If someone wants to register
a different encoding scheme which is almost --- but not quite ---
identical to base-64 encoding, instead of allowing the registration
and permitting (and perhaps endorsing) this alternate encoding
standard, it can be valuable if someone can explore with the
registrant whether or not the code point is really needed, and whether
there is a technical justification for having this alternate encoding
scheme in the first place.   

In the past, my understanding is that the original IANA would perform
such functions, and I think this is a good thing.  Converting the IANA
into something that can be implemented using an LDAP server may make
the process more streamlined, but throwing out technical judgement to
help improve some potentially bad ideas seem to be an vey, very
unfortunate side-effect.

I am also very troubled by the provision stating that no registration
could be denied based on scarcity unless a potentially heavyweight
process is initiated to either (a) eliminate the scarcity, or (b)
justify that it cannot be so eliminated.  Does this mean that every
single time some kook^H^H^H^H^H, ah...., "enthuastic experimenter"
wants to register a new IP header version, or TOS value, or one of
many, many bit-encoded, restricted fields in the lowest levels of our
protocol stack, we need to create a working group to write an RFC
justifying why expanding the IP version field in the IP header beyond
4 bits would be a Bad Thing?

The argument could be made that "common sense" would not require such
an effort, but the whole point of draft-klensin-iana-reg-policy-00.txt
seems to be to eliminate any ambiguity by spelling out exactly what
should happen, and the way it is currently worded, an implementation
of this registration policy without the application of common sense
could fairly easily result in a DOS attack against the IETF.

						- Ted

---

From: grenville armitage <[email-masked]>
Date: Sat, 02 Jul 2005 11:07:15 +1000

Jeffrey Hutzelman wrote:

> On Friday, July 01, 2005 07:58:42 AM +1000 grenville armitage 
> <[email-masked]> wrote:
	[..]
>> Scenario (a) would seem to be solved by assigned a non-conflicting option
>> codepoint and then hoping the competing protocol dies of irrelevance.
>> Scenario (b) suggests we have bigger problems. I'm honestly hoping it
>> isn't
>> scenario (b), and that there's an scenario (c) I'm just not seeing.
> 
> Have you read the spec in question?

Actually (and conciously), no. I was tempted to do so, but my position
isn't about the protocol which would be indirectly indicated by the
requested codepoint. My position is about the assignment of a codepoint,
itself merely a neutral bit pattern in packets passed from one end point
to another. A bit pattern that, if known, could be used by operators to
filter or pass packets implementing the protocol to which some object.
A bit pattern which, if unknown, cannot be used for said filtering or passing.

I'm not trying to remain ignorant of the protocol in order to be a nuisance,
more to remain clear-headed (well, IMHO, and I concede this certainly makes me
less sesitive to the basis for the IESG's broader misgivings.)

> The issue is not that the presence of an unknown option interferes with 
> congestion control.  The problem is that when the endpoints _do_ 
> implement the option,

Well, more precisely, when the endpoints "_do_ implement the protocol that
would be _represented_ by the requested option" ....

> they can sometimes decide to disregard TCP 
> congestion control procedures such as slow-start, which while 
> implemented on an end-to-end basis nonetheless affect congestion control 
> on all intervening segments.

I'm not at all unsympathetic to the negative consequences of a modified
TCP-like behaviour. (On the contrary, in fact.)

> Now, it's possible that, in the circumstances in which this spec allows 
> endpoints to punt on slow-start, it is actually safe to do so without 
> risking causing problems for the rest of the network.  But I haven't 
> read the document in enough detail to know that, and the potential for 
> problems if it is not is quite large.  I'd be much happier if any 
> proposal along those lines were reviewed by the IETF (particularly, 
> experts in IPV6, QOS, TCP, congestion control, etc) before being 
> unleashed on the Internet.

Indeed, and I too agree that there's probably a substantial amount of
useful work to be done refining (or rejecting) the algorithm underlying
the protocol changes to which the requested codepoint would have pointed.

My only concern is that we're using codepoint assignment denial as a means
of protecting the Internet from poor, TCP-unfriendly end2end algorithms. And
that just doesn't seem reasonable. (As someone else observed, two or
more consenting endpoints don't need new codepoints to implement an e2e
congestion control behaviour that's detrimental to current TCP. They
might even hide their malicious behaviour inside UDP packets!)

So, I'm not necessarily disagreeing with the IESG's summation that Dr Robert's
proposed protocol could be detrimental. But it would seem to have been more
preferable to assign a codepoint with a public notation 'packets carrying
this option represent flows using a non-IETF approved congestion control
algorithm' (or some such text). 

There should have been a famous person who said 'Keep your friends close,
and enemies well documented' ;)

cheers,
gja
-- 
Associate Professor Grenville Armitage
Director, Centre for Advanced Internet Architectures
http://caia.swin.edu.au

---

From: David Hopwood <[email-masked]>
Date: Sat, 02 Jul 2005 03:26:25 +0100

David Hopwood wrote:
> "Specification Required", it would have said so.

RFC 2780, of course.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 2 Jul 2005 14:27:54 -0500

Perhaps things have settled down sufficiently for me to express an 
opinion...

I am not an IANA weenie. But I think registries should register 
things.

We have a decent amount of running code (for example, 
http://www1.ietf.org/mail-archive/web/ietf/current/msg35953.html) that 
says our attempts to limit what gets deployed by limiting what gets 
registered don't work reliably.

It is frustrating for operators to have less clue about what's 
happening on their networks because parameters weren't registered. If 
an operator freaks out at the thought of carrying the option requested 
way back on the beginning of this thread, it would be easier to filter 
this traffic confidently if the option was registered. It would also 
be easier for an operator to figure out who is using the option, and 
how often, especially if there weren't two sets of traffic using the 
same option to mean two different things - and that is where 
unregistered deployed options will take us, especially if neither 
option generates a multi-day mail thrash on the IETF mailing list (I 
suppose THIS option will never be squatted on by anyone else - it's 
infamous, even if it's not registered).

What I would like to see is a clear distinction between IANA as a 
registry and the IETF as a protocol standards organization.

People who I respect have expressed concerns that allocating values in 
a registry for lame protocols will be confused with endorsing lame 
protocols. I'm not sure this is true, but if it is, in the past what 
we've done in similar situations is to publish RFCs like 
ftp://ftp.rfc-editor.org/in-notes/rfc1796.txt, when we were concerned 
about people thinking that all RFCs are standards.

It may be time to publish a similar RFC, with a title like "Not all 
registry allocations support wonderful protocols". That would be fine. 
I can draft something along those lines - it should be a page long, 
modulo boilerplate. If you have an opinion on this, please e-mail me 
privately.

It may also be time to add a registry policy for parameters that we 
wouldn't register, but people are deploying them anyway, just as a 
public service announcement. We could call it the "Damn the Torpedoes, 
Full Speed Ahead" policy (DTFSA), and no one could say they weren't 
warned.

I also note that one of the many "wireless is special" things I've 
seen in the past decade was the WAP Interim Naming Authority (WINA), 
now resurfacing as the Open Mobility Naming Authority (OMNA) (see 
http://www.openmobilealliance.org/tech/omna/index.htm). There are 
probably other pseudo-IANAs I don't know about. Our choke-hold on the 
parameters the world uses isn't quite as tight as it needs to be in 
order for us to use IANA as an enforecment tool.

Thank you,

Spencer

("Damn the torpedoes! Full speed ahead" is a historical reference - 
details at http://en.wikipedia.org/wiki/David_Farragut. It's also a 
killer Tom Petty album - details at 
http://en.wikipedia.org/wiki/Damn_the_Torpedoes_%28album%29)

---

From: Ned Freed <[email-masked]>
Date: Sat, 02 Jul 2005 15:03:02 -0700 (PDT)

> registered don't work reliably.

Exactly. FWIW, media types, email header field names, and charsets are all good
examples of other ways things can go wrong.

Now, the vast majority of the registries we have are ones which for whatever
reason aren't terribly popular: Additions to the registry are rare and so is
use of unregistered values. (Take a look at the list of IANA registries and
you'll find dozens of these.) We may like to think of these as registry success
stories, but getting scaling considerations "right" is easy when no scaling is
needed.

Then there are some where only a few values are registered but several other
values are in common use. A good example of one of these was the protocol name
registry used in email WITH fields: For the longest time only "SMTP" was
standardized but a small set of other values were frequently used. RFC 3865
changed that, but writing this sort of RFC and getting it through the process
turns out to be surprisingly hard, so much so that most registries with this
particular problem never get dealt with. (An nearby example of one that hasn't
been cleaned up are email VIA fields.)

Then there are the registries where there's an escape hatch for private values.
Sometimes this is sufficient to prevent use of supposed-to-be-registered values
and sometimes it doesn't. For example, most private SMTP extensions - and there
are a bunch of them - have elected to the X-prefix naming convention marking
them as private use. OTOH, email header fields that don't begin  with "X-"
abound that from context are clearly carrying private-use information. (This
problem is so prevalent that there was no consensus to continue having the "X-"
convention in RFC 2822.) Or consider media types, where the initial
registration procedures were overly onerous and where for whatever reason
people didn't like seeing "X-", so literally hunderds of unregistered values
came into widespread use, use which continues to this day.

The bottom line is that despite being informed by many years of experience we
aren't nearly as good at this stuff as we seem to think we are.

> ...

> registry and the IETF as a protocol standards organization.

Agreed. This would help a lot.

> ...

> order for us to use IANA as an enforecment tool.

Well, we like to talk about how the network we have helped create routes around
problems at many levels, but we seem to be unable to comprehend that sometimes
we're the ones that are perceived as being the problem. It is hardly surprising
given the very mixed results we've had with our own registries that other
registries have sprung up. And since I have no real expectation that we're
going to clean up our act as a result of this or any other discussion, this
sort of thing is bound to continue and even accelerate.

				Ned

---

From: Robert Elz <[email-masked]>
Date: Mon, 04 Jul 2005 14:01:02 +0700

Date:        Fri, 1 Jul 2005 15:16:09 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <p0620074abeeb3c7dc3ef@[10.0.0.171]>

  | In what way would that differ from "Specification Required"?

See below.

  | No.  That one ("Specification Required") explicitly states that the 
  | document must be permanent, readily-available and in sufficient 
  | detail so that interoperability is possible.

And where do you see "permanent, readily-available" in the IESG
approval section?

  | There is absolutely no indication here regarding what criteria the 
  | IESG should use to approve (or not approve) an IANA allocation.

Everything in 2434 is about the amount of documentation required.
Why would the IESG approval section be any different?   It expressly
talks about documentation, and nothing else.   It says the IESG can
ask for more documentation, it doesn't say that it can ask for proof
that the option won't harm X or Y, or anything else.   There's a very
old principle of interpretation that says that if something is
expressed, everything else is inapplicable (it has a Latin name, if
I thought I could come even close to spelling it, I would).

  | You have arbitrarily decided that availability of the same documentation 
  | described in "Specification Required" is the only criteria that the 

Not the same documentation.   The same kind or standard perhaps, but
without requiring anything to be publically available.   Documentation
needs to exist, to show that there's a real option (in this case) being
registered, and so that others could implement it, in the right
circumstances.   But it could be private documentation, given to
the IESG under NDA.   The section expressly says that it does not need to
be published (as an RFC).

  | I personally believe that the IESG should use the same criteria that 
  | we use for all of the other IESG decisions in the IETF (absent other 
  | direction) -- we try to decide what is in the best interests of the 
  | IETF and the Internet.

I'll leave that rat hole for another time.

  | If you disagree with that decision (although I think you 
  | should read the document first before forming that opinion), 

No, that's exactly the point.   It cannot be in anyone's best interests
for option numbers to clash.   It does not matter what the use of the
option is.  Driving people who request options into inventing their own
code, rather than having one assigned by IANA helps the internet just how?
Now in this case the group who are requesting the option may be willing
to simply do nothing (or abandon use of IPv6) rather than going to the
extreme of inventing their own option code and using it.   But in another
case, the applicant will not.

Benefit to the IETF, maybe, after all, the IETF cannot possibly allow
another organisation, that is actually producing something, where the
IETF is just talking about the need to do so, to actually succeed, can it?
That wouldn't show the IETF in a very good light.

But IANA is not a function of the IETF, it never has been.   It asks
the IETF for advice, but the "best interests of the IETF" are certainly
not something that ought be relevant in IANA assignments.

  | The working group did _not_ make a decision about whether an IP 
  | option number should be allocated _for this purpose_ (i.e. for this 
  | particular option) without requiring an IETF consensus document. 

They did, or they would have specified that as a requirement.

Obviously the WG didn't consider this particular option, or any other
future option, which didn't exist when 2780 was written.   Instead they
(really us, since the WG just proposed, the IETF approves via the last
call process) decided that it should never be a requirement (though it
is an option) for anyone to go through the IETF consensus process for
IPv6 options.

  | They delegated that decision to the IESG by including "IESG Approval" 
  | as one option in their IANA considerations section.  If they  wanted 
  | to allocate a number to everyone who produces a permanent,
  | publicly available, detailed document, they would have chosen 
  | "Specification Required".

But everyone knows that options are sometimes needed for things that
are not to be documented that way.   Having the doc checked by someone
(an expert in some cases, the IESG in others) is a reasonable way to
allow that to happen.

What do you propose doing when someone comes to you with a propietary
option they're proposing using, and asks for an option code for that
one, but who refuses to make any documentation about the option public?

  | The fact that a document gives the IESG the authority to approve 
  | allocations in a particular registry does not obligate the IESG to 
  | say 'yes' to every request that is received for that registry -- what 
  | would be the point of that?

When did anyone ever claim that was required?   I have consistently
said that I have no idea whether the option actually should have been
registered.   What was wrong was the method used to reject it, not that
it was rejected.

  | IMO, this 
  | is not a case of the IESG over-exercising our authority, it is a case 
  | of us being conservative about exercising our authority in a complex 
  | situation.

There is nothing complex about this at all.   IPv6 options can be
inserted into any IPv6 packet by anyone, with or without any specification,
anywhere, of what the options mean.   That includes both desestination
and hop by hop options.   Whether the option will do anything useful or
not is another question, but they can certainly be added.

The only question here is whether someone who wants their particular
option listed in the registry, so others can avoid conflicting with it
should be able to do so.

What is complex?

No-one is asking you to approve their particular protocol.

The problem is that the IETF, and the IESG in particular, sees a protocol,
sees it is planned to be used with internet related protocols, and so
perhaps on some part of the internet, and decides "that's ours, we must
be the ones to decide whether that is any good or not, now how do we force
that to happen?"

That's intolerable.

kre

---

From: Keith Moore <[email-masked]>
Date: Mon, 04 Jul 2005 06:50:07 -0400

> be the ones to decide whether that is any good or not, now how do we force

No, that's their job.  Or at least, close to their job.  IP is IETF's 
protocol.  IETF is where the vast majority of expertise in IP resides. 
An IP extension developed entirely outside of IETF has a very high 
probability of causing problems for the Internet.  It's naive to have 
this idea that says "anybody ought to be able to extend IP however they 
want, and we'll let the market sort things out."  It doesn't work, any 
more than the market works to prevent the spread of a virulent disease.

Keith

---

From: "Nicholas Staff" <[email-masked]>
Date: Mon, 4 Jul 2005 23:29:01 -0700

Keith (and anyone interested in this thread that doesn't have me on ignore),

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.

I would think if the extension's deemed good then we'd want to avoid
conflicts and if it's bad then we'd want it to wear the scarlet letter -
both of which would be accomplished with the assignment.  Then decisions can
be made as to it's worth (or lack thereof) and it's assignment can be
treated accordingly.

Keith, you said:

"It's naive to have this idea that says "anybody ought to be able to extend
IP however they want, and we'll let the market sort things out.""

The thing is, anyone can extend IP however they want, all we're advocating
here is the ability to track their changes.

Best regards,

Nick Staff

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Keith Moore
Sent: Monday, July 04, 2005 3:50 AM
To: Robert Elz
Cc: Margaret Wasserman; [email-masked]; grenville armitage
Subject: Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of
an IPV6 Hop-by-hop Option)

> The problem is that the IETF, and the IESG in particular, sees a 
> protocol, sees it is planned to be used with internet related 
> protocols, and so perhaps on some part of the internet, and decides 
> "that's ours, we must be the ones to decide whether that is any good 
> or not, now how do we force that to happen?"
> 
> That's intolerable.

No, that's their job.  Or at least, close to their job.  IP is IETF's
protocol.  IETF is where the vast majority of expertise in IP resides. 
An IP extension developed entirely outside of IETF has a very high
probability of causing problems for the Internet.  It's naive to have this
idea that says "anybody ought to be able to extend IP however they want, and
we'll let the market sort things out."  It doesn't work, any more than the
market works to prevent the spread of a virulent disease.

Keith

---

From: grenville armitage <[email-masked]>
Date: Tue, 05 Jul 2005 20:29:25 +1000

Brian E Carpenter wrote:

> grenville armitage wrote:
> ...
> 
>> of protecting the Internet from poor, TCP-unfriendly end2end algorithms. 
> 
> 
> Who's "we"? The IESG said that the IESG wasn't going to approve a 
> codepoint,
> and that the only way to get it approved would be IETF consensus.

My copy of the email announcing the IESG's decision to decline the
option codepoint assignment request ended with the text: "So, the IESG
declines the assignment request and recommends against pursuing this
proposal within the IETF."

It is a shame that the sentence didn't end immediately after the
words "....declines the assignment request."  The rest of the sentence
(in the context of the editorialising which preceded it) has a distinctly
chilling feel.

(I'll leave this thread now to people who can actually change things. Just
wanted to, perhaps, ground the discussion in its origins.)

cheers,
gja

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Jul 2005 11:49:52 +0200

Pete Resnick wrote:
...
> evaluate much of anything. And I think that is part of the concern you 
> are hearing expressed in the objections to the decision process.
> 

However, BCP 95 is fairly clear:

   1. Mission Statement

     The goal of the IETF is to make the Internet work better.

and I presume that the IESG is expected to steer accordingly.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Jul 2005 11:56:49 +0200

> The argument is that the IESG used the wrong criteria in making

Since neither 2434 nor 2780 lays down any criteria, I don't
understand how to measure "wrong."

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Jul 2005 11:43:51 +0200

> of protecting the Internet from poor, TCP-unfriendly end2end algorithms. 

Who's "we"? The IESG said that the IESG wasn't going to approve a codepoint,
and that the only way to get it approved would be IETF consensus. IETF review
might be considered a good way of attempting to protect the Internet; it's
the only lever "we" have, anyway.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Jul 2005 11:32:12 +0200

Robert Elz wrote:
...
> Also remember that "no consensus" in an issue like this, really needs to
> mean "no authority" - if you cannot get at least most of the community to
> agree with the IESG position, then the IESG cannot just claim the
> authority and say "there is no consensus that we should not have it".

I don't believe that is true in this case, as long as RFC 2780 is in force.
Especially since there is a clear path for Larry Roberts to ask for
IETF consensus, which by definition would overrule the IESG.

     Brian

---

From: Bill Manning <[email-masked]>
Date: Tue, 5 Jul 2005 08:47:03 -0700

> IETF consensus, which by definition would overrule the IESG.
	just for my edification, how is IETF consensus determined,
	esp. when there is a need to "overrule the IESG"?  in other
	contexts, this type of thing is done by a vote of the membership,
	but last i checked, there are no members of the IETF.

--bill

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 05 Jul 2005 14:49:03 -0400

On Friday, July 01, 2005 11:32:41 AM +0200 Harald Tveit Alvestrand 
<[email-masked]> wrote:

> "IESG review" indicates that the writers of the IANA considerations
> section thought that the IESG was able to come to a correct decision
> *without* having to ask for an IETF consensus.

I don't entirely agree.  The definition of "IETF Consensus" in RFC2434 
requires an RFC developed through the IETF process _and approved by the 
IESG_.  There is no cookie-cutter policy defined in that document which 
requires consensus of the IETF but _not_ approval of the IESG.  If someone 
wanted to set a policy like that for a registry, they'd have to state it 
explicitly rather than incorporating one by reference.

On the other hand, my reading of the definition of "IESG Approval" is that 
approval by the IESG is required, but not any particular means of getting 
that approval.  The simple path of "requestor asks IANA; IANA asks IESG; 
IESG says yes or no" works fine, but so does following the procedure 
Margaret just suggested to Larry, and so does going through the full 
standards process.

>   either abandon the practice, modify the practice or make it a standard

I like this, except that I'm not sure 1 year is a long enough period to 
gather useful data for this experiment.  OTOH, I don't really know how 
frequently the IESG sees requests like this, so I'll defer to those who do.

> I think that a blanket retrofitting of a new meaning on the "IESG
> approval" IANA considerations is a thoroughly bad idea.

Agree.

-- Jeff

---

From: John C Klensin <[email-masked]>
Date: Wed, 06 Jul 2005 05:01:46 -0400

--On Tuesday, 05 July, 2005 08:47 -0700 Bill Manning
<[email-masked]> wrote:

>> Especially since there is a clear path for Larry Roberts to
>> ask for IETF consensus, which by definition would overrule
>> the IESG.
>> 
>>     Brian
>> 
>> 

As far as I can tell, there are only two ways:

	(i) We ask the IESG if they think they have been
	overruled.  In the nasty and impolite old days, the
	question was often stated at open plenaries, with at
	least the possibility of [real or virtual] over-ripe
	fruit moving through the air in the IESG's direction.
	Today, when a larger percentage of the community seems
	either inclined to suffer in silence or disinclined to
	speak up, the message from the community probably needs
	to be much more clear, and the consensus stronger, for
	the IESG to reach that conclusion.
	
	(ii) Someone appeals, essentially asking the IAB whether
	the IESG has been overruled.  The problem with this path
	is that, in the last decade, the IAB has tended to be
	deferential to the IESG's determinations about community
	consensus.  That determination is often hard to make,
	the various procedural documents appear to assign the
	job of making it to the IESG, and the IAB has tended to
	want to look at procedural issues on appeals and to not
	review the IESG's judgment calls.

Perhaps, in both cases, that is how we want it.  If it is not,
perhaps this is the time to start making procedural changes.
But, in either case, the difficulties implied by the above are
the greatest part of what makes statements such as the last
clause in the IESG's rejection of the Roberts registration
request particularly troubling: if the IESG has already
concluded the community consensus is sufficiently unlikely that
they recommend against trying to obtain it, the amount of
consensus, and ways of demonstrating it, that would be needed to
get them to decide their conclusion was incorrect and they had
been overruled may set an impossibly high barrier.

     john

---

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

> As far as I can tell, there are only two ways:

Middle posting: I think John and Bill are missing the
primary mechanism which is *trusting* the relevant AD to
call the IETF consensus honestly, even if s/he doesn't
agree with it. That shouldn't be hard to accept, since
we extend the same trust to every WG Chair.

If the AD makes the wrong call, then complaints, appeals and even
recalls are available.

    Brian

---

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

> proposal within the IETF."

Which does not prevent the proponents from doing so.

    Brian

---

From: [email-masked]
Date: Wed, 6 Jul 2005 16:50:05 +0000

> If the AD makes the wrong call, then complaints, appeals and even

	if John is correct, and your statements are correct,
	then IETF consensus kind of depends on IESG tacit
	approval...  and why would the IESG approve something
	that would "second-guess" or "overrule" a choice they
	already made?  Me thinks that we have a -VERY- high
	threshold to challange an IESG fiat.  And this may be 
	bad for the continued health/relevence of the IETF.
	Or not...  development can and does occur in other fora.
	The IETF may not see the work until it is cooked.
--bill