Subject: Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

From: John C Klensin <[email-masked]>
Date: Mon, 27 Jun 2005 06:32:21 -0400

--On Sunday, 26 June, 2005 09:28 -0700 Allison Mankin
<[email-masked]> wrote:

> Hi, John,
> 
> There are two different IETF IANA registry goals (at least):
> 
> -  maintenance of protocol parameters by the IANA for
>    keeping the namespace free of conflict
> 
> -  policy for the extension of an IETF protocol, which
>    is expressed by the rules governing the
>    issuing of new codepoints for particular elements
>    in that protocol.
> 
> In the message the IESG sent about Roberts' request,
> we pointed out that the IPv6 Hop by Hop option extensibility 
> is governed by a BCP, RFC 2780, which requires an IETF document
> (standards track or other), or in a fallback, IESG review.
> This is the action the IESG has taken.  
> 
> Your message about the the registries being largely for
> prevention of conflicts and so on is true for some registries,
> but for many others there's an extension policy in place too.
> 
> For many protocols, there's an RFC that states a requirements
> for some or all the codepoints for an IETF docoument before
> IANA allocations. You can see these requirements in the IANA
> pages now.  These requirements reflect views by the developers
> that the protocol needed engineered coherency, an IETF review
> process that would ensure architectural considerations when
> the extensions are made.
> 
> (The IETF is here for engineering the protocols, after all).

Allison, I'm generally supportive of that view.  I've actually
been responsible for writing some of those IANA considerations
sections that require standards-track actions.   In the light of
this situation and a few recent other ones, I have modified my
historical view somewhat and would encourage the IESG to do some
similar rethinking.

Let's consider two cases.  In one case, the IETF finds an idea
aesthetically unattractive.  The community concludes that, were
the IETF to try doing some work in the area covered by the
proposal, we could do a better job... and, perhaps, someday, we
might.  But registering the option cannot be demonstrated to
cause a significant interoperability threat: at worst the
associated protocol extension is just dumb.  In the second case,
the nature of the protocol and extension mechanism involved is
such that a proposed extension actually would cause an
interoperability threat or we can demonstrate that the proposed
extension would simply not work. For the second case, it is
probably reasonable to say "no registration".  I suggest that,
while the number of instances of that case is certainly not
zero, it should be small and that it should be a design goal for
us to minimize them: in a way, having a situation in which an
unapproved extension can break a protocol violates much of what
we claim to know and believe about robustness.

But, for the first, I'm getting more and more anxious about
rejecting a registration request.  That is largely because, if
the applicant still feels that the idea is a good one, we've got
lots of unfortunate experience that he or she will just ignore
the registration requirement, squat on a code, and proceed as if
the allocation had been made. Worse, that applicant may not come
back and ask the next time, depriving the community of a
heads-up and the applicant of potentially-valuable IETF review.

I've said part of this in an earlier note but I think we've got
to get past what I've come to think of as considering the IETF
as some sort of Protocol Legislature that makes Protocol Laws
with the assumption that people will follow those laws or the
Protocol Police will show up and drag them off for punishment.
We make voluntary standards.  Those standards are followed or
not based on our powers of persuasion that there is community
support for them and that the community support is meaningful
because it results from adequate review, conclusions based on
that review, and persuasive documentation.  Reliance on
authority-assertions is a bad idea, not only because no one
individual or group can claim such authority by right, but
because the Protocol Police aren't out there to enforce the
authority.   If someone can ignore our conclusion that an idea
is dumb and go ahead and deploy it anyway, we gain nothing and
create risks by not assigning an option number to the dumb idea
-- risks that are primarily the consequence of not being able to
tell in practice what options are being used.

So I now believe that we should have provision in some of those
registries for notes that say "The IETF has concluded that the
option or extension represented by this value is a really rotten
idea.  Explanation in RFC NNNN (or the IESG note at <URL>)".
That would be a good move because it would give potential users
of the option an easily-accessible indication that they should
consider the issues raised carefully before deciding to deploy
the option.  Denying the registration, except in the
second case above, may turn into a foolish and unnecessary
threat to interoperability.

To state that somewhat differently, since we cannot effectively
prohibit the deployment of an extension or option of which the 
IETF disapproves, the best things we can do for the Internet are
make it as easy as possible to identify the use of the extension
so it can be effectively quarantined and to make information
about why we consider it a bad idea readily available.
Ironically, both of those goals are most strongly aided by
registering the extension and assigning an appropriate
identifier, rather than rejecting registration requests and
hoping the idea goes away. 

While the situation with the Hop-by-hop proposal appears closer
to the first group of cases than the second, it appears to me to
be
complicated by two other factors:

(i)  Apparently, this registration request represents work being
carried on in other standards bodies and we have a
presumably-good liaison relationship with one of them.  The IESG
should, I believe, consider whether Dr. Roberts should be
encouraged to discuss this proposal further with them, whether
we should have a WG-level dialogue open with them about the
appropriateness of the protocol design, and, if a registration
request is made, whether that should come across the liaison
channel as a registration request in support of _their_
protocol.  At one level, that sequence would be nothing more
than a procedural nicety.  But at another, if this is a
standards body whom we recognize and which recognizes us, our
failure to make option numbers available for protocol extensions
which we dislike but can't talk them out of on technical grounds
could rapidly lead the Internet to competing and conflicting
registries for the same protocol parameters.   That isn't good
in the address space; it is much less good in these name spaces.

(ii) For the reasons above and in my earlier note, I think the
IESG, and the IETF more broadly, must exert great caution in
rejecting a registration request and must exert that caution in
public.   For example, the language of 2434, and the language of
2780 with regard to the registry in question, indicates that the
IESG may approve one of these requests.  They do not appear to
me to indicate that the IESG may definitively reject it.  It
would be perfectly reasonable, IMO, for the IESG to say "You
requested that we exercise our discretion and register this.
After reviewing it, we believe that the protocol option itself
will be controversial in the community and that it needs
significantly more review and discussion, either to refine it or
to adequately clarify and document the reasons why it may be
problematic.  So we cannot approve the registration request at
this time but encourage you to open a dialogue with the relevant
WG(s) in the hope that you will be able to find common ground
and convince each other, or at least educate each other."
But, instead, as far as I can tell, the IESG communicated a "go
away and don't come back" message.  My knowledge is, of course,
poor because the nature and unfolding of the IESG discussions,
what the applicant was told, and what the IESG intended and
intends are appearing only incrementally, supported by poor
minutes and statements with "may not represent consensus"
disclaimers attached.  For a registration request and for the
reasons given, I (and apparently others) believe that "go away
and don't come back" is a message that should be delivered only
with strong indications of IETF community consensus and not
based only on the opinion of the IESG about what they consensus
might be.

>> Historically, we maintain registries of various protocol
>> parameters, not to endorse them, but to prevent conflicts in
>> the meaning/ interpretation of such things.  [snip...]
> 
> Note there are hundreds of registries!  One summary does not
> fit all. Also, endorse is a very loaded word.  They express
> RFC 2434 / BCP 26 policies.  

Actually, I think it is possible to state, or restate, guiding
principles, even if the details for those registries are
different.  In the interest of focusing discussion, an
Internet-Draft that attempts to do just that will be submitted
for posting later today.

   john

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

---

From: Thomas Narten <[email-masked]>
Date: Mon, 27 Jun 2005 13:28:24 -0400

On one point (since it was mentioned in other thread as well):
> me to indicate that the IESG may definitively reject it.

What 2434 says about "IESG approval" is:

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

(as an author) I agree that the "must" wording is poor and would be
better replaced by something like "may".

I would also add wording saying that "IESG Approval" is intended for
unusual circumstances, with the preferred approval through something
involving IETF review (e.g., "Standards Action").

In practice, what I have been telling folk over the years (when
advising about writing IANA considerations sections) is that including
"IESG Approval" is a useful thing to do to deal with unanticipated
circumstances -- it leaves the door open to convincing the IESG that
the documented approval paths are a problem in particular cases. I
suspect that a lot of existing RFCs use the above _in_ _addition_ _to_
specifying alternative approval methods.

Finally, in all the time I was on the IESG, I can't right now recall
the IESG ever getting an assignment request via the above mechanism,
much less approving one. So the above has not been used in practice
very often, if at all.  Instead, folks generally know (or were
advised) to submit an ID instead and get it reviewed by an appropriate
WG rather than making a request directly to the IESG.

This all suggests that the case at hand is rather unusual and does not
reflect the common case. The more common case is to have requests
reviewed by the IETF community (or experts peforming reviews on behalf
of the community). But as has been noted, in this case the IETF does
not have open access to the proposal, so the community as a whole
cannot evaluate it. Thus, the IESG was forced into the role of having
to make a decision. Somewhat of a no-win situation, it seems to me.

Thomas

---

From: Ned Freed <[email-masked]>
Date: Mon, 27 Jun 2005 10:43:36 -0700 (PDT)

> hoping the idea goes away.

Very nicely put, John. I completely agree. And to the extent we have "running
code" in this area, I believe it supports this view.

> to the first group of cases than the second, it appears to me to be

> ...

In the specific case of the current proposal, my view is that the reasons the
IESG gave for rejecting this proposal put us all out  on a very shakey limb,
and the added comments about the likely outcome of this work being made an IETF
work item of some sort have no limb at all underneath them.

I also have another concern here that I don't believe anyone else has
mentioned. In response to criticism of the lack of openness of the process used
to arrive at this rejection, it has been asserted that it had to be this way
due to the lack of availability of a specification for review.

As many of you no doubt know, I have long been an advocate of having freely
available specifications whenever possible. I have frequently pushed back on
IETF that involves references to outside work that isn't readily available.
These concerns have usually been dismissed with responses like: "There's no
rule against it" or "The specification is available to those who really care"
or "There's nothing we can do to improve the situation so live with it". And in
fact we have numerous specifications which depend on such references. In fact
while I was on the IESG on at least one occasion I paid $ in order to obtain
a specification I felt I needed in order to carry out proper review of
something.

After all this I find it quite curious to see the lack of a publicly available
specification used to justify the way this was handled, when in so many other
cases we simply shrugged and moved on.

Even worse, the fact of the matter is the specification is publicly available:

  http://www.packet.cc/IPv6Q-IETF-2A.htm

No googling necessary; this URL was included in the original submission
request.

Now, the request also stated that this is not the final form of the
specification that was submitted to the ITU. But it seems very unlikely that
the specification has changed sufficiently that the earlier, publicly available
draft couldn't be used for review purposes. But rather than speculate on that,
since we have the author of the proposal here, I'll just ask a direct question.
Dr. Roberts, do you believe there have been sufficient changes between the
version posted at the above URL and the ITU submission that it isn't reasonable
to decide things based on the public version? And if there have in fact been
sufficient changes, would it be possible to make a version with those changes
available for public review?

> Internet-Draft that attempts to do just that will be submitted

Agreed again. I'm looking forward to seeing your document.

				Ned

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 27 Jun 2005 11:34:35 -0700

Ned,

> code" in this area, I believe it supports this view.

What was the reason(s) the request was made for an assignment
that required IESG Approval, rather than either Specification
Required or First Come First Serve ?

Yakov.

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Jun 2005 12:37:10 +0700

Date:        Mon, 27 Jun 2005 13:28:24 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | What 2434 says about "IESG approval" is:
  | 
  | >       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).
  | 
  | (as an author) I agree that the "must" wording is poor and would be
  | better replaced by something like "may".

I wouldn't object to that change.  As worded, it may imply that the IESG
has no option but to approve any request made to it, which I would agree
was never the intention.

However:

  | I would also add wording saying that "IESG Approval" is intended for
  | unusual circumstances, with the preferred approval through something
  | involving IETF review (e.g., "Standards Action").

I would certainly do nothing at all like that, and would not agree to
any such change.

2434 has a list of "example" policies for RFC authors to select from,
that is, overall, so comprehensive, that almost no-one bothers to
think up any others.

In 2434 there's the complete range, from "Private Use" (which amounts to
"no-one cares, do whatever you like, no registration possible" through
"FCFS" (anyone can ask, the first to ask for a particular value, gets it),
all the way up to "IETF standards action" (only specifications approved
by the IETF as being "good things" can get values assigned).

The working group that defines the field in which the value is to
be used gets to select which mechanism is appropriate to use for
that particular field (with IETF review via last call and all of
that of course).

There are 5 main levels of requirement that make sense,
	1. anything goes (no registration)
	2. anyone can register (fcfs)
	3. anything properly documented can be registered
	4. anything published as an RFC can be registered
	5. anything that is on the IETF standards track can be registered

These give increasing levels of "review required" to be applied
to the particular field, from none at all (the first two, except
that 2 at least requires a contact point, and general description
of purpose), through "must be documented" (basically so others
can implement it) but with no rules as to how that documentation is
necessarily done, to any RFC, so now we have rules about what the
doc must be, and how it gets published, but informational RFCs and
even experimental, qualify, and will generally mean that nothing that
is actually harmful to the protocol stack will be included, and finally,
standards action, which implies IETF approval that the proposal that
uses the new code is a "good thing" and worth of being added to the
stack.

In 2434 terms those more or less equate to
	1. Private Use, and Hierarchical Allocation
	2. First Come First Served
	3. Specification Required (maybe Expert Review)
	4. IETF Consensus
	5. Standards Action

The question then arises, just where does "IESG Approval" fit
in this scheme of things, as it is the one being used here.

Your suggestion is that it is a last resort escape clause, almost a
way for the IESG to decide to ignore the rules for special cases
where they would cause hardship.

But that's not supported by any evidence whatever.   First, that isn't
what 2434 actually says, it doesn't even hint that.  Rather, IESG Approval
is placed in the list of increasing "reviewedness" right between "specification
required" and "IETF Consensus", it isn't held to the end as a last resort,
or placed in a separate section.

What's more, no exception clause like that is required, RFC2026 already
has the "Variance Procedure" by which the rules can be waived, or temporarily
altered, in circumstances that really require that.

So, my interpretation would be, that "IESG approval" means just what it
appears to mean in 2434 - that is, something that ranks between specification
required, and IETF consensus.   That is, it expressly does not require
the IETF to agree that the proposal is even good enough to publish as an
experimental protocol.

We get now to what should be involved in the approval part of "IESG Approval".

The IESG seems to be taking that to mean that they can do whatever they
like, and if they don't like the the specification, they can, and some have
said, even should, or must, reject the application.

That's clearly nonsense.   You quoted the paragraph above, but to save people
scrolling back through this long message, I will quote it again...

That is, what is going on here, is clearly (to the point where it could
hardly be any clearer) all about documentation, and what documentation
is available.

Note, it quite clearly says "there is no requirement that the request be
documented in an RFC" - so the current suggestions that the proposal be
written up as an I-D, and submitted to (some unknown) IETF working group
for consideration are patently not required for an allocation under
this procedure.

As it says in the paragraph quoted from 2434, the IESG's role here is
to make certain that there is adequate documentation, and to request
more documentation, or other required supporting materials, as needed,
to satisfy the request.

Absolutely nothing about whether the request is for a protocol that
anyone on the planet cares anything about - were I to properly document
an option that would be used in the HBH options field and which would
cause routers processing the option to all explode with maximum
violence, the IESG has no grounds whatever for refusing to register
an option code for that option.   Now, I don't see many router vendors
being ready to implement my "explode and kill the network, and any
people standing in the vicinity" option (though I suspect there are
plenty of people who'd appreciate it if I'd test my option for
effectiveness), but there's no reason whatever for it not to be
allocated an option code.

The working group, when 2780 was written, explicitly did NOT require
standards action for new option codes to be registered, it didn't
even require publication of an RFC (though either of those are other
ways to obtain option codes).   All it requires is IESG approval, and
that means, IESG approval that the documentation is adequate, not that
the proposal is a good one.

  | This all suggests that the case at hand is rather unusual and does not
  | reflect the common case.

No-one has ever suggested that this is a common case.   What is usually
done, in the common cases, is therefore irrelevant.   This is clearly an
unusual case, everything about it is unusual.   Being unusual doesn't
mean that we then have to attempt to force it to act just like all the
normal cases.   Nor does it mean that we should reject it because it
is unusual, or because someone has their nose out of joint that anyone
would dare to step on what the IETF (or at least the current IESG) regards
as its private turf.

What the IESG did in this case was clearly way out of line.   And once
again, I don't care what the protocol is that plans on using this option
(I still have not looked at the web site, where, contrary to what some
people keep saying, the use of the option is apparently documented for
anyone to see) as it simply does not matter what that protocol is.

Nor do I have any idea whether that documentation is actually sufficient to
allow the option to be allocated.   Nor do I know if the option requested
might happen to be an (almost) duplicate of some other option that exists
(though there are currently so few, that being a duplicate would seem
unlikely).   So, I am not saying, and never said that the IESG was required
to approve the application.

But, what I continue to claim, and nothing whatever that I have heard or
read has in any way made me doubt, that the IESG's actual actions, and
certainly their public response to the request, was way outside their
authority, and totally inappropriate, and MUST be corrected, either by
the IESG, or upon appeal, by the IAB.

If that doesn't happen, I would expect, and even encourage, the applicants
to simply pick their own option code, and inform IANA what they picked,
and are consequently using.   At least that way, IANA can use its
discretion in allocating numbers to future requests to avoid colliding
with this one.   The lack of the existence of this option in the IANA
registry will be something for which the (current) IESG will be totally
responsible - the applicants have done everything that the procedures
require them to do (or at least, there is currently no evidence to the
contrary).

kre

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 28 Jun 2005 09:37:02 +0200

(Changing the subject and flushing most of the CCs including the IESG. They 
will probably read it anyway.)

As the other co-author of 2434, I want to point out that the term "IESG 
Approval" was not invented by 2434.

In fact, a simple-minded grep for "iesg approval" shows that RFC 2048, the 
first MIME registration procedures, was the first to use it, 2 years 
earlier; that only shows where I cribbed the term from, I guess.

Quote from 2048:

> 2.3.2.  IESG Approval
>
>    Media types registered in the IETF tree must be submitted to the
>    IESG for approval.

(Historical note: This document replaced RFC 1590, which did not specify a 
role for the IESG. 1590 was, AFAIK, done without IETF discussion. The 
change in procedure in 2048 was definitely done with IETF discussion. Times 
change.)

In keeping with the general tendency to let things be handled by others 
when they can be handled by others, I think changing requirements from 
"IESG approval" to "Expert Review" is a Fine Thing (and think that the IESG 
should have the right to do that on its own, even when documents say "IESG 
approval").
But I like the text describing the "IESG approval" part in 2434 just the 
way it is.

What *I* would like to add is more guidance on how to write IANA sections 
where you have multiple ways to register something; I dislike sentences 
like this one:

>    assignments .... follow an Expert Review, IESG Approval or
>    Standards Action process.

because it does not show what the normal procedure is expected to be, or 
what is a reason to choose one and not the other.

                          Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Jun 2005 00:16:56 +0200

> Required or First Come First Serve ?

RFC 2780 (BCP 37). If there had been an I-D it would have been
easier.

    Brian

---

From: "Dr. Lawrence G. Roberts" <[email-masked]>
Date: Mon, 27 Jun 2005 20:57:38 -0700

Ned,
The document on my packet.cc web site is certenatly close enough to the 
final ITU documents attached (which I sent to Brian) that there should be 
no trouble reviewing it for the concepts. The attached documents are the 
latest ITU documents and the TIA 1039 document is identical in content. The 
difference in them from the packet.cc document is in the addition of IPv4 
which is not at issue and does not depend on an option field code 
assignment. Making these later ones publicly available can be considered. 
But it may take awhile. Meanwhile, the copies above were available to the 
committee since I sent them to Brian..
It is hard to convert these documents to ACII text quickly to put them in 
IETF format. That was done once at packet.cc and the option field is for 
IPv6 which is in all the documents.
Larry

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Jun 2005 07:39:35 -0400

--On Tuesday, 28 June, 2005 09:37 +0200 Harald Tveit Alvestrand
<[email-masked]> wrote:

>...
> In fact, a simple-minded grep for "iesg approval" shows that
> RFC 2048, the first MIME registration procedures, was the
> first to use it, 2 years earlier; that only shows where I
> cribbed the term from, I guess.
> 
> Quote from 2048:
> 
>> 2.3.2.  IESG Approval
>> 
>>    Media types registered in the IETF tree must be submitted
>>    to the IESG for approval.

Yep.  Ned, Jon, and I did it.  I can't remember precisely who
the original guilty party was for either the term or the
concept. The multiple-tree idea in this space was, I think,
originally mine but the rules for getting into the trees was, if
I recall, very much group discussion.  We did it very 
deliberately, and were deliberately vague about the procedure
IESG was to use.  And it was not about document completeness
review, it was about content-based approval of whether or not
the IESG liked that content.  We didn't feel a need to comment
on the adequacy of documentation bit because we could not
believe IESG would sign off on something in the IETF tree that
was incompetently described and IANA was still making decisions
that would have produced pushback on such a thing if IESG
somehow let an obviously-weak definition slip through.

_However_, there are two rather special properties of the
concept of IESG review as it appeared in 2048:

	(1) If the IESG said "no", it wasn't "no, you can't
	register this thing" or "no, you can't use it".  Instead
	(assuming competence of documentation), it was "nope,
	not IETF tree, register it in one of the other trees).
	Note that registration in the some of the other trees
	was (and is) extremely permissive: in 2048, and as this
	has evolved in its predecessors, the review required for
	the others is, at most, "someone besides the applicant
	needs to look at this, and you need to pay attention to
	what they say before registering.  So, what the IESG
	review was determining was not "register or not" but
	whether registration could occur in a particular tree or
	category. The distinction between "determine category"
	and "determine registration" is discussed in more detail
	in section 4 of draft-klensin-iana-reg-policy-00.txt --
	I recommend you have a look at it when it is posted and
	see what you think of it.
	
	(2) We introduced the term to include _all_ types of
	IESG review and approval, including the entire range
	from "IESG looks at it, nods approvingly, and tells IANA
	to go ahead" to "standards approval".   The reason for
	the flexibility was primarily so the IESG could decide
	that something was far enough along in development or us
	in the IETF community to belong there and, in
	particular, that a type specified in an I-D that had
	received wide discussion could be approved long before
	the I-D itself made it through the process and to the
	RFC Editor.  And the notion was clearly one of the IESG
	determining, albeit informally and without requiring a
	formal Last Call, the general direction of IETF
	consensus on the matter.   At least in retrospect, we
	were relaxed about that because the media type name
	space is not scarce and, because there were other trees,
	inappropriately registering something in the IETF tree
	or not doing so would not be of earthshaking
	consequence. 

Now -- personal opinion -- from that perspective we should
probably have been a bit more explicit about what criteria the
IESG was expected to use for that review.  Although it does it
in extremely general terms rather than in the context of one
registry, draft-klensin-iana-reg-policy-00.txt attempts to
remedy that omission.  More important, in retrospect, when you
picked the term out of context and defined it in 2434 without
criteria and in the absence of alternate registration trees,
that might not have been A Good Thing.  But, probably, you
assumed that any specification that invoked that definition from
2434 would define criteria and procedures to the degree needed
by the registry involved.  From that perspective, the disconnect
may have occurred with 2780, or we may have just drifted our way
into a problem in which, IMO, the "signoff on definition
quality" which applies generally to registrations and becomes
more important the more important the registration is got
confused with "approval of content" which is appropriate only
for choices among multiple-tree situations.

Again, draft-klensin-iana-reg-policy-00.txt attempts to focus
this discussion by elaborating on the model that underlies my
remarks and, I believe, those of several others.  If the
community agrees with its analysis and recommendations, perhaps
we can dig ourselves out of this series of disconnects.

>...
> In keeping with the general tendency to let things be handled
> by others when they can be handled by others, I think changing
> requirements from "IESG approval" to "Expert Review" is a Fine
> Thing (and think that the IESG should have the right to do
> that on its own, even when documents say "IESG approval").
> But I like the text describing the "IESG approval" part in
> 2434 just the way it is.

To preview what would otherwise be a discussion on the new I-D,
here we disagree, for two reasons:

	(i) For some registrations, especially those for which
	there are no alternate registration categories and where
	unidentified use of mechanisms might lead to operational
	problems, "IESG approval" may be appropriate, but IESG
	non-approval must never mean "no, you can't register it".
	
	(ii) For situations in which "IESG review" is actually
	intended to convey a lightweight form of IETF approval,
	substitution of the judgment of an individual for an
	IESG determination of IETF consensus (however
	lightweight that determination process) is completely
	inappropriate.  Expert Review is a mechanism for
	determining adequacy of definition and for managing a
	feedback process to submitters, it is not as substitute
	for community consensus (however rough) about quality or
	desirability, and must not be permitted to become a
	substitute for such consensus.

Four-line summary:

	  We can reasonably delegate a determination of
	definitional adequacy to an individual, but decisions
	about "good" or "bad", or recommendations to use or not
	use something, require community consensus.

 john

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 28 Jun 2005 14:37:17 +0200

> 	non-approval must never mean "no, you can't register it".

Two examples of "refusal to register"..... and I don't think the 
distinction between the IESG and a designated expert really matters in 
order to discuss the principle.

1) The language tag reviewer (a designated expert) rejected the tag 
"es-americas" after due debate on the ietf-languages mailing list.
(Debate led to the same functionality now being registered as "es-419". 
That namespace also allows for use of "x-" names.)

2) The MIME type reviewer (another designated expert) has steadfastly 
pushed back on attempts to use what's effectively content transfer 
encodings as MIME types - the last example is the debate on "yEnc" in 
USEFOR. (Here, too, x- names are allowed)

In both these cases, I think that the designated experts have been doing 
their jobs.
I have no strong opinion about the IPv6 hop-by-hop header in question. But 
I don't want to (effectively) remove the ability to refuse registration - I 
think we'll pay a high price for that later.

                    Harald

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jun 2005 08:40:07 -0400

My personal opinion is that it's quite reasonable to require IESG 
approval of an IP-level option.  IMHO the IESG should solicit public 
input before making such a decision, probably in the form of a Last 
Call.  But the potential for harm is such that somebody needs to have 
the ability to say "no".  Or to put it another way, IMHO we need both 
convincing evidence of technical soundness, ideally supported by 
analysis, and a compelling argument of benefit for the Internet 
community, to justify adding a new option to the IP layer.  We already 
have too much variation in the operating environment from one network to 
another.

Keith

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Jun 2005 08:48:26 -0400

Harald,

The presence of the "X-" option, and the fact that it can be
used among consenting parties without loss of function, puts
both of the cases you mention into the area of "refusal means a
different choice of category" not "refusal encourages the
behavior to occur without proper identification".   See the I-D
when it is posted.

    john

--On Tuesday, 28 June, 2005 14:37 +0200 Harald Tveit Alvestrand
<[email-masked]> wrote:

> 
> 
> --On tirsdag, juni 28, 2005 07:39:35 -0400 John C Klensin
> <[email-masked]> wrote:
> 
>> To preview what would otherwise be a discussion on the new
>> I-D, here we disagree, for two reasons:
>> 
> Two examples of "refusal to register"..... and I don't think
> the distinction between the IESG and a designated expert
> really matters in order to discuss the principle.
> 
> 1) The language tag reviewer (a designated expert) rejected
> the tag "es-americas" after due debate on the ietf-languages
> mailing list.
> (Debate led to the same functionality now being registered as
> "es-419". That namespace also allows for use of "x-" names.)
> 
> 2) The MIME type reviewer (another designated expert) has
> steadfastly pushed back on attempts to use what's effectively
> content transfer encodings as MIME types - the last example is
> the debate on "yEnc" in USEFOR. (Here, too, x- names are
> allowed)
> 
> In both these cases, I think that the designated experts have
> been doing their jobs.
> I have no strong opinion about the IPv6 hop-by-hop header in
> question. But I don't want to (effectively) remove the ability
> to refuse registration - I think we'll pay a high price for
> that later.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 28 Jun 2005 16:12:37 +0300

Harald,

>>to refuse registration - I think we'll pay a high price for
I tend to agree. To me, "IESG Approval" in an IANA
considerations text means that we expect the IESG to
think about the allocation and its impacts, and to make
a decision -- one way or the other. Not an automatic
refusal, not an automatic granting. And not something
based on just the availability of space -- otherwise we could
have written FCFS in the text. Looks like the IESG did
its job here.

Having said that, I think the hbh header request deserves
serious consideration. I have not reviewed the proposed
scheme myself, so I can't say what the right decision would
have been. In any case, it seems fair to write it up as a
draft so that we can discuss more widely.

In terms of strictness of allocation policies, stuff in IPv6
headers seems more important to guard than something
in application layer protocols. Nevertheless, its easy to
err on either side in the policies. Make it too easy, and
we end up with potential interoperability issues. Make it
too hard, and people find other, perhaps worse ways to
do what they wanted to do. I could cite many examples
of IETF work where too tight control has actually reduced
the amount of quality control the IETF can have over our
technology. Say, we develop protocol X to replace a bad
protocol Y, but make X so tightly controlled that in practise
we can't convince vendors to use it. Suddenly everyone
is using protocol Y...

--Jari

---

From: Ralph Droms <[email-masked]>
Date: Tue, 28 Jun 2005 09:26:06 -0400

John - as a concrete example of the problem you describe, the dhc WG
perceived that there was a looming problem with exhaustion of the DHCP
option code space.  So, we wrote up a procedure (RFC 2939) requiring
documentation of new options in an RFC, implying technical review by the
dhc WG.  Now, we find a significant number of option codes in the
private code space (128-254), which have been unofficially appropriated
for use in shipping products. 

To clean up the mess, the dhc WG has enlarged the available option code
space and is working through a process of identifying and registering
the unofficially appropriated option codes (RFC 3942).  I'll ask the dhc
WG to review RFC 2939 in light of the expanded option code space and our
experience with unofficial appropriation.

- Ralph

On Mon, 2005-06-27 at 06:32 -0400, John C Klensin wrote:
> [...]
> [...]

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 28 Jun 2005 08:52:50 -0500

Ralph,

Are you saying that the vendor community interprets registration delay 
as damage, and routes around it?

Spencer

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jun 2005 10:21:15 -0400

> as damage, and routes around it?

or maybe, the vendor community insists on inflicting damage?

Keith

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Jun 2005 07:50:43 -0700

> 	use something, require community consensus.

nice, simple language.  seems to capture the distinction -- and the 
requirement -- nicely.

-- 
 
   d/

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jun 2005 11:16:14 -0400

> nice, simple language.  seems to capture the distinction -- and the 

I disagree.  We normally require a higher standard than community consensus
for technical specifications - we require both consensus and technical soundness.
Technical soundness is determined by both community feedback and IESG review.
I don't see why we should impose a lesser standard for IP options.

Keith

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 28 Jun 2005 17:40:53 +0200

>That namespace also allows for use of "x-" names.)

Thanks, Harald, some laugh in that tense debate is welcome. Let me give 
others some more documented details to add to your support of Robert Elz 
and Dr. Roberts.

1. it is worse: the language tag reviewer designated expert (for apparently 
a permanent mandate) _accepted_ the tag but was reprimanded for that (by 
who?). (cf. below)

2. this concerned list ([email-masked]) is not an IETF list, 
but an Harald Alvestrand's private mailing list. At least this what Harald 
told me, to be able to ban me, without proper procedure, AD protection and 
appeal possibilities RFC 3494 would have granted me. I must say that, among 
others, I demand for months that list to be set-up as a IANA mailing list 
it is to be (RFC 3066) with all the publicity, IANA access and decorum the 
matter requires;. In the process I may have trolled a little bit to trap 
Harald in acknowledging the situation :-). Everything is on-line.

3. Heaven thank's more that list is not IETF: it does not respect the RFC 
3066 procedures. An approval requires a 15 days discussion on the list. In 
the es-419 case it was reduced to 4 days, by fed-up of the Prince (cf. 
below). BTW "-419" would only be permitted by the twice Last Call failed 
non yet introduced RFC 3066 bis. Still alive with its concerning doctrine 
unchanged, now as part of the WG-ltru work.

4. everyone knows that for a long IETF has joined ITU and adopted the UN 
system. So everyone knows that "419" comes from M.49 
http://unstats.un.org/unsd/methods/m49/m49regin.htm which is the Harald's 
replacement for Jon Postel's RFC 1591 which selected ISO 3166. This is why 
".us" has now become ".840". Also everyone agrees "Americas" was is 
ambiguous term: so the expert selected "419" which stands for "Latin 
America and Caribbean" instead of "019" which stands for ... "Americas". 
This means that for the IESG/IANA the USA have no New Mexico state (cf. 
below).

In case you think I am kidding, here is the Expert's statement which 
promulgates "es-419":

<quote>
I approved the tag assuming it has gone through the mill enough. I approved 
"es-americas" a while ago and was growled at for that. I am not interested 
in pissing off the IANA lass who deals with our stuff for no good reason. 
I've approved it, I don't believe that ANYONE is going to come up with a 
convincing reason to disapprove it, and the idea of formally withdrawing 
the approval for 11 days and then doing it again doesn't really thrill me.

And New Mexico can live with 419, for heaven's sake.
</quote>

In case you want to share in this exciting list,  you just have to register 
in sending a mail to:
<mailto:[email-masked]?subject=subscribe> .

The review of  the management of the IANA langtag registry is subject to 
the work of the WG-ltru. http://ietf.org/html.charters/ltru-charter.html
Let me make some outreach for this important WG for the image of the IETF 
in the international community, in an area where Culture Ministries, 
academic people and ccTLD Managers, GAC Members, etc. are very concerned, 
their language, culture and to some extent their economy are involved. I 
note we are only two there having not English as a mother language, what is 
not enough to provide the WG with the necessary diversity. FYI there are 
7500 languages listed in the ISO 639 list under final preparation by Peter 
Constable. And 20.000 in the ISO 639-6 list to follow. It is worth noting 
that the integration of ISO 639 for languages and ISO 15924 for scripts 
(however difficult the definition of what they represent and for who 
[author, reader of both]) are building blocks of the Multilingual Internet 
I documented yesterday and obviously for the 
multimedia/multimode/multitechnology convergence.

The consistency with ISO 11179 (Registries continuity) and the work IETF 
should carry in that area, is precisely what would prevent cases like the 
HBH case and determine how such parameters should be recorded and where. 
One understands that in front of 20.000 equal by right and equally 
cherished languages by those speaking them, one cannot continue to speak of 
a unique authoritative entity in the same way as when the Legacy was the 
few ASCII machines of an US academic project. We have to ensure technical 
end to end interoperability. We also have to manage person to person 
interintelligibility within 20.000 and far more, cultural spaces of 
exchanges, trust and services. Either we do it, or some others will decide. 
The committing decisions will be taken in Tunis.

This will decide of a catastrophic Internet split, balkanisation or 
pulverisation as I discussed it yesterday, or to a productive concerted 
partitioning organised in continuity.
jfc

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Jun 2005 21:38:11 +0700

Date:        Tue, 28 Jun 2005 00:16:56 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | Yakov Rekhter wrote:
  | > What was the reason(s) the request was made for an assignment
  | > that required IESG Approval, rather than either Specification
  | > Required or First Come First Serve ?
  | 
  | RFC 2780 (BCP 37).

I'm not sure that was really the question Yakov was answering, but
then again, I'm not sure what that was, so perhaps...

  | If there had been an I-D it would have been easier.

Easier to do what?   The IESG rejected the request because it did
not like the protocol it was proposed to be used with.   How could
the format of the presentation of the protocol possibly make a difference
to that?

I would assume that even if the protocol were presented to a WG as an I-D,
and approved by the WG, and IETF last call, the IESG would still have refused
publication, and consequenlyly the parameter assignment by IANA - after all,
the IESG apparently believes this protocol (whatever it is) would do harm
to the internet, and presumably, IPv6.

Do you have any idea what you're really saying, or are you just looking
for excuses to attempt to justify the IESG's bizarre and inexcusable actions?

kre

---

From: Bob Hinden <[email-masked]>
Date: Tue, 28 Jun 2005 09:48:48 -0700

Keith,

At 05:40 AM 06/28/2005, Keith Moore wrote:
>My personal opinion is that it's quite reasonable to require IESG approval 
>of an IP-level option.  IMHO the IESG should solicit public input before 
>making such a decision, probably in the form of a Last Call.  But the 
>potential for harm is such that somebody needs to have the ability to say 
>"no".  Or to put it another way, IMHO we need both convincing evidence of 
>technical soundness, ideally supported by analysis, and a compelling 
>argument of benefit for the Internet community, to justify adding a new 
>option to the IP layer.  We already have too much variation in the 
>operating environment from one network to another.

Well said.

I would be troubled by any change to IP (including new options) that was 
not discussed in the IETF, documented in an RFC, and have declared IPR.  In 
the hour glass model of the IP architecture these are changes that go in 
the skinny waist.  A place in the architecture where we want to be 
conservative adding new things (as opposed to higher up where we clearly 
want lots of diversity and liberal assignment policies).

Bob

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Jun 2005 16:32:54 -0400

--On Tuesday, June 28, 2005 09:48 -0700 Bob Hinden 
<[email-masked]> wrote:

>> My personal opinion is that it's quite reasonable to require
>> IESG approval  of an IP-level option.  IMHO the IESG should
>> solicit public input before  making such a decision, probably
>> in the form of a Last Call.  But the  potential for harm is
>> such that somebody needs to have the ability to say  "no".
>> Or to put it another way, IMHO we need both convincing
>> evidence of  technical soundness, ideally supported by
>> analysis, and a compelling  argument of benefit for the
>> Internet community, to justify adding a new  option to the IP
>> layer.  We already have too much variation in the  operating
>> environment from one network to another.
>
> Well said.
>
> I would be troubled by any change to IP (including new
> options) that was not discussed in the IETF, documented in an
> RFC, and have declared IPR.  In the hour glass model of the IP
> architecture these are changes that go in the skinny waist.  A
> place in the architecture where we want to be conservative
> adding new things (as opposed to higher up where we clearly

Sigh.  I'm going to try one last time.  Probably I should just 
give up.

Bob and Keith,

As far as protocol changes, adding stuff to IP, etc., I am 100% 
in agreement with you.  We should be cautious, we should 
exercise considerable diligence, we should not approve anything 
without considerable evidence of informed IETF consensus.  I 
can't figure out how to say that more clearly.

_However_ if some rogue group comes along (and I hope that we 
are a long distance from where Larry Roberts would be considered 
a "rogue group", even though I have disagreed about some things 
he has advocated in the past and may do so in the future) and 
has the resources and commitment to deploy an IP option, I think 
we need to register it to protect the community from the bad 
option, not pretend that not registering it will somehow prevent 
them from deploying their ideas.

And then, if we are convinced the idea is bad enough, we need to 
do what _will_ prevent the bad idea from being actively used, 
which is to do, and write up the analysis of why it is bad and 
what problems it will cause.

But the notion that the IETF can prevent something from 
happening or being deployed by declining to register it, or by 
turning our collective backs on it without any real explanation 
-- even at the waist of the hourglass--  is, in this world, just 
delusional.  And, if that delusion prevents the IETF community 
from explaining, carefully and in public why the idea is a bad 
one, then it is we who are putting the Internet at risk.

   john

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 28 Jun 2005 13:23:59 -0700

Hi -

> From: "JFC (Jefsey) Morfin" <[email-masked]>
> To: "Harald Tveit Alvestrand" <[email-masked]>; "John C Klensin" <[email-masked]>
> Cc: "Thomas Narten" <[email-masked]>; "Ned Freed" <[email-masked]>; "IETF list" <[email-masked]>; "Robert Elz"
<[email-masked]>
> Sent: Tuesday, June 28, 2005 8:40 AM
> Subject: Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)
...
> Harald in acknowledging the situation :-). Everything is on-line.

The mailing service for [email-masked] happens to be provided by
Harald.  This is not unusual or improper, as has been explained to you on
the ietf-languages list, as well as the ltru WG mailing list.  Furthermore, your
request to change the administration of the mailing list was rejected by WG
consensus.

Your bad behaviour on the [email-masked] and [email-masked] lists
(suspended twice on the former, once on the latter) and consistent efforts
to delay progress on both lists have done little to enhance your credibility.
Indeed, I was surprised when the ltru WG did NOT agree to add text
to the draft on the registry to explicitly address the question of suspending
disruptive elements on the [email-masked] mailing list.

...
> This means that for the IESG/IANA the USA have no New Mexico state (cf.

This is a gross misrepresentation.  See
http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-06.txt
section 2.4.4, especially point (3) (D).

...
> the work of the WG-ltru. http://ietf.org/html.charters/ltru-charter.html

Thank you for the advertisement.  We are very close to WG last call, so
I urge those interested to join now.

> not enough to provide the WG with the necessary diversity.

Demonstrably false, and you know it.  There are more than two WG participants
whose first language is not English.  Some members are linguists by training,
and the WG includes experts in internationalization.  Of course more would
always be welcome, but I think those we have are up to the task.

...
...

The ltru WG consensus was to not delay our work in order to align with ISO 11179.

Randy, ltru co-chair

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jun 2005 18:07:23 -0400

> one, then it is we who are putting the Internet at risk.

Basically I think we need to do whatever will be most effective at
discouraging the bad idea.  If that means any of the following:

- not registering the idea, or
- registering the idea and clearly marking it as bad, or
- delaying registration of the idea until such time as it can be
  improved or the harm can be limited,

any of those are fine with me.  Circumstances vary from one 
case to another, and according to how bad the idea is, and the 
best action in one case might not be the best in another.  

So basically I think we need to leave such decisions to the 
discretion of a well-informed group of people, e.g. the IESG.
I do think the IESG should solicit community input on the 
proposal, but I don't think the Internet community would be 
well served by criteria that insisted that we register any IP
extension that someone proposed.  And if IESG makes mistakes,
well, that's what the appeals process is for.

Keith

---

From: grenville armitage <[email-masked]>
Date: Wed, 29 Jun 2005 09:12:47 +1000

Much as I normally dislike "me too" posts, John's summation below
captures quite well the concern I've also felt since the minute I
saw the IESG's announcement regarding rejection of the requested
IP option code point.

cheers,
gja

John C Klensin wrote:
	[..]
> Sigh.  I'm going to try one last time.  Probably I should just give up.
> 
> Bob and Keith,
> 
> As far as protocol changes, adding stuff to IP, etc., I am 100% in 
> agreement with you.  We should be cautious, we should exercise 
> considerable diligence, we should not approve anything without 
> considerable evidence of informed IETF consensus.  I can't figure out 
> how to say that more clearly.
> 
> _However_ if some rogue group comes along (and I hope that we are a long 
> distance from where Larry Roberts would be considered a "rogue group", 
> even though I have disagreed about some things he has advocated in the 
> past and may do so in the future) and has the resources and commitment 
> to deploy an IP option, I think we need to register it to protect the 
> community from the bad option, not pretend that not registering it will 
> somehow prevent them from deploying their ideas.
> 
> And then, if we are convinced the idea is bad enough, we need to do what 
> _will_ prevent the bad idea from being actively used, which is to do, 
> and write up the analysis of why it is bad and what problems it will cause.
> 
> But the notion that the IETF can prevent something from happening or 
> being deployed by declining to register it, or by turning our collective 
> backs on it without any real explanation -- even at the waist of the 
> hourglass--  is, in this world, just delusional.  And, if that delusion 
> prevents the IETF community from explaining, carefully and in public why 
> the idea is a bad one, then it is we who are putting the Internet at risk.
> 
>   john

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

---

From: grenville armitage <[email-masked]>
Date: Wed, 29 Jun 2005 09:53:57 +1000

Keith Moore wrote:
	[..]
>   improved or the harm can be limited,

I'm not sure a new, unique option code is 'an idea' that needs discouraging.
At most it is a marker indicating someone, somewhere, might deploy an idea
that you believe could require discouraging. Discouraging _deployment_ of
the idea may well be warranted, but it wont be achieved by blocking the
assignment of an option code on those grounds alone.

> best action in one case might not be the best in another.

In this case 'the idea' was "we would like an option code point
assigned". I'd have thoughth the discussion should have been about whether there
was an intention of deployment by the requestor (the request isn't gratuituous)
and whether there are enough codepoints available for future use (the request,
if fulfilled, wont prevent other IETF-developed ideas from getting their own
codepoints). The decision process should have stopped when the answer was
"yes" on both counts. At least, that's how it seems to me.

cheers,
gja

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 29 Jun 2005 02:11:43 +0200

This is a beautifull troll :-) However the good of the WG-ltru work calls 
for short comments where we will probably partly agree.

>I urge those interested to join now.

Yes! This is really an important issue. Not usual IEFT but important.

>There are more than two WG participants whose first language is not English.

True. I should have said as regular contributors. We need more.

>Some members are linguists by training, and the WG includes experts in 
>internationalization.

Yes. But we are missing experts in networking, Internet standard process, 
multilingualism, national cultures, LDAP, standard document witing. This is 
a actually complex issue (mix of lingual subjective and 
networking/standardisation precise issues).

>The ltru WG consensus was to not delay our work in order to align with ISO 

This is unfortunately a self-evaluation of the WG  current consensus 
process  ... I say this because the WG charter says "[the Dratf/WG] is also 
expected to provide mechanisms to support the evolution of the underlying 
ISO standards". The ISO 639-6 and ISO 639-4 persons (present on the list) 
explained these two standards will comply with ISO 11179. ISO 639-4 defines 
the guidelines for all the language standards used by the WG. This 
consensus therefore opposes the charter (but if the Draft does not want to 
be BCP 47, this is IMHO acceptable, but must be discussed).

Anyway I understand the concern as ISO 11179 is a "big" thing. It is also 
key element of the future. And certainly the key of the evolution of RFC 
2434 if to stay compatible with the global convergence. Interesting to 
share here. Beware: ISO 11179 is not finished and already an heavy 
document. IETF should work on its network/multilingual simplification.

jfc

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jun 2005 20:29:32 -0400

> assigned". 

if that's all there is to the proposal, it should be rejected 
out-of-hand without discussion.

> I'd have thoughth the discussion should have been about whether there was an intention of deployment by the requestor (the request isn't 
> gratuituous) and whether there are enough codepoints available for future use (the 
> request, if fulfilled, wont prevent other IETF-developed ideas from getting their 
> own codepoints). The decision process should have stopped when the answer was

those are both valid concerns, but relatively minor concerns compared to 
the potential for poorly designed IP options to have an adverse effect 
on Internet interoperation, at any layer from 3 up.

Keith

---

From: "Thomas J. Hruska" <[email-masked]>
Date: Tue, 28 Jun 2005 20:37:54 -0400

> John C Klensin wrote:
<snip>
>> being deployed by declining to register it, or by turning our 
>> collective backs on it without any real explanation -- even at the 
>> waist of the hourglass--  is, in this world, just delusional.  And, if 
>> that delusion prevents the IETF community from explaining, carefully 
>> and in public why the idea is a bad one, then it is we who are putting 
>> the Internet at risk.
>>
>>   john

(This message is duplicated on my blog, so, moderators, don't even
bother trying to block it).

So...why hasn't the IETF labeled SMTP and POP3, not just a bad idea, but
a terrible one and scrapped (obsoleted, terminated, or whatever you want
to call it) both protocols and come up with something completely new
without a migration path (i.e. the terminated SMTP and POP3 protocols
can't talk to the new protocol and vice versa)?

While that is some lovely writing, I have yet to see the IETF do
anything constructive in lieu of the spam that plagues the Internet.  In
my book, the IETF is to blame for spam, both its existence and its
continuation.  Also, from what I can tell over the past few years of
watching this list, no one in the IETF has the guts nor the spinal
column needed to do anything about it.  Instead of all of you getting
drunk at BOF meetings, how about actually fixing the spam problem and
perhaps a few other protocols while you are at it.  You are the Internet
_Engineering_ Task Force.  It is your job to make new protocols and fix
broken protocols, and it is the implementor's responsibility to follow
changes without complaint.  If you terminate SMTP and POP3 or simply
re-write the core Internet protocols from the ground-up, every
implementation out there MUST follow.  If the IETF thinks it can do
nothing about spam, then it is already delusional and the world needs a
new organization that isn't blind to the world's needs.  We wouldn't
have the problems today that we currrently have if the IETF was actually
doing its job.

All I have to ask is:  Who around here loves receiving spam?  Who is
ultimately responsible for the spam people get?

Bite the bullet, get some guts, and grow a spine.  Sure it is scary to
replace major protocols in such a radical fashion, but we all know it is
long overdue, so just do it.  Implementors around the world will love
you if you do (spam drives them up the wall because they have to
constantly counter-act it with new "needless" features in their servers).

Note that this is partly my personal angst, partly an implementor's
view, partly because spam is a real problem that isn't being dealt with,
and partly because SMTP and POP3 are so incredibly old and riddled with
hacks for MIME, attachments, multi-byte character sets/unicode, and use
cleartext transmissions (except over more recent SSL/TLS hacks).  At
some point the hacks have to hit a limit and spam was the indicator of
that limit, only the IETF ignored it and kept going.

Frankly, I wouldn't be surprised if, in the near future, companies and
individuals started suing the IETF for damages for every spam message
they receive.  I'll bet a class action lawsuit against the IETF would
get public attention real fast...and not in a good light either for the
IETF.

Thomas Hruska

---

From: grenville armitage <[email-masked]>
Date: Wed, 29 Jun 2005 10:39:01 +1000

> out-of-hand without discussion.

who said that's all there was to the proposal? there was clearly a
proposed use. but the use factors into the question only to the
extent that we would want to ensure the codepoint will actually be
used (and not just a gratuitous request for codepoint assignment).
assuming we're happy the codepoint will be used, assign one. let
later deployment realities, and if necessary "don't do this"
style of RFCs, be the judge of whether the proposal (which uses
the codepoint) is a good idea.

	[..] 
> on Internet interoperation, at any layer from 3 up.

and one stops that by refusing a unique codepoint?

cheers,
gja

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jun 2005 23:10:23 -0400

> used (and not just a gratuitous request for codepoint assignment).

no.  it's also important to evaluate the proposed extension for 
technical soundness.

> the codepoint) is a good idea.

in other words, allow the disease to spread before you try to fix it.

>> those are both valid concerns, but relatively minor concerns compared 
>> to the potential for poorly designed IP options to have an adverse 
>> effect on Internet interoperation, at any layer from 3 up.
> 
> 

one stops it by any means that is effective and available.

Keith

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 28 Jun 2005 21:16:04 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, June 28, 2005 5:11 PM
...
> networking/standardisation precise issues).

More untruths.  The working group's members include Harald Alvestrand, and
John Klensin, to name a few who know something about the Internet standard
process.  I think working group member Kurt Zeilenga is adequately qualified on
LDAP issues.  Both of the co-chairs have served as editors of multiple RFCs,
as have several of the WG members.  Some of us also have experience editing
ISO and ITU standards, and some members have experience in the W3C or the
Unicode Consortium, to name just a few.  I suppose WG members like
James Seng might have something to say on "multilingualism" and "national
cultures" as would both co-chairs (both living in multi-cultural, multi-lingual
households), if those discussions were relevant to the mechanics of
the syntax and registration of tags for the identification of languages.

...

Providing support for the evolution of the underlying standards does not
require conformance (whatever that might mean) to ISO 11179, any
more than it means we should use the same word processor used to
edit the ISO documents.

Randy, ltru co-chair

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Jun 2005 07:31:45 -0400

--On Tuesday, 28 June, 2005 21:16 -0700 Randy Presuhn
<[email-masked]> wrote:

>...
> More untruths.  The working group's members include Harald
> Alvestrand, and John Klensin, to name a few who know something
> about the Internet standard process.  
>...

Randy,

Since you mentioned my name, to be perfectly precise about
this,...

(1) There is no such thing as a "member" of a working group.
You presumably know this.  Since, if I recall, I have made zero
postings, the only evidence you have of my involvement is my
presence on the WG's mailing list.

(2) For a long set of reasons, if the only reason/ justification
for my tracking (or even participating) in the WG was my
knowledge of the Internet standard process, I would be --at best
from your point of view-- completely irrelevant.   There are a
few people who think I know something about the subject matter
but, of course, their level of delusion up something for others
to assess.

(3) I have been trying to track the WG's efforts by subscribing
to the mailing list but have, frankly, found that nearly
impossible given that I have other priorities.  The message
volume got high enough that I started trying to read things on a
digest basis, at which point I discovered (i) that the digests
were very frequent and very large (partially due to poor email
hygiene on the part of some posters) and (ii) that there are
some serious bugs in the IETF Secretariat mechanisms for
producing digests.  They have been unable or unwilling to fix
those bugs, but the result is that they are sending out mail
that is invalid under RFC 2822 (and 822 and earlier).  For me,
that is very inconvenient in terms of sorting and tracking the
mail which makes it even more difficult for me to try to track
the WG's efforts.  However, those who believe that the essence
of spam-exclusion includes rejecting any message that doesn't
conform to the rather minimal requirements of 2822 are being
systematically excluded from receiving those materials.  (For
those who are curious, this is "action" tracking Inquiry #57798.)

Because there are many other pressures on my time right now, the
combination of those factors has resulted in my trying, mostly
in vain, to track the WG's work, but being unable to actually
participate in it.  If there are others in a similar situation,
that creates a risk for the community, but this is not the time
or place to resolve it.

     john

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 29 Jun 2005 14:57:54 +0200

I am quite glad we cooperate to the outreach of the WG-ltru.

>the syntax and registration of tags for the identification of languages.

I did not yet any contribution of the quoted persons. I am glad they 
joined: their contributions will certainly help the work of the WG. The 
issue is complex and as important as the creation of the name space or IP 
addressing. It is the naming structure of the Multilingual Global NGN.

Opposition is between the vision of an "application/author" oriented 
W3C/Unicode affinity group, focusing on the writing of a document, and the 
experimentation effort I represent which is interested in its multiple 
"networked usage" architecture. This is "what for" question the Draft does 
not document yet (Martin Düerst just introduced an interesting suggestion 
to permit that: if the scope of the Draft is clearly defined, what is not 
addressed if not blocked, but reserved for further study. This idea is a 
good idea which should probably investigated in other cases).

The problem is the same as in the HBH case (Harald was right to quote it in 
unwillingly supporting Dr. Roberts). We are in a gigantic change period for 
the Internet, from an architecture which started with four machines to a 
global multi-everything architecture. It is normal that tensions exist. 
What is not normal is that they result in ad hominems and in stubborn 
denials of dialog and cooperation (usually a demonstration of weakness: 
this is not good, we are not here to oppose but to build together - but it 
has to make sense).

Dr. Roberts, myself and many others, starting with ICANN (ICP-3 document), 
call for the need to experiment and not to be blocked by outdated legacies. 
Others try to oppose for many good (stability, experience, etc.) and less 
good reasons (I know better, this is the way it is). John Klensin started 
discussing that well. The good reasons of both sides must be considered, 
the poor ones filtered out. In the case of RFC 3066 Harald introduced a 
possibility which should be present everywhere, and which has been quoted 
here: "x-tags" are for free private use. This permits experimentation and 
specialised applications. (Except that to comply with some possible old 
experimentations the free, private x-tags should be restricted to 8 
hexatridecimals :-) !!!). HBH would be up and running/faling, no one 
knowing it, no one being hurt, no one having wasted time.

-->

The list of WG-ltru "angels" Randy quoted, shows the interest of the 
WG-ltru. If John Klensin, Harald Alvestrand, Kurt Zeilenga and James Seng, 
etc. contribute, with  Randy and Martin Düerst as co-chairs, contributors 
of same stature will certainly have the occasion of interesting exchanges.

>require conformance (whatever that might mean)

con·for·mance    ( P )  Pronunciation Key  (kn-fôrmns)
n.
Conformity.

Source: The American Heritage® Dictionary of the English Language, Fourth 
Edition
Copyright © 2000 by Houghton Mifflin Company.

>to ISO 11179, any more than it means we should use the same word processor 
>used to edit the ISO documents.

Non-Members should understand that when Randy refers to the script, 
language and country parameters of the word processor being used. This 
calls for two comments:

1. the word processor also uses two other parameters: the referent of the 
used language (ex. dictionary) and the context in which it is used (ex. 
style) as everyone using Word for example can check. The current RFC 3066 
langtags are informal and open. They can accommodate much flexibility. The 
RFC 3066 bis langtags are structured and rigid: in refusing to include the 
referent and the context they become totally out of scope.. Like if you 
were prevented to tell the vegetable and the dressing when ordering a McDo 
cold salad.

2. ISO 639 -1 and -2 have been defined before their experience (and many 
other standards) lead to the ISO 11179 convergence work. ISO 639-4 wants 
the ISO 639 to conform to ISO 11179, so ISO 639-3 will (what has low 
impact) and ISO 639-6 will extend that. The impact is that the proposed 
Internet langtags will conflict with the ISO langtags, the way they are 
going to be used in Industry, marketing, consumer goods, networking, 
international documents and standards, administration and immigration, 
UNESCO, WTO, WIPO, etc. etc. outside of the XML pages respecting the 
currently proposed Draft. Introducing confusion and loss of credibility and 
delays for the IETF.

Where the issue is quite worrying is that all this could root into
- the protection of a vision of the locales management (named CLDR) by the 
Members of the Unicode consortium
- against a generalised ISO 11179 lingual model including the locale, the 
multimedia convergence, the multimode aspects (writing is a seldom used way 
to use language, when compared to others).

No more than for HBH I think IETF should support one technical approach 
against another. And if it does it should not be by acrimony and harassment.

jfc

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 29 Jun 2005 15:18:46 +0200

Sigh.

I, like John, have been following LTRU only with half an eye; it seemed to 
be running fairly well, apart from the problems of dealing with Jefsey's 
comments, but I haven't read the documents for quite some time.

But I'm confident enough about my reading of the mail in my mailbox to say 
that the chair is right in saying that ISO 11179 conformance was considered 
by the WG (because Jefsey proposed it), and was rejected by the WG as 
irrelevant.

Note: Jefsey's suspension on the ietf-languages list runs until July 15. 
After that, I have to modify my killfile so that I see mail he sends to 
that list. Until then, I see no reason why I should look at mail from him 
at all.

                    Harald

---

From: Hans Kruse <[email-masked]>
Date: Wed, 29 Jun 2005 10:42:44 -0400

Just a quick (one-time I plan) note in support of John's position.  I, 
too, think it is counterproductive to avoid/deny registration in this 
case.  Maybe a slightly different way of saying it:

- A group of folks has designed an IP _option_ they intend to use
- They have documented the option (albeit not in IETF format)
- They are asking, in fact, "We are going to deploy this option, what 
code point would you like us to use?"

The IETF/IESG have two choices IMHO:

A. Assign a code point.  If someone later says "hey, that option 
doesn't play well on my part of the network", you know _exactly_ what 
code point to filter (drop packets) on.  In a good community spirit one 
might also write this up as an "option XYZ considered harmful" ID.

B. Deny the assignment of the code point, and forever wonder which 
unknown code in an inbound packet might correspond to this option.

I suggest choice A. above is the better one of the two.

Also note that "C. Prevent the deployment of the option" does not exist.

On Jun 28, 2005, at 16:32, John C Klensin wrote:

> _However_ if some rogue group comes along (and I hope that we are a 
> long distance from where Larry Roberts would be considered a "rogue 
> group", even though I have disagreed about some things he has 
> advocated in the past and may do so in the future) and has the 
> resources and commitment to deploy an IP option, I think we need to 
> register it to protect the community from the bad option, not pretend 
> that not registering it will somehow prevent them from deploying their 
> ideas.
>
> And then, if we are convinced the idea is bad enough, we need to do 
> what _will_ prevent the bad idea from being actively used, which is to 
> do, and write up the analysis of why it is bad and what problems it 
> will cause.
>
Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer 
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

---

From: Hans Kruse <[email-masked]>
Date: Wed, 29 Jun 2005 10:51:02 -0400

But the refusal of a code point is not effective, and in fact 
counter-productive (since the option will indeed be deployed, you just 
won't know what code point it self-assigned).

On Jun 28, 2005, at 23:10, Keith Moore wrote:

>
>>> those are both valid concerns, but relatively minor concerns 
>>> compared to the potential for poorly designed IP options to have an 
>>> adverse effect on Internet interoperation, at any layer from 3 up.

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Jun 2005 10:58:45 -0400

> won't know what code point it self-assigned).

that's not true in general.  each situation is different.

the alternative - to blindly assign codepoints even to poor proposals - 
would encourage proliferation of poorly designed extensions to IP.

we need to allow IESG to use some discretion here.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Jun 2005 09:53:53 -0700

> we need to allow IESG to use some discretion here.

what *kind* of discretion?

      should we allow the IESG the discretion to decide what they like or 
don't like and then allow them the authority to make the decision based on that?

      or, should we allow the IESG the discretion to note potential issues and 
then allow them the authority to raise seek review and consensus from the IETF?

and, of course, there are more alternatives to consider "allowing", but these 
two highlight the underlying question here.

I could have sworn that Dave Clark preceded the "rough consensus" reference 
with a reference about our not assigning decision-making authority to a 
delegate.  He named kings and presidents.

So it is not ok to have a king or a president, but it *is* ok to have an 
oligarchy?

-- 
 
   d/

  Dave Crocker

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Jun 2005 20:13:10 +0200

As a matter of information, my habit is to ignore messages under a given
subject field that discuss something else, e.g. messages under a header
like 'RFC 2434 term "IESG approval"' that actually discuss language tags.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Jun 2005 20:33:29 +0200

> don't like and then allow them the authority to make the decision based 

As I read RFC 2780 that is (apart from the "don't like" caricatural phrasing)
today's rule:

5.5 IPv6 Hop-by-Hop and Destination Option Fields

    Values for the IPv6 Hop-by-Hop Options and Destination Options fields
    are allocated using an IESG Approval, IETF Consensus or Standards
    Action processes.

> 
>      or, should we allow the IESG the discretion to note potential 
> issues and then allow them the authority to raise seek review and 
> consensus from the IETF?

If there is an IETF contribution to review (or equivalently, a liaison
communication from another standards body soliciting a review of their
specification), we can always do that. That is also allowed by 2780.

    Brian
> 
> and, of course, there are more alternatives to consider "allowing", but 
> these two highlight the underlying question here.
> 
> 
> 
> I could have sworn that Dave Clark preceded the "rough consensus" 
> reference with a reference about our not assigning decision-making 
> authority to a delegate.  He named kings and presidents.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Jun 2005 20:50:23 +0200

Larry,

One thing that may not be immediately obvious is that if the IETF
reviews a contribution (whether it's an Internet-Draft or an email),
it automatically falls under IETF IPR rules. Alternatively, if another
SDO sends a liaison requesting IETF review of their document, we
presume that the other SDO's IPR rules apply. It's rather unclear
what IPR rules apply when an individual (e.g. you) points the IETF to
another SDO's document, absent a formal liaison.

But what the IETF does best is review I-Ds.

In other words, if you want to make progress, a repeat request
accompanied an I-D is really the best way (regardless of the
IESG's expressed pessimism).

    Brian

Dr. Lawrence G. Roberts wrote:
> final ITU documents attached (which I sent to Brian) that there should 
> be no trouble reviewing it for the concepts. The attached documents are 
> the latest ITU documents and the TIA 1039 document is identical in 
> content. The difference in them from the packet.cc document is in the 
> addition of IPv4 which is not at issue and does not depend on an option 
> field code assignment. Making these later ones publicly available can be 
> considered. But it may take awhile. Meanwhile, the copies above were 
> available to the committee since I sent them to Brian..
> It is hard to convert these documents to ACII text quickly to put them 
> in IETF format. That was done once at packet.cc and the option field is 
> for IPv6 which is in all the documents.
> Larry
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 29 Jun 2005 20:55:50 +0200

At 15:18 29/06/2005, Harald Tveit Alvestrand wrote:
>that the chair is right in saying that ISO 11179 conformance was 
>considered by the WG (because Jefsey proposed it), and was rejected by the 
>WG as irrelevant.

Thank you for at last showing publicly and with authority that ad-hominems 
are the answer given to the "dumb" idea that, WG-ltru and ISO dealing with 
the same topic (ISO Tables registries), mutual innovative considerations 
(and not only political lobbying) could help both. We, and all the people 
involved, know this cannot be otherwise and may mean a loss of commercial 
dominance over a significant part of the Internet.

We both think competition and free softwares foster better quality and 
innovation. And cultural empowerment is the key to a common and sustainable 
development. So, why?
jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 29 Jun 2005 12:48:29 -0700

Hi -

> To: "Harald Tveit Alvestrand" <[email-masked]>; "John C Klensin" <[email-masked]>; "Randy Presuhn"
<[email-masked]>; <[email-masked]>
> Sent: Wednesday, June 29, 2005 11:55 AM
> Subject: Status in LTRU
>

The ltru WG considered the proposal to employ ISO 11179.
No one else supported the proposal to employ ISO 11179.
Several opposed the proposal to employ ISO 11179.
The proposal to employ ISO 11179 was rejected.
Get over it.

If you have concerns with the ltru work, please take them to the
[email-masked] mailing list.  [email-masked] really isn't the place for
discussing the details of the language tag registry.

Randy, ltru co-chair

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Jun 2005 16:11:59 -0400

> don't like and then allow them the authority to make the decision based on that?

IESG should have discretion to evaluate such proposals for soundness,
along with supporting material and community comments, and make a
decision.  And if people disagree with that decision, that's what
appeals are for. 

> then allow them the authority to raise seek review and consensus from the IETF?

No.  _Someone_ has to decide whether a proposal has sufficient merit to
approve it, and whether any technical or process concerns raised are
sufficiently valid to deny the proposal or to request that it be
revised.  Of course, that someone can be capricious, and that's
unfortunate.  But taking IESG out of the loop doesn't solve that
problem, it only moves it. 

And it's probably worth pointing out that both individuals and working 
groups can be at least as capricious, and incorrect, as IESG can.
Your effort to make IESG seem capricious by using words like "what they
like or don't like" applies at least as much to other parties as it
does to IESG.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 29 Jun 2005 16:18:18 -0400

Dave, et. al.,

This is quite a complex situation, and I am a bit confused about it myself...

We have a document that says that an IP option number can be 
allocated based on IESG approval, IETF consensus or standards action 
processes, right?

So, based on our own standards and BCPs, we have given the IESG the 
authority to allocate an IP option number.

Can we really give the IESG that authority and not also give the IESG 
the authority to say 'no'?

In this particular case, the IESG was asked to approve the assignment 
of an IP option number to this document, and we chose to say 'no'.

The criteria by which the IESG would make this determination are not 
documented.  In this case, we decided that this specific proposal 
presents significant enough technical issues and incompatibilities 
with existing IETF specifications that we didn't feel comfortable 
assigning an IP option number for this purpose.

  I don't think the fact that the IESG did not choose to exercise its 
authority to allocate this IP option number precludes the proponents 
of this allocation from attempting to gain IETF consensus (for which 
they would presumably need to publish their draft as an I-D and make 
any IPR holding clear), nor does it preclude the authors of this 
document from attempting to publish the document as an IETF standard 
(which would also mean publishing it as an I-D).

Of course, I do understand that these three options are not _really_ 
as separate as RFC 2434 seems to indicate that they are...  In order 
to establish IETF consensus, it is practically necessary to gain 
Brian Carpenter's cooperation, as he is (as far as I know) the only 
person who can really put a question the IETF and judge our consensus 
on the response.  And, to publish a document on the standards track, 
it would be necessary to get at least one IESG member to sponsor the 
work and to get IESG approval to publish the document.

Personally, I think that if the IETF doesn't want to give the IESG 
the right to approve (and refuse to approve) the allocation of IP 
options, then the IETF should update  RFC 2780.

Margaret

At 9:53 AM -0700 6/29/05, Dave Crocker wrote:
>      should we allow the IESG the discretion to decide what they 
>like or don't like and then allow them the authority to make the 
>decision based on that?
>
>and, of course, there are more alternatives to consider "allowing", 
>but these two highlight the underlying question here.
>
>
>
>So it is not ok to have a king or a president, but it *is* ok to 
>have an oligarchy?
>
>--
>
>   d/
>
>  Dave Crocker

---

From: grenville armitage <[email-masked]>
Date: Thu, 30 Jun 2005 08:42:45 +1000

>    are allocated using an IESG Approval, IETF Consensus or Standards

I read that as suggesting, in order, the groups who could _allocate_ a new
codepoint without requiring further review. But _not_ allocating would mean
escalating to the next group along (i.e. if the IESG do not feel it appropriate
to allocate a codepoint immediately, they'd 'redirect' the requestor to the
process for gaining IETF Consensus, etc)

This seems logical to me in so far as it optimises the approval path for
uncontentious requests (IESG approval is presumably a quicker process than
IETF Consensus, etc).

What piqued my interest with the original announcement rejecting this particular
codepoint was the IESG's editorialising, which came across as "don't bother trying
for IETF consensus, it'll be a long time coming and we've got some similar/better
work of our own going on". Which just didn't seem like a fair or reasonable rider on
a rejection message.

(In my confused opinion, naturally.)

cheers,
gja

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 30 Jun 2005 16:36:49 -0400

On Wednesday, June 29, 2005 04:18:18 PM -0400 Margaret Wasserman 
<[email-masked]> wrote:

> authority to allocate this IP option number precludes the proponents of
> this allocation from attempting to gain IETF consensus (for which they
> would presumably need to publish their draft as an I-D and make any IPR
> holding clear), nor does it preclude the authors of this document from
> attempting to publish the document as an IETF standard (which would also
> mean publishing it as an I-D).

I don't believe the IESG's decision precludes the proponents from taking 
the proposal through IETF process, one way or another.

I don't think the IESG believed or intended so when it made this decision.

I don't think the IESG intended others to believe so, or to believe that 
that was its intent, when the announcement was drafted.  In fact, it's 
pretty clear to me that the IESG's announcement specifically left room for 
just such an action.

Unfortunately, it seems that an awful lot of people either think the IESG's 
action precludes further attempts to gain registration through IETF 
process, or think that the IESG intended it to preclude such attempts.

I _do_ think the IESG intended to give the advice that such a proposal 
would be unlikely to gain IETF consensus, and that therefore would just be 
a huge waste of everyone's time, including the proponents'.  I'm not in a 
position to guess whether that advice is correct or not, and given the 
significant cross-area implications of the proposal, I suspect that few 
IETF participants are in such a position.  The IESG as a whole _might_ be 
in such a position, and obviously believed that it was, or would not have 
given the advice.

Now, we can debate until the cows come home about whether it was proper for 
the IESG to give such advice at all.  I find myself on the fence, leaning 
towards "no" on the grounds that doing so creates a chilling effect which 
makes it harder to evaluate the proposal on its own merits.

> Of course, I do understand that these three options are not _really_ as
> separate as RFC 2434 seems to indicate that they are...  In order to
> establish IETF consensus, it is practically necessary to gain Brian
> Carpenter's cooperation, as he is (as far as I know) the only person who
> can really put a question the IETF and judge our consensus on the
> response.

It should be noted that while Brian's cooperation is necessary for that 
approach, his support is not.

In any case, I don't think this route is the right one to take, because I 
agree with the IESG's belief that for work of this sort, touching core 
internet components (including routing and TCP congestion control), review 
within the IETF should be a necessary part of the process.  If this went to 
an IETF consensus call, I would argue against assigning an option without 
IETF review of the protocol; that is, I would argue for the IETF as a whole 
to make the same decision the IESG did.

-- Jeff