Subject: Withdrawing sponsorship of draft-housley-tls-authz-extns

From: Sam Hartman <[email-masked]>
Date: Mon, 11 Jun 2007 18:57:13 -0400

Folks, after the various IPR disclosures were filed on
draft-housley-tls-authz-extns, I asked for a second IETF last call to
see if we had consensus to publish this document on the standards
track given the IPR claims against it.

That last call did not show the consensus I was looking for.  So, we
agreed we were going to send mail to the TLS working group and ask
them for their comments on publishing the draft.  We hoped that we'd
see a consensus there.  The chairs did ask for comments; see
http://www1.ietf.org/mail-archive/web/tls/current/msg01688.html .

Comments were provided, but there was not a consensus in favor of
publication on the standards track either there or on the ietf list.

I think there is a rough consensus against publication on the
standards track.  However it is quite clear that there is not a rough
consensus in favor of publication on the standards track which would
be required to do so.

So, I am withdrawing my sponsorship of the draft and as far as the
IETF process is concerned this draft is no longer under consideration
for publication.

One option that several people suggested is publication as an
informational spec.  I personally do not choose to sponsor this
document for informational or experimental.  often, it seems that we
use informational as a way to publish things we cannot build a strong
consensus behind.  I think that process is generally problematic and
would like to avoid it in this instance.  Other ADs may consider
sponsoring this document as an informational document; I would ask
them to carefully consider whether that is the best use of the time
they have to offer the IETF community.  My conclusion is that for me
personally, it is not.

Publishing this document via the rfc editor independent submissions
track is basically not an option because the IANA assignments require
IETF consensus or standards action.

That leaves the authors with several options:

* Work with people to build consensus and try again later.  Possibly
  working on discovering prior art or trying to revise the licensing
  terms.  There should be a much higher bar for starting the process a
  second time, but perhaps that bar can be met.

* Work on an alternative that does not have the IPR constraints.

* Work on finding another AD to sponsor the document.  I will not do
  so, and I'd advise my fellow ADs to think for a long time before
  taking on this draft, but I would not block another AD sponsoring
  the draft.

* Rewrite this document as a sketch of what might be done rather than a protocol and go through the independent submissions track.

* Drop the proposal.

I'm sad that we have come to this point.  I think this technology has
significant value and wish we'd found a way to publish it.  However we
follow a consensus process for many valuable reasons and it is clear
that the necessary consensus is not present in this case.
Sam Hartman
Security Area Director

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

---

From: <[email-masked]>
Date: Tue, 12 Jun 2007 14:18:15 +0300

Sam,

I'm quite disappointed with the way you chose to handle this.

I do agree with your assessment that we do not, at this time,
have rough consensus to publish this on Standards Track.

However, based on the public comments I have seen (obviously, 
I have not seen comments sent only to the IESG), significantly
more people supported publishing this (in some form) than were
totally opposed to publishing. I find it totally plausible that 
someone could interprete this as rough consensus for publishing 
this as a non-Standards Track RFC.

Since the Standards Action has been initiated, and the document
has gone through IETF last call, I think the decisions about the
Standards Action (whether to publish this or not, at what
status, with what changes) should be made by the IESG as a
whole, not solely by the sponsoring AD. 

While it is at each AD's discretion not to sponsor some document
(and not initiate Standards Action), I don't think this
discretion should extend to having a veto at the IESG table 
when the document and community input is considered ("if you 
make changes I don't like, I'll withdraw my sponsorship").  

It looks like our process rules don't really cover the case of
withdrawing sponsorship, but the existing IESG decision-making
process already allows an AD to object to publishing a document,
and I believe using a "sponsorship-withdrawal-veto" instead is
inappropriate.

I ask you to consider putting this document back on the IESG 
table, allowing each AD evaluate the document and community 
input received during the IETF Last Call (and determine the 
consensus or lack of it), and ballot accordingly.

Whatever the outcome is, I strongly believe this is not a 
decision you should make alone, and doing so would violate
the spirit of RFC 2026 and RFC 3710: in Standards Action,
the consensus is judged by all Area Directors, not any 
single person alone.

Best regards,
Pasi

> -----Original Message-----
> From: ext Sam Hartman [mailto:[email-masked]] 
> Sent: 12 June, 2007 01:57
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Withdrawing sponsorship of draft-housley-tls-authz-extns
> 
> 
> 
> * Rewrite this document as a sketch of what might be done 
> rather than a protocol and go through the independent 
> submissions track.
> 
> * Drop the proposal.
> 
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 12 Jun 2007 14:46:21 +0200

It seems to me that this draft has hit some corners in the process, but 
I would point out that Sam is not the only one who can sponsor the 
thing, and if nobody else stands up and sponsors it, that would be a 
good indication that perhaps more work is needed prior to IESG approval.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 12 Jun 2007 07:11:25 -0700

> good indication that perhaps more work is needed prior to IESG approval.

+1.

To obtain "IETF approval", there needs to be a sponsoring AD.  Sam explained 
why he feels he cannot fill that role any longer.  Whether some other AD feels 
can can serve in his stead is their individual decision.  We do not have any 
rules that compel an AD to sponsor a submission.  Indeed, being able to obtain 
a willing sponsor is considered part of the IETF vetting process.

Nothing prevents the document from being submitted directly to the RFC Editor, 
for publication as a non-IETF document.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Jun 2007 15:33:28 +0100

> for publication as a non-IETF document.

... except that TLS extensions require IETF consensus ...

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FORTIES CROMARTY FORTH: NORTHEASTERLY 3 OR 4. SLIGHT OCCASIONALLY MODERATE.
SHOWERS, RAIN LATER. MODERATE OR GOOD.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 12 Jun 2007 07:38:39 -0700

> ... except that TLS extensions require IETF consensus ...

mumble...  grrr... yeah...  mumble...

waffle: I didn't mean to cover documents that seek to be part of an existing 
IETF-approved publication set, such as enhancing a standard, or seek to be 
added to an existing IANA registration set that has restrictions.

mumble...

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 Jun 2007 11:11:22 -0400

--On Tuesday, June 12, 2007 07:11 -0700 Dave Crocker 
<[email-masked]> wrote:

> To obtain "IETF approval", there needs to be a sponsoring AD.
> Sam explained why he feels he cannot fill that role any
> longer.  Whether some other AD feels can can serve in his
> stead is their individual decision.  We do not have any rules
> that compel an AD to sponsor a submission.  Indeed, being able
> to obtain a willing sponsor is considered part of the IETF
> vetting process.
>
> Nothing prevents the document from being submitted directly to
> the RFC Editor, for publication as a non-IETF document.

That is the avenue I would prefer, but it raises another issue 
(which I think would fall into the category Eliot referred to as 
<a corner in the process>).   As Sam points out, the actual use 
of this as a protocol requires IANA registration of parameters 
and current procedures for TLS extensions and many other things 
require IETF consensus for such registrations and hence for 
publication of any document that specifies, or requests IANA 
registration of, such parameters.

There may be things that make this particular case special, but, 
for the general case, I have gradually come to think that model 
is broken.  The problem is that the IETF cannot _prevent_ 
someone from making up a parameter and using it, registered or 
not, nor can we punish someone who does so.  So, by preventing 
registration, we do little but increase the odds that one 
unregistered and unapproved extension will use the same 
parameter keywords as another, causing interoperability 
problems.  Preventing publication and registration does not 
necessarily reduce the odds that the extension will be used; it 
merely reduces the odds that a system encountering that 
extension will be able to properly identify it and easily 
determine what it is attempting to do.

Consequently, I believe that many of the <IETF Consensus 
required> registration requirements should be changed to permit 
an alternate lower threshold of:

	(1) There has been IETF review and discussion, but the
	IETF did not conclude that the idea was wise, or even
	perhaps concluded that it was a bad idea.  Note that
	this is very different from "not reviewed in the
	IETF".
	
	(2) There is a reasonable basis for concluding that the
	protocol has been, or is likely to be, deployed.

For that class of situation, I now believe that it should be 
possible to make an independent submission and, if the RFC 
Editor judges that the document is of adequate interest and 
technical and editorial quality, be published and the 
registrations made.  Of course, the document should, at that 
stage, be very clear that it is not an IETF-approved protocol 
and should ideally explain the reasons why the IETF did not 
approve it.   Similarly, the registration should be made in the 
interest of interoperability but both the "IANA Considerations" 
section of the document and the registration itself should 
clearly indicate that the registration is to prevent 
interoperability problems only and does not imply approval or 
endorsement.

Our pretending that a protocol extension will simply go away 
because we don't like it --or because we can't agree that we do 
like it-- does not make the Internet work better.

      john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jun 2007 17:22:52 +0200

John,

I'm not sure whether I agree with your proposal or not, but I think
the most concrete way forward would be a proposal for specific
wording for draft-narten-iana-considerations-rfc2434bis, which
Harald left on my plate and I left for Russ.

     Brian

On 2007-06-12 17:11, John C Klensin wrote:
> 
> 
> --On Tuesday, June 12, 2007 07:11 -0700 Dave Crocker <[email-masked]> 
> wrote:
> 
> That is the avenue I would prefer, but it raises another issue (which I 
> think would fall into the category Eliot referred to as <a corner in the 
> process>).   As Sam points out, the actual use of this as a protocol 
> requires IANA registration of parameters and current procedures for TLS 
> extensions and many other things require IETF consensus for such 
> registrations and hence for publication of any document that specifies, 
> or requests IANA registration of, such parameters.
> 
> There may be things that make this particular case special, but, for the 
> general case, I have gradually come to think that model is broken.  The 
> problem is that the IETF cannot _prevent_ someone from making up a 
> parameter and using it, registered or not, nor can we punish someone who 
> does so.  So, by preventing registration, we do little but increase the 
> odds that one unregistered and unapproved extension will use the same 
> parameter keywords as another, causing interoperability problems.  
> Preventing publication and registration does not necessarily reduce the 
> odds that the extension will be used; it merely reduces the odds that a 
> system encountering that extension will be able to properly identify it 
> and easily determine what it is attempting to do.
> 
> Consequently, I believe that many of the <IETF Consensus required> 
> registration requirements should be changed to permit an alternate lower 
> threshold of:
> 
> For that class of situation, I now believe that it should be possible to 
> make an independent submission and, if the RFC Editor judges that the 
> document is of adequate interest and technical and editorial quality, be 
> published and the registrations made.  Of course, the document should, 
> at that stage, be very clear that it is not an IETF-approved protocol 
> and should ideally explain the reasons why the IETF did not approve 
> it.   Similarly, the registration should be made in the interest of 
> interoperability but both the "IANA Considerations" section of the 
> document and the registration itself should clearly indicate that the 
> registration is to prevent interoperability problems only and does not 
> imply approval or endorsement.
> 
> Our pretending that a protocol extension will simply go away because we 
> don't like it --or because we can't agree that we do like it-- does not 
> make the Internet work better.
> 
>      john
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 12 Jun 2007 08:26:27 -0700

+1.

Then again, this is a very general issue with much of the IETF's current
efforts to assert authority over various matters.

> (1) There has been IETF review and discussion, but the IETF did not
> conclude that the idea was wise, or even perhaps concluded that it was a
> bad idea.  Note that this is very different from "not reviewed in the 
> IETF".
...
 >     Of course, the document should, at
 > that stage, be very clear that it is not an IETF-approved protocol and
 > should ideally explain the reasons why the IETF did not approve it.
 > Similarly, the registration should be made in the interest of
 > interoperability but both the "IANA Considerations" section of the document
 > and the registration itself should clearly indicate that the registration
 > is to prevent interoperability problems only and does not imply approval or
 > endorsement.

I think the incremental suggestion, here, translates into permitting the IESG 
to attach a comment to an IANA registration entry, much as it can for an 
Independent RFC document submission?

I think that's a pretty reasonable idea.

+1.

d/
-- 

   Dave Crocker

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Jun 2007 08:41:24 -0700

>Harald left on my plate and I left for Russ.

This goes beyond just rewording the IANA Considerations document. It 
requires WGs to actually understand the interoperability issues John 
brings up. There are plenty of places where a WG has required "IETF 
Consensus" where "RFC published" would be just fine, but they chose 
"IETF Consensus" because it sounded better and "this related WG just 
used it in their spec so we should too". It would be great if WGs 
would start looking at the IANA registry as something that will 
promote interoperability of their specs, not as an enforcement 
mechanism for controlling extensions (except where the protocol was 
mis-designed to have too small of a namespace for robust 
extensibility).

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 Jun 2007 11:43:58 -0400

--On Tuesday, June 12, 2007 08:26 -0700 Dave Crocker 
<[email-masked]> wrote:

> I think the incremental suggestion, here, translates into
> permitting the IESG to attach a comment to an IANA
> registration entry, much as it can for an Independent RFC
> document submission?
>

Yes.   For this case and others, comments --especially comments 
that actually say something, rather than denying knowledge or 
making assertions about lack of review that aren't true -- 
impress me as a far better idea than denying registration or 
trying to deny publication.

Again, there may be exceptions, but I think denial cases should 
require fairly strong (and public) justification.  In the 
general case, I believe the Internet is better off if even the 
most terrible of ideas is well-documents and registered --with 
appropriate warnings and pointers-- if there is any appreciable 
risk that it will be deployed and seen in the wild.

If we have created a registration space sufficiently small that 
we are concerned that registration of parameters for bad ideas 
will cause scarcity problems, then that is a problem of our 
creation that we need to fix (and avoid in the future), not 
something that justifies bad long-term policy.

   john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 12 Jun 2007 08:49:15 -0700

John C Klensin wrote:
> Again, there may be exceptions, but I think denial cases should require 
> fairly strong (and public) justification.  In the general case, I 
> believe the Internet is better off if even the most terrible of ideas is 
> well-documents and registered --with appropriate warnings and pointers-- 
> if there is any appreciable risk that it will be deployed and seen in 
> the wild.

Mostly, I think we (the community) tend to confuse the coordination role of 
registration with the approval role of standardization.

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 Jun 2007 11:51:06 -0400

> Harald left on my plate and I left for Russ.

And that last clause -- i.e., the fact that document has not 
progressed in three years or more -- may suggest either that (i) 
if modifying it is the most constructive way forward, we have a 
problem or (ii) that it is not an effective way forward, whether 
or not it is constructive.

An extension of Paul Hoffman's recent comment is that the 
community should start aggressively pushing back, at Last Call 
if necessary, on every document that makes a requirement of 
"IETF Consensus" for registration unless the need to that is 
clearly and persuasively demonstrated for the individual case. 
The way to reinforce Paul's message, with which I agree, is for 
WGs (and responsible ADs) to get the message that requirement 
will cause unnecessary pain on Last Call... possibly resulting 
in thinking more seriously about it.  That approach might be 
less constructive than the one you suggest, but it would 
probably be more effective.

To me, the fundamental question here is whether, in the last 
analysis, we consider it more important to have

	* the best and most extensive Internet interoperability
	possible or
	
	* a maximum of real or imagined IETF control over all
	protocols in use on the Internet.

We claim to believe the former and then often behave as if we 
believe the latter.

       john

---

From: Thomas Narten <[email-masked]>
Date: Tue, 12 Jun 2007 12:25:29 -0700

> > Harald left on my plate and I left for Russ.

That document is pretty much done. Indeed, it may be done. I had
folded in some comments from IANA on the last respin. I'll have to
check my notes to see if there is any other outstanding comment. My
bad for not getting the process finished.

> or not it is constructive.

IMO, completing this document is long overdue. It is a tremendous
improvement over 2434.

Some general comments on this thread. I understand the argument that
some make that we should just give out code points in all cases,
because otherwise we invite squatting. On the other hand, I do believe
that withholding code points does prevent (in some, but not all cases)
use of extensions that are potentially problematical. As one concrete
example, other SDOs are generally hesitant to endorse/use protocols
that have not been properly granted code points. This has been a
carrot/stick in the past to get those SDOs to come to the IETF with
the work rather than just having them "embrace and extend" our
protocols. Do you think this is not useful/necessary or that it can be
done in other ways?

Also, if one thinks that code points should just be given out in all
cases, how do we deal with stuff like RFC 3427? 

And, does this also mean, for example, that anyone should be granted
ICMP code points?

Are you really calling for essentially granting code points to anyone
who asks? (That is what I hear when the bottom line is that the IETF
can't say no, because, the reality is (IMO) that some only come to the
IETF because they have to. They'd just as soon do their own thing and
don't appreciate having their proposals get seriously reviewed.)

Thomas

---

From: Dave Crocker <[email-masked]>
Date: Tue, 12 Jun 2007 09:52:58 -0700

Thomas Narten wrote:
>  ... I do believe
> use of extensions that are potentially problematical. 

<rant>
This goes to the heart of the current paradigm problem with IETF 
decision-making:  There is nearly exclusive concern about preventing all cases 
of problems, no matter how occasional or minor, with little apparent concern 
for the affirmative need to *faciliate* progress.

For any interesting IETF effort, it is guaranteed that there are potential 
problems with the outcome.

So the mere citation of that potential cannot reasonably justify any decision, 
such as denial or such as imposing a requirement for approval in a process 
that is, by its nature, intended for providing coordination rather than for 
demonstration community support.
</rant>

The need is for balance, rather than the constant focus *only* on corner 
cases.  Corner cases are expensive... and rare.

d/
-- 

   Dave Crocker

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Jun 2007 09:21:23 -0400

>>>>> "p" ==   <[email-masked]> writes:

    p> Sam,

    p> While it is at each AD's discretion not to sponsor some
    p> document (and not initiate Standards Action), I don't think
    p> this discretion should extend to having a veto at the IESG
    p> table when the document and community input is considered ("if
    p> you make changes I don't like, I'll withdraw my sponsorship").

    p> It looks like our process rules don't really cover the case of
    p> withdrawing sponsorship, but the existing IESG decision-making
    p> process already allows an AD to object to publishing a
    p> document, and I believe using a "sponsorship-withdrawal-veto"
    p> instead is inappropriate.

The IESG internal process requires that anything going before the IESG
have a yes vote to be approved.  I'm unwilling to vote yes on this
document nor am I willing to dedicate my time shepherding it through
the process.  I believe that especially the allocation of my time for
individual submissions is entirely my decision to make.

I have left open the possibility that another AD would support this
work and choose to sponsor it.

But yes, I believe that the consensus of the IESG is that the sponsor
can remove their yes vote and that unless another sponsor steps
forward, that kills a document.  We had a rather long discussion about
this and my understanding of the conclusion of that discussion is that
the IESG should not approve a document that no one on the IESG
affirmatively supports.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Jun 2007 10:53:46 -0700

At 12:25 PM -0700 6/12/07, Thomas Narten wrote:
>because otherwise we invite squatting.

That is one reason to give out code points liberally, but not the 
only one. The reason that both John Klensin and I gave (and I think 
Dave Crocker echoed) is that giving out code points liberally 
increases interoperability. It gives developers stronger confidence 
that the registry is both correct (no overlapping values due to 
registration race conditions gated on RFC publication) and complete 
(no squatting).

>On the other hand, I do believe
>protocols.

Doing so inherently causes lack of interoperability during the 
carrot-stick dance, and often for a long time after the dance is 
over. That probably helps the IETF leadership but hurts developers of 
our protocols.

>Do you think this is not useful/necessary or that it can be
>done in other ways?

It is probably not necessary but it is probalby useful nonetheless. A 
different way to achieve the carrot-stick goal might be to use the 
registry to list the IETF's perceived soundness of the codepoint's 
registration. "Stanards-track RFC", "Informational RFC", "Outside 
spec; see <URL>", "Outside spec; believed to be unstable by the IESG 
on mm/dd/yy", "Outside spec; believed to have serious technical 
issues; see <http://www.iesg.org/comments/nnnn>", and so on.

>cases, how do we deal with stuff like RFC 3427?

That's a straw-man; no one on this thread said "in all cases". There 
are at least two cases where liberal registration are not good:
- A limited-size namespace (usually protocols written pre-1995)
- A namespace where the names have significant semantic value 
("microsoft", "better-auth", ...)

>who asks?

No. In order to achieve interoperability, stable documentation of the 
definition of the codepoint should always be required. Additional 
commentary from the IESG and/or IAB might also be useful.

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Jun 2007 16:50:47 -0400

There is one thing that needs to be highlighted at this 
point.  John's message come close to saying it, but it falls short.

There are at least two implementations of this TLS authorization 
extension.  These implementations use the code point that was 
assigned by IANA while this document was in the RFC Editor queue.  It 
is clear to me that this protocol can be used in ways that do not run 
into problems with the RedPhone Security IPR.  I am not a patent 
lawyer, so you need to make your own assessment of this situation. If 
others come to the same conclusion, the existing implementations may 
find deployment.  As a result of my analysis, I do not believe that 
we should hamper this deployment.  Failing to use the code point 
previously assigned by IANA would force these implementations to make changes.

Russ

At 11:11 AM 6/12/2007, John C Klensin wrote:

>(which I think would fall into the category Eliot referred to as <a 
>corner in the process>).   As Sam points out, the actual use of this 
>as a protocol requires IANA registration of parameters and current 
>procedures for TLS extensions and many other things require IETF 
>consensus for such registrations and hence for publication of any 
>document that specifies, or requests IANA registration of, such parameters.
>
>There may be things that make this particular case special, but, for 
>the general case, I have gradually come to think that model is 
>broken.  The problem is that the IETF cannot _prevent_ someone from 
>making up a parameter and using it, registered or not, nor can we 
>punish someone who does so.  So, by preventing registration, we do 
>little but increase the odds that one unregistered and unapproved 
>extension will use the same parameter keywords as another, causing 
>interoperability problems.  Preventing publication and registration 
>does not necessarily reduce the odds that the extension will be 
>used; it merely reduces the odds that a system encountering that 
>extension will be able to properly identify it and easily determine 
>what it is attempting to do.
>
>registration requirements should be changed to permit an alternate 
>lower threshold of:
>
>possible to make an independent submission and, if the RFC Editor 
>judges that the document is of adequate interest and technical and 
>editorial quality, be published and the registrations made.  Of 
>course, the document should, at that stage, be very clear that it is 
>not an IETF-approved protocol and should ideally explain the reasons 
>why the IETF did not approve it.   Similarly, the registration 
>should be made in the interest of interoperability but both the 
>"IANA Considerations" section of the document and the registration 
>itself should clearly indicate that the registration is to prevent 
>interoperability problems only and does not imply approval or endorsement.
>
>Our pretending that a protocol extension will simply go away because 
>we don't like it --or because we can't agree that we do like it-- 
>does not make the Internet work better.
>
>      john
>
>

---

From: <[email-masked]>
Date: Wed, 13 Jun 2007 12:08:14 +0300

> We claim to believe the former and then often behave as if we 

There are also cases when the latter can also promote the former.

The hurdle of getting IETF consensus and publishing an RFC does
weed out many crazy proposals that, in all fairness, would not
have made the Internet work better, and would not have promoted
interoperability. 

Or in other words: we do have many proposals for extending IETF
protocols whose primary motivation is not solving a real-world 
need, but rather finding some work for the standardization guys 
to do (or getting a PhD or something). 

Those extensions might even get "implemented" in some sense of 
the word (anyone can set up a SourceForge project), but are not 
even meant to be deployed.

If by having some control over IANA allocations we weed out of
this stuff, I have no problems with it. But I agree that the
controls should not be too strict, so that protocols that actually
get deployed are able to get the numbers, and are documented
as RFCs (but IMHO something stricter that "first come first served"
is usually beneficial).

Best regards,
Pasi

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 13 Jun 2007 05:51:58 -0700

Dave and I appear to be in agreement here.

I have spent quite a bit of time thinking what the consequences of a default by a registry of the IANA, ISBN, EUI (aka MAC address) type. My conclusion is: virtually nil.

Let us imagine that the folk who assign EUI numbers decide that they are not going to allow Iran or North Korea to register a number. This is far from theoretical, in fact it is US law today.

The Iranian manufacturer simply announces that they are going to use a particular prefix and starts making ethernet cards. If you are another manufacturer there is simply no way that you are going to accept the unauthorized Iranian assignment.

Similar strategies apply to IANA assignments, including assignment of IPv4 address space. It is best if nobody attempts to employ IANA as an Internet choke point, it is not. 

The issue is unlikely to come up unless the resource being allocated is finite: Port numbers, DNS RR codes, protocol numbers.

My personal view is that we should develop an Internet architecture that allows an infinite number of new protocols to be deployed without consumption of scarce resources, i.e. port numbers of DNS RRs. I think that it is entirely defensible for IANA to be parsimonious with such assignments because they are essentially the fabric of the Internet.

Assignment of non-finite identifiers should be a free for all. Anyone should be allowed to apply for a text based label (i.e. algorithm identifier, SRV prefix, ASN.1 OID) at any time with no process whatsoever.

Until now we have been dealing with application protocols that almost exclusively deal with the human-machine interaction: Email, Web, FTP, NNTP. Only a handful of protocols are machine-machine. This is changing with Web Services/Mashups/Semantic Web. In the future we are going to see a vast number of machine-machine protocols, only a tiny proportion of which will be standards based.

The lack of standards is a good thing, neither the IETF, W3C or OASIS or all three combined is going to have the bandwidth to standardize everything. And unlike human-machine protocols the cost of running multiple machine-machine protocols in parallel is not unacceptable as a general rule. Moreover premature standardization is a bad thing, particularly when nobody really knows what the protocols should be doing.

So in summary, the IAB should be charged with identifying the set of finite resources that IANA assigns and propose an Internet architecture in which deployment of new application layer protocols does not cause any of the finite resources to be depleted.

> From: Dave Crocker [mailto:[email-masked]] 
> Sent: Tuesday, June 12, 2007 11:49 AM
> To: John C Klensin
> Cc: [email-masked]; [email-masked]
> Subject: Re: IANA registration constraints
> 
> 
> 
> John C Klensin wrote:
> > require fairly strong (and public) justification.  In the general 
> > case, I believe the Internet is better off if even the most 
> terrible 
> > of ideas is well-documents and registered --with 
> appropriate warnings 
> > and pointers-- if there is any appreciable risk that it will be 
> > deployed and seen in the wild.
> 
> 
> Mostly, I think we (the community) tend to confuse the 
> coordination role of registration with the approval role of 
> standardization.
> 
> d/
> 
> -- 
> 
>    Dave Crocker

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Jun 2007 17:26:15 +0300

I also have the experience that a too strict policy
can be harmful. I could cite numerous examples...
On the other hand, Thomas and Pasi are also right that
too loose policy can be harmful.

You have to remember that interoperability
can be hurt or improved in many ways. Secret
code allocations, private specifications, etc. are
indeed a problem. But so are incompatible
extensions, multiple ways of doing the same
thing, etc.

My experience of the current number system is
that it is actually working fairly well. There are
exceptions, but by and large numbers are
allocated and used as they should be. I know
we do not have the IEPF (Internet Engineering
Police Force) to send when someone uses a number
against our approved RFCs, but at least in my
experience in Internet layer matters such allocations
are relatively rare. I would be interested in actual
data about this, if anyone has some, however.

I would like to see a model that has an appropriate
level of strictness... and I have a model in mind.
I do not like the idea of wholesale redefinition of
who can allocate numbers or what the various
RFC 2434 phrases mean. The different number
spaces are different, and we need to apply
different criteria for allocations in them. For
instance, its a completely different thing to
create new optional-to-recognize data attributes
than new message types; IP protocol numbers
are a scarce resource whereas some other resources
are not, etc.

And, appropriately, authors and working groups
have been laying out the rules in the IANA Considerations
section for years and years about what allocation
policies are right. I think we need to respect the
wisdom of the WG to decide on a policy issue in
their protocol. We should continue to give the power
to the working groups on this issue.

At the same we need to recognize that we've made
mistakes in this space in the past, either in the WGs
or through IESG or AD requirements. In many cases,
policies have been too strict. In some cases they have
been not defined well enough to actually work. In
yet other cases they have been too loose. Or silly,
such as the policy in RFC 2780 about IPv4 protocol
number allocations involving NDAs.

So here's my proposal:

1) Design new protocols in a way that mere field
    size is not an issue. I think we've been mostly doing
    this since mid-90s.

2) Make sure WGs think hard about the various
    interoperability tradeoffs and other issues when
    they write their IANA considerations sections.

3) Involve the WG chairs and ADs in following what
    is happening in the real world, and to take action
    if what is deployed out there starts to differ too
    much from what either the IANA registry or the
    IETF RFCs describe. For instance, we had this
    situation in EAP WG a couple of years ago, and
    started a program to make sure all EAP methods
    were in the IANA table and described in RFCs,
    created a new WG, AD sponsored some specifications,
    offered reviewers and IESG support if people took
    their specifications to the RFC Editor, etc.

4) Make sure there is ample space for experimentation
    and research. Often there isn't. Consider publishing
    an update to make this happen. We did this for many
    IP layer numbers in RFC 4727, for instance.

5) Add sufficient mechanisms for vendor-specific or
    private numbers.

6) Periodically review the existing IANA rules for your
    protocols and consider revising them for the right
    balance. Again, all-strict and free-for-all are probably
    the wrong policies; different numbers need different
    treatment. Getting the balance right may not always
    be easy, but its worthwhile. Taking another example
    from EAP, we went from free-for-all to no-allocations-until-
    wg-revises-base-spec to expert-review in the EAP
    method space. The expert review model has worked
    well for this particular purposes, because it does not
    block allocation or make unreasonable requests,
    but it does ensure there's documentation about the
    method and that the documentation answers the
    right questions.

7) Keep relatively strict rules on number spaces that
    are scarce.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Jun 2007 17:37:43 +0300

Phillip,

> My personal view is that we should develop an Internet architecture that allows an infinite number of new protocols to be deployed without consumption of scarce resources, i.e. port numbers of DNS RRs.
...
> So in summary, the IAB should be charged with identifying the set of finite resources that IANA assigns and propose an Internet architecture in which deployment of new application layer protocols d…

I'm definitely in favor of improving the situation. And for applications
protocols this is probably an easier problem to begin with. And as
I said in the previous e-mail, as far as I know, most new work uses
field sizes and types that have less scarcity.

However, the Internet runs to a large extent on protocols that were
designed decades ago, and some of those protocols have number
spaces that  are very finite. I don't want to run out of protocol
numbers, DHCP message types, etc.

Jari

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 13 Jun 2007 07:54:15 -0700

That is why I think this is an area that the IAB should look at.

I don't think we should be worried about running out of protocol numbers. Deployment of IPv6 and multicast pretty much demonstrate that it is a non-issue.

At the application level we just need to persuade people that, no it is not acceptable or sustainable to have an internet architecture that is dependent on parsimonious assignment of IP Port or DNS RR numbers.

Where we have a resource code consumption issue we should either declare the protocol essentially closed for extensions or work out a way to introduce a sustainable extension mechanism.

So for example on DHCP I think it would be entirely justifiable to say 'this is an infrastructure for assigning IP addresses and specifying the domain name for the LAN and we do not therefore anticipate assignment of additional codes on an ongoing basis'. This does not rule out special pleading (e.g. geopriv) but clearly signals to people to think somewhere else.

Alternatively if we think that every new protocol is going to need a DHCP slot to advertise its existence then we would have to work out a way to insert an extensible mechanism.

In the case of DHCP the first approach is clearly the way to go.

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, June 13, 2007 10:38 AM
> To: Hallam-Baker, Phillip
> > My personal view is that we should develop an Internet 
> architecture that allows an infinite number of new protocols 
> to be deployed without consumption of scarce resources, i.e. 
> port numbers of DNS RRs.
> ...
> > So in summary, the IAB should be charged with identifying 
> the set of finite resources that IANA assigns and propose an 
> Internet architecture in which deployment of new application 
> layer protocols does not cause any of the finite resources to 
> be depleted.
> >   
> 
> I'm definitely in favor of improving the situation. And for 
> applications protocols this is probably an easier problem to 
> begin with. And as I said in the previous e-mail, as far as I 
> know, most new work uses field sizes and types that have less 
> scarcity.
> 
> However, the Internet runs to a large extent on protocols 
> that were designed decades ago, and some of those protocols 
> have number spaces that  are very finite. I don't want to run 
> out of protocol numbers, DHCP message types, etc.
> 
> Jari
> 
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 13 Jun 2007 11:21:23 -0400

Can we please leave the specific opinions about DHCP out of this discussion?
The dhc WG has done its due diligence, with review and support from the IETF
and the IESG, to put into place processes to govern assignment of extensions
to DHCP and to accommodate future extensions to both DHCPv4 and DHCPv6 in
the option code space design.  This discussion is clearly not the place for
opinions about how future extensions to DHCP ought to be managed.

If DHCP must be brought into the discussion, please read and understand the
relevant RFCs and policies at IANA before using DHCP as a whipping
boy/example.

- Ralph (who's not bitter at all)

On 6/13/07 10:54 AM, "Hallam-Baker, Phillip" <[email-masked]> wrote:

> I don't think we should be worried about running out of protocol numbers.
> Deployment of IPv6 and multicast pretty much demonstrate that it is a
> non-issue.
> 
> At the application level we just need to persuade people that, no it is not
> acceptable or sustainable to have an internet architecture that is dependent
> on parsimonious assignment of IP Port or DNS RR numbers.
> 
> Where we have a resource code consumption issue we should either declare the
> protocol essentially closed for extensions or work out a way to introduce a
> sustainable extension mechanism.
> 
> 
> So for example on DHCP I think it would be entirely justifiable to say 'this
> is an infrastructure for assigning IP addresses and specifying the domain name
> for the LAN and we do not therefore anticipate assignment of additional codes
> on an ongoing basis'. This does not rule out special pleading (e.g. geopriv)
> but clearly signals to people to think somewhere else.
> 
> Alternatively if we think that every new protocol is going to need a DHCP slot
> to advertise its existence then we would have to work out a way to insert an
> extensible mechanism.
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Jun 2007 08:24:56 -0700

At 5:51 AM -0700 6/13/07, Hallam-Baker, Phillip wrote:
>I have spent quite a bit of time thinking what the consequences of a 
>default by a registry of the IANA, ISBN, EUI (aka MAC address) type. 
>My conclusion is: virtually nil.

That kinda depends on what is part of that "default". I would 
absolutely want every codepoint to have the best possible reference 
to a document that shows how the codepoint is used. An RFC is best 
(as long as the registry is updated when the RFC is); an Internet 
Draft is OK; a reference to an online non-IETF document is 
reasonable; an email address is barely acceptable. But there has to 
be some way for a developer who needs to know what to do when faced 
with the use of the codepoint to get some information.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Jun 2007 08:27:35 -0700

>have made the Internet work better, and would not have promoted

It does not need to promote interoperability; being interop-neutral 
is sufficient. How does giving a codepoint to someone with a crazy 
(and let's say even dangerous to the Internet) idea hurt 
interoperability? It seems to be interop-neutral.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 13 Jun 2007 08:38:51 -0700

If the repository is active, rather than passive this is of course possible.

For example we might map out a DNS spec within the .arpa TLD and use it to distribute machine readable descriptions of the code points. Something of the sort could be done for EUI-48 and -64 space as well of course.

It does increase leverage and the ability to enforce assignments to a degree but only to the extent that running code actually refers to the registry and only if there is no possibility of setting up a rival registry.

At the end of the day it is impossible to prevent a fork here, there is no magic token in the Internet architecture that says 'mine'.

I suspect that if we ever get to the point where the DNS root is signed that there will be multiple signature authorities and multiple signing keys involved. 

> From: Paul Hoffman [mailto:[email-masked]] 
> Sent: Wednesday, June 13, 2007 11:25 AM
> To: [email-masked]; [email-masked]
> Subject: RE: IANA registration constraints
> 
> absolutely want every codepoint to have the best possible 
> reference to a document that shows how the codepoint is used. 
> An RFC is best (as long as the registry is updated when the 
> RFC is); an Internet Draft is OK; a reference to an online 
> non-IETF document is reasonable; an email address is barely 
> acceptable. But there has to be some way for a developer who 
> needs to know what to do when faced with the use of the 
> codepoint to get some information.
> 
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 13 Jun 2007 12:19:58 -0400

--On Wednesday, June 13, 2007 08:27 -0700 Paul Hoffman 
<[email-masked]> wrote:

>> The hurdle of getting IETF consensus and publishing an RFC
>> does weed out many crazy proposals that, in all fairness,
>> would not have made the Internet work better, and would not
>> have promoted interoperability.
>
> It does not need to promote interoperability; being
> interop-neutral is sufficient. How does giving a codepoint to
> someone with a crazy (and let's say even dangerous to the
> Internet) idea hurt interoperability? It seems to be
> interop-neutral.

As Brian has suggested, this is a discussion that should really 
be had around the specifics of draft-narten-iana...  I believe 
that discussion needs to  be a community one leading to a BCP, 
because some fundamental policy issues are involved that 
interact with the IAB's role with regard to IANA and general 
community interests, not just the policy role that falls to the 
IESG as the result of its management/steering responsibilities.

Fortunately or unfortunately, I don't believe it is worth 
spending more time on that document until there are firm 
commitments to moving it forward.  Until then, the WGs and IESG 
will do what they like, with or without adequate consideration 
of implications, and the community will need to express its 
opinions and manage by Last Call comments and appeal, if at all.

Following Paul's earlier comment, I do believe that there is 
something the IESG could do on its own initiative and without 
much fuss that might help with situations like this going 
forward.  The vast majority of the community, at best, skims 
Last Call announcements and decides to ignore most of the 
documents because nothing controversial or important to their 
work leaps out at them.   But there are cases in which the IESG, 
or WG Chairs, or others know that there are issues --either 
technical or procedural ones, but especially the latter-- that 
might be controversial.  I'd like to see those explicitly 
identified in Last Call announcements, just as 
draft-klensin-norm-ref (RFC4897 RSN) requires that downward 
references be identified.

Given this thread, I believe that any registration requirement 
stronger than "good, publicly-available, documentation required" 
(deliberately not using Thomas's terminology to avoid getting 
tied up with the specifics of those categories) should be called 
out in that way in Last Call announcements.

That said, I think strawmen are very dangerous here and that we 
should be looking at exactly what is being proposed.  To my 
knowledge, no one has seriously suggested that we should give 
numbers or parameter values to everyone who asks or every 
half-baked idea that comes along.

I think real specifications of what the requested parameter will 
mean and be used for are important.  I think there is a 
difference between registering a parameter for a non-standard 
specification that is already deployed and in successful use and 
registering one for a wild idea by one person.  I think we ought 
to be thinking seriously about how to handle some registrations/ 
number allocations that were made on the basis of I-Ds which the 
IESG and RFC Editor then declined to publish as RFCs.  And the 
solution is probably not to withdraw the registrations, at least 
IMO.

But, again, unless the IESG believes that this topic is 
important enough to give priority and invest energy in looking 
at policies and moving documents forward, I fear that this 
discussion is largely a waste of time.

    john

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 13 Jun 2007 22:54:23 +0200

One possibility, if one wants to get things through without modifying 
current process, is to:

a) publish the specification as an independent submission
b) publish an one-line document, with IETF consensus, saying that "the 
codepoint x is for use with protocol Y, which is not an IETF protocol".

Somewhat bureaucratic and a little bit silly, but it can be done without 
violating any process rule currently in existence (afaik; someone might 
have invented one while I was not looking :-)

Thanks to Sam Hartman and the DLV work for making me thing of it....

--On 12. juni 2007 16:50 -0400 Russ Housley <[email-masked]> wrote:

> There is one thing that needs to be highlighted at this point.  John's
> message come close to saying it, but it falls short.
>
> extension.  These implementations use the code point that was assigned by
> IANA while this document was in the RFC Editor queue.  It is clear to me
> that this protocol can be used in ways that do not run into problems with
> the RedPhone Security IPR.  I am not a patent lawyer, so you need to make
> your own assessment of this situation. If others come to the same
> conclusion, the existing implementations may find deployment.  As a
> result of my analysis, I do not believe that we should hamper this
> deployment.  Failing to use the code point previously assigned by IANA
> would force these implementations to make changes.
>
> Russ
>

---

From: <[email-masked]>
Date: Thu, 14 Jun 2007 07:27:45 +0300

> interoperability? It seems to be interop-neutral.

I think giving out codepoints freely would in many cases encourage
having multiple (often half-baked) solutions to the same problem.

To give one example we both worked on: I think it's good we didn't
allocate codepoints to all the individual MOBIKE protocol proposals
(mine, Tero's, Francis's), and instead were "forced" to work together
and converge on a single protocol.

Probably the "market" would have eventually picked one of them as 
the winner, but meanwhile, the situation would IMHO not have been
interop-neutral. (And working together also produced a better 
protocol than any of the individual drafts were.)

I'm not saying that this particular cooperation would not have
happened with less strict IANA policies -- but I do believe that 
if the bar for getting codepoints and publishing an RFC would be
significantly lower than today, we would have a much larger number 
of poorly concieved and overlapping extensions to various IETF 
protocols. (And IMHO that would not always be interop-neutral.)

However: I do agree with John Klensin's statement that "there is a 
difference between registering a parameter for a non-standard 
specification that is already deployed and in successful use and 
registering one for a wild idea by one person."

Best regards,
Pasi

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jun 2007 09:55:08 +0200

> numbers, DHCP message types, etc.

Exactly. There are very tight namespaces where we need to apply pretty
strict rules to avoid hitting a brick wall, but nobody can disagree that
we should design to avoid creating new brick walls.

But in the namespaces where there is no brick wall, there are nevertheless
reasons to be careful. I'd suggest that people should not only look
at the text of 2434bis, but also at RFC 4775 and at
draft-carpenter-extension-recs-02.txt. Comments on the latter are very
welcome.

I don't believe we should do anything that can be interpreted as condoning
misappropriation of IANA-assigned values. But I do agree with John Klensin
that when something is in actual use, that fact should be recognized,
and registered with a factual comment. That helps interoperability even
if it offends our formalities.

     Brian

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Jun 2007 07:45:39 -0700

>having multiple (often half-baked) solutions to the same problem.

This is the crux of the issue. Does the IETF want to control bad 
ideas through the IETF process *and* the IANA registry, or just the 
IETF process? You are proposing the former, I am proposing the 
latter. I trust that the IETF process works fine and doesn't need a 
backup crutch from IANA. I also trust that developers who look in the 
IANA registry and see four entries, one of which is an RFC and three 
of which are URLs to individuals and corporate web sites, to be able 
to make the right decision about what they want to implement.

>of poorly concieved and overlapping extensions to various IETF

Fully agree. But we're not talking about lowering the bar to 
publishing RFCs, only to registering codepoints.

>(And IMHO that would not always be interop-neutral.)

Why not? As long as the reader of the IANA registry can ascertain 
which codepoint owner is at a particular level, how would that affect 
interop?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 14 Jun 2007 08:26:04 -0700

I am more concerned with timing.

All protocols are experimental when they are started. If I need to go through a three year process before I can get the number I need assigned to start my experiment, well I am not going to, an nor is anyone else.

That is why I would draw the boundary between layers 6 and 7. Experiments at layer 5 are likely to have rather more serious consequences than at layer 7. This is fortunate since the vast majority of experiments people want to perform are at the application level.

On the 'misapropriation' issue, I think that it is important that people understand that nobody owns the Internet and nobody can own it. Just because the IETF won the global data design competition in the 1990s does not mean that it has perpetual ownership of it. IBM once assumed that it owned the PC standard, turns out it did not.

That is not the same as saying that it is impossible for IANA to exercise control or that the IETF should not attempt to exercise control in certain areas. What it means is that the IETF needs to be very careful in the areas where it attempts to exercise influence and even more careful in the areas where it attempts to exercise control.

The comment I would make on the draft is that it does not differentiate between the protocol layers. 

What I would like to see the IETF produce is the type of 'software contract' Tony Hoare suggested a software module should present to its environment. 

I would like to reduce certain types of registration to essentially filling in a Web form. So for example someone who has a new crypto algorithm enters the details into a form which spits out algorithm identifiers. In that case I would really want to avoid publishing an RFC of any type or have the authors be able to make any claim to have been involved in IETF process since 99% of the time the algorithm will be junk.

The main use here would be for application layer protocols. I want every protocol to be assigned an identifying SRV prefix and URI at the earliest possible moment. The documentation can follow.

If it is necessary to impose some sort of velocity controls we could charge for registrations or alternatively have some non-charging velocity control such as require people to get to level 42 on net.rogue. A mechanism that I think would work very well here would be based on social network size with some form of breadth and connectedness constraints.

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Thursday, June 14, 2007 3:55 AM
> To: [email-masked]
> Cc: [email-masked]
> > applications protocols this is probably an easier problem to begin 
> > with. And as I said in the previous e-mail, as far as I 
> know, most new 
> > work uses field sizes and types that have less scarcity.
> > 
> > designed decades ago, and some of those protocols have 
> number spaces 
> > that  are very finite. I don't want to run out of protocol numbers, 
> > DHCP message types, etc.
> 
> Exactly. There are very tight namespaces where we need to 
> apply pretty strict rules to avoid hitting a brick wall, but 
> nobody can disagree that we should design to avoid creating 
> new brick walls.
> 
> But in the namespaces where there is no brick wall, there are 
> nevertheless reasons to be careful. I'd suggest that people 
> should not only look at the text of 2434bis, but also at RFC 
> 4775 and at draft-carpenter-extension-recs-02.txt. Comments 
> on the latter are very welcome.
> 
> I don't believe we should do anything that can be interpreted 
> as condoning misappropriation of IANA-assigned values. But I 
> do agree with John Klensin that when something is in actual 
> use, that fact should be recognized, and registered with a 
> factual comment. That helps interoperability even if it 
> offends our formalities.
> 
>      Brian
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 14 Jun 2007 08:35:12 -0700

Every protocol begins as a wild idea by one person. So I don't accept John's point.

Forcing groups together is not necessarily a good idea. The counter example I would give is SAML, WS-Trust and OpenID. Merging protocols prematurely can be a mistake. The groups have to be speaking the same language for a start.

Requiring a merger for standards process is a good idea, usually, but standards are not always the best approach. If you don't yet understand the problem space you should not be wasting peoples time on the standards circuit.

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, June 14, 2007 12:28 AM
> To: [email-masked]; [email-masked]
> Subject: RE: IANA registration constraints (was: Re: 
> Withdrawingsponsorship...)
> 
> Paul Hoffman wrote:
> > 
> does weed 
> > >out many crazy proposals that, in all fairness, would not 
> have made 
> > >the Internet work better, and would not have promoted 
> > >interoperability.
> > 
> interop-neutral is 
> > sufficient. How does giving a codepoint to someone with a 
> crazy (and 
> > let's say even dangerous to the Internet) idea hurt 
> interoperability? 
> I think giving out codepoints freely would in many cases 
> encourage having multiple (often half-baked) solutions to the 
> same problem.
> 
> To give one example we both worked on: I think it's good we 
> didn't allocate codepoints to all the individual MOBIKE 
> protocol proposals (mine, Tero's, Francis's), and instead 
> were "forced" to work together and converge on a single protocol.
> 
> Probably the "market" would have eventually picked one of 
> them as the winner, but meanwhile, the situation would IMHO 
> not have been interop-neutral. (And working together also 
> produced a better protocol than any of the individual drafts were.)
> 
> I'm not saying that this particular cooperation would not 
> have happened with less strict IANA policies -- but I do 
> believe that if the bar for getting codepoints and publishing 
> an RFC would be significantly lower than today, we would have 
> a much larger number of poorly concieved and overlapping 
> extensions to various IETF protocols. (And IMHO that would 
> not always be interop-neutral.)
> 
> However: I do agree with John Klensin's statement that "there 
> is a difference between registering a parameter for a 
> non-standard specification that is already deployed and in 
> successful use and registering one for a wild idea by one person."
> 
> Best regards,
> Pasi
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 14 Jun 2007 08:48:04 -0700

It seems to me that the IANA registry could provide more influence for the IETF if run as Paul suggests.

So I go to the code page for the USELESS cipher. It tells me that the cipher has not been approved by the IETF, has not been endorsed by any professional bodies and is not an IETF standard.

We would at last have a mechanism to trump the usual claim that an internet draft has been submitted so please consider me as good as being a standard.

Or another organization could run the registry.

> Sent: Thursday, June 14, 2007 10:46 AM
> To: [email-masked]; [email-masked]
> Withdrawing sponsorship...)
> 
> This is the crux of the issue. Does the IETF want to control 
> bad ideas through the IETF process *and* the IANA registry, 
> or just the IETF process? You are proposing the former, I am 
> proposing the latter. I trust that the IETF process works 
> fine and doesn't need a backup crutch from IANA. I also trust 
> that developers who look in the IANA registry and see four 
> entries, one of which is an RFC and three of which are URLs 
> to individuals and corporate web sites, to be able to make 
> the right decision about what they want to implement.
> 
> have happened 
> >with less strict IANA policies -- but I do believe that if 
> the bar for 
> >getting codepoints and publishing an RFC would be 
> significantly lower 
> >than today, we would have a much larger number of poorly 
> concieved and 
> >overlapping extensions to various IETF protocols.
> 
> Why not? As long as the reader of the IANA registry can 
> ascertain which codepoint owner is at a particular level, how 
> would that affect interop?
> 
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: <[email-masked]>
Date: Thu, 14 Jun 2007 17:02:19 +0100

> We would at last have a mechanism to trump the usual claim 
> that an internet draft has been submitted so please consider 
> me as good as being a standard.

ULA-C was in a draft that has expired and was in fact specifically
dropped by the WG that produced the ULA RFC. Nevertheless, at least one
person believes that means ULA-C is as good as being a standard and has
asked the RIRs to begin operating a registry for ULA-C addresses.
 
> Or another organization could run the registry.

Well, if you want a centrally-registered ULA prefix that is globally
unique, you can get one from this registry:
http://www.sixxs.net/tools/grh/ula/

NOTE: this is not the same as ULA-C, this is a central registry of
pseudo-randomnly generated ULAs as defined in RFC 4193.

--Michael Dillon

---

From: Bob Braden <[email-masked]>
Date: Thu, 14 Jun 2007 10:10:04 -0700

Phillip Hallam-Baker wrote in part:

>On the 'misapropriation' issue, I think that it is important that people 
>understand that nobody owns the Internet and nobody can own it. Just 
>because the IETF won the global data design competition in the 1990s does 
>not mean that it has perpetual ownership of it.

Seems like a peculiar version of the actual history of the IETF and of the 
Internet design.  But, let's NOT
get into a deep philosophical discuss of what "ownership" means.

Bob Braden

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 14 Jun 2007 10:17:32 -0700

Seems like a way of saying 'I am going to contradict you without justifying my position in terms that allow me to criticize any request to do so'.

> From: Bob Braden [mailto:[email-masked]] 
> Sent: Thursday, June 14, 2007 1:10 PM
> Cc: Brian E Carpenter; [email-masked]; [email-masked]
> >On the 'misapropriation' issue, I think that it is important that 
> >people understand that nobody owns the Internet and nobody 
> can own it. 
> >Just because the IETF won the global data design competition in the 
> >1990s does not mean that it has perpetual ownership of it.
> 
> 
> Seems like a peculiar version of the actual history of the 
> IETF and of the Internet design.  But, let's NOT get into a 
> deep philosophical discuss of what "ownership" means.
> 
> Bob Braden
> 
> 
> 
>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 14 Jun 2007 17:08:13 -0700

> registration of, such parameters.

To be clear, in this particular case, is there no room for getting
assignments out of a vendor-specific case? That escape clause is in
many name spaces...

I am all-too-aware that there are corner cases that come up where the
actual IANA considerations rules don't really handle a situation
well. Even when WGs/authors do to right good IANA Considerations, the
reality is that its hard to think of all things in
advance. Consequently,
draft-narten-iana-considerations-rfc2434bis-06.txt added a new rule
(not in 2434) designed to cover such cases:

5.3.  Overriding Registration Procedures

   Since RFC 2434 was published, experience has shown that the
   documented IANA considerations for individual protocols do not always
   adequately cover the reality on the ground. For example, many older
   routing protocols do not have documented, detailed IANA
   considerations. In addition, documented IANA considerations are
   sometimes found to be too stringent to allow even working group
   documents (for which there is strong consensus) to obtain code points
   from IANA in advance of actual RFC publication.  In other cases, the
   documented procedures are unclear or neglected to cover all the
   cases. In order to allow assignments in individual cases where there
   is strong IETF consensus that an allocation should go forward, but
   the documented procedures do not support such an assignment, the IESG
   is granted authority to approve assignments in such cases. The
   intention is not to overrule properly documented procedures, or to
   obviate the need for protocols to properly document their IANA
   Considerations. Instead, the intention is to permit assignments in
   individual cases where it is obvious that the assignment should just
   be made, but updating the IANA process just to assign a particular
   code point is viewed as too heavy a burden.

   In general, the IETF would like to see deficient IANA registration
   procedures for a namespace revised through the IETF standards
   process, but not at the cost of unreasonable delay for needed
   assignments. If the IESG has had to take the action in this section,
   it is a strong indicator that the IANA registration procedures should
   be updated, possibly in parallel with ongoing protocol work.

If the above text were in effect today, would it be sufficient to
cover the situation at issue here? (Now would be an excellent time to
consider updates/clarifications to the above text.)

Thomas

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Jun 2007 09:55:12 +0200

On Tue, Jun 12, 2007 at 09:52:58AM -0700,
 Dave Crocker <[email-masked]> wrote 
 a message of 37 lines which said:

> There is nearly exclusive concern about preventing all cases of
> problems, no matter how occasional or minor, with little apparent
> concern for the affirmative need to *faciliate* progress.

True. If IP had been subject to the same level of scrutiny that is
applied to Identifier/locator separation proposals on the RAM list, we
would never have adopted IP (a protocol with so many security
holes)...

---

From: <[email-masked]>
Date: Fri, 15 Jun 2007 11:25:25 +0300

Thomas Narten wrote:

> cover the situation at issue here? (Now would be an excellent time
> to consider updates/clarifications to the above text.)

I don't think so. The text allows IESG to override the allocation
procedures when they judge there is "strong IETF consensus" to do 
so.

In the situation at issue here: IMHO the main question is whether 
we have rough consensus that this particular draft should be 
published as non-Standards Track RFC.

If the IESG thinks we have this consensus, they would just approve 
the document, and the override procedure would not be needed. If 
the IESG thinks there is no consensus (or it's too rough), the 
override rule wouldn't apply.

So while I think the override rule might be valuable in some
cases, it doesn't seem to help here. 

Best regards,
Pasi

---

From: <[email-masked]>
Date: Fri, 15 Jun 2007 12:10:26 +0300

> which codepoint owner is at a particular level, how would that affect 

Being able to ascertain what the level is isn't enough; you also 
need to know (and more importantly, care) about the differences 
in the levels :-)

I'd say there are lot of implementors who don't really care that
much for the distinctions between an individual Internet-Draft, 
a WG draft, an Experimental RFC, or Proposed Standard RFC.

But if only the latter two (or three) would have proper numbers 
in them (instead of TBD-BY-IANA), that would send a clear message
that "this not ready yet"... (but of course, this doesn't always
work; if there's strong enough pressure to implement, people
will "invent" some numbers there)

Best regards,
Pasi

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Jun 2007 13:33:23 +0200

On 2007-06-15 10:25, [email-masked] wrote:
> the document, and the override procedure would not be needed. 

Yes it would, if registration normally requires Standards Action.

> If 

I think another aspect is whether the IETF chooses to give IANA
some discretion to document usage which is widespread, but not
covered by any IETF document or procedure. It may not be appropriate
to expect the IESG to spend time on every case, or even to look for
consensus when what is being documented is simply a fact of life.
As a friend of mine used to say, you can't vote on facts.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Fri, 15 Jun 2007 20:14:32 +0700

Date:        Thu, 14 Jun 2007 17:08:13 -0700
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | (Now would be an excellent time to
  | consider updates/clarifications to the above text.)

Aside from the minor problem that the paragraph you quoted is way more
wordy and chatty than is really needed, it gets the "should be" procedure
all wrong.

The IANA is the Internet Assigned Numbers AUTHORITY and should be treated
that way - allowing assignment requirements in specs to be ignored in cases
where they're obviously wrong is fine.   But is the IANA which (who) should
make the decision, not the IESG.

By all means, require the IANA to notify the IESG (or IETF) in advance,
and allow time for objections to an assignment (or for general input to
the IANA which may influence either the yes/no decision, or in some cases
the actual value assigned).  But the decision belongs to IANA, not the IESG
(just as the final decision whether to publish a RFC rests with the RFC
editor, and not the IESG).

There's a tendency, especially in procedures authored by IESG (or ex-IESG)
members for everything to be made the responsibility of the IESG.  That's
the wrong approach in most cases.

Under the same section heading you have now (5.3....) the text I would
include would be something like...

	Not withstanding any requirement in any document published before
	or after this specification, the IANA has the power to allocate
	a code point in any IANA maintained registry whenever it appears to
	the IANA that doing so is in the best interests of the Internet
	community.

	Before the IANA makes a registry entry in accordance with this
	procedure it shall advise the IESG (or the IETF as a whole) of
	the request for registration, and wait a period of not less than
	21 days to receive comments and advice from the Internet community
	before proceeding with the registration.

That's all that's needed (the "21 days" is just an arbitrary number, seems
long enough without being too long, but use whatever you prefer).

kre

---

From: Thomas Narten <[email-masked]>
Date: Fri, 15 Jun 2007 09:16:25 -0400

> procedures when they judge there is "strong IETF consensus" to do 

The text is very much intended to allow the IESG to say "IANA, please
go ahead and make the assignment", even in the absence of having
approved the document. The key wording is:

   In order to allow assignments in individual cases where there is
   strong IETF consensus that an allocation should go forward, but the
   documented procedures do not support such an assignment, the IESG
   is granted authority to approve assignments in such cases.

The intention with "documented procedures do not support such an
assignment" was to cover things where by the normal rules (e.g.,
approval to publish as an RFC) aren't satisfiable, yet there is
support to assign the code point anyway.

I agree that the wording "strong consensus" is key. Perhaps that bar
is too high -- it was intended to ensure that this procedure was not
invoked in cases where there was real opposition to the code point
assignment. I.e., to be an exception mechanism rather than a common
occurrence.

While consensus may not exist to publish the docuemnt, that is not the
same thing as a lack of consensus for making the code point
assignment.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 15 Jun 2007 09:28:29 -0400

> make the decision, not the IESG.

Um, this train left the station a LONG time ago. RFC 2434 (and
existing practice) have given the role of approving assignments to the
technical/protocol experts that created that name space. That is why
we have IANA considerations sections.

The IESG is just the default fallback for when the IANA considerations
as written don't properly work for some reason. But in general, and in
the vast majority of cases today, the system works -- with assignments
being made as the original registry creators intended (and without the
IESG playing any role). And the intention in giving the IESG that role
is not for the IESG to step in and do the work themselves, but give
them the authority/responsibility to go find the right people to do
the evaluation. But the buck has to stop somewhere, and in the IETF,
that is the IESG.

IANA does not make the decisions on what to assign and what not to
assign, unless it has been given clear criteria when it can do so. In
general, IANA does not have the expertise to make such
evaluations. Many are very protocol specific and require an evaluation
by someone with an understanding of the protocols that will be using
the assignment.

Thomas

---

From: Robert Elz <[email-masked]>
Date: Fri, 15 Jun 2007 20:50:42 +0700

Date:        Fri, 15 Jun 2007 09:28:29 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | Um, this train left the station a LONG time ago. RFC 2434 (and
  | existing practice) have given the role of approving assignments to the
  | technical/protocol experts that created that name space. That is why
  | we have IANA considerations sections.

Of course - maybe my wording wasn't clear enough, but I didn't intend to
replace that, merely to add the safety net "unusual case" mechanism in
a different way than your proposal.

This is just as the IESG approves the vast majority of new RFCs following
the regular IETF process, but the RFC Editor can publish others if he
feels inclined (after taking advice.)

  | But the buck has to stop somewhere, and in the IETF, that is the IESG.

And in this case, this is exactly the point.   IANA is the
INTERNET Assigned Numbers Authority, not the IETF Assigned Numbers
Authority - and the code points it assigns and the registries it
maintains are used by the Internet as a whole, not just that part of
it that participates in the IETF.

  | IANA does not make the decisions on what to assign and what not to
  | assign, unless it has been given clear criteria when it can do so.

That may be as it is now, but it is not the way it should be.  There's
no sense having something that we call an authority of it has no authority.

  | In general, IANA does not have the expertise to make such
  | evaluations.

I'm not sure I necessarily believe that, but in any case, that's what
advice is for - to obtain any extra information that's needed.   The only
question really is who gets to be the final umpire, and this is a case
where it most certainly should not be the IESG.

kre

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 15 Jun 2007 10:30:08 -0400

Am I confused? The allocation required an IETF Consensus. A consensus
was determined and the code point allocated. How can it make any
difference if the consensus determination is later reversed? Why should
it make a difference to that allocation if the reversal occurred before
or after the RFC was published?

Because the IETF believes in interoperability, once a code point is
allocated it is, for all practical purposes, never taken back. The use
might be deprecated or something but the code point isn't re-used
because their might be use of implementations that depend on that code
point.

Donald

-----Original Message-----
From: Harald Tveit Alvestrand [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2007 4:54 PM
To: Russ Housley; John C Klensin; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Withdrawing sponsorship of draft-housley-tls-authz-extns

Thanks to Sam Hartman and the DLV work for making me think of it....

---

From: Sam Hartman <[email-masked]>
Date: Fri, 15 Jun 2007 10:41:19 -0400

>>>>> "Robert" == Robert Elz <[email-masked]> writes:

    Robert>     Date:        Fri, 15 Jun 2007 09:28:29 -0400
    Robert>     From:        Thomas Narten <[email-masked]>
    Robert>     Message-ID:  <[email-masked]>

    Robert>   | Um, this train left the station a LONG time ago. RFC 2434 (and
    Robert>   | existing practice) have given the role of approving assignments to the
    Robert>   | technical/protocol experts that created that name space. That is why
    Robert>   | we have IANA considerations sections.

    Robert> Of course - maybe my wording wasn't clear enough, but I didn't intend to
    Robert> replace that, merely to add the safety net "unusual case" mechanism in
    Robert> a different way than your proposal.

    Robert> This is just as the IESG approves the vast majority of new RFCs following
    Robert> the regular IETF process, but the RFC Editor can publish others if he
    Robert> feels inclined (after taking advice.)

    Robert>   | But the buck has to stop somewhere, and in the IETF, that is the IESG.

    Robert> And in this case, this is exactly the point.   IANA is the
    Robert> INTERNET Assigned Numbers Authority, not the IETF Assigned Numbers
    Robert> Authority - and the code points it assigns and the registries it
    Robert> maintains are used by the Internet as a whole, not just that part of
    Robert> it that participates in the IETF.

For what it is worth, I completely disagree with this approach.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 Jun 2007 08:56:32 -0700

>a WG draft, an Experimental RFC, or Proposed Standard RFC.

Fully agree. Where we disagree is whether or not the IETF should do 
something about that more than just saying what our levels are and 
what they mean. I believe that needs to be sufficient, and our 
energies are best spent on our standards efforts.

>will "invent" some numbers there)

Enforcement of our standards process by hiding things that are 
outside of the process seems both dishonest to, and disrespectful of, 
typical developers. That does not lead them to the type of 
interoperability we want.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 Jun 2007 08:52:38 -0700

>it that participates in the IETF.

I agree with Sam: this is completely the wrong approach. The 
registries that IANA maintains have obvious constituencies. The vast 
majority have the IETF as a constituency; only a few (the DNS root 
zone) have the whole Internet as a constituency.

If a different SDO such asks IANA to start maintaining that SDO's 
registration, IANA should not let the IESG change the values there, 
and at the same time, IANA should not let the other SDO change the 
IETF-based registries.

--Paul Hoffman, Director
--VPN Consortium

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Jun 2007 15:24:50 -0400

> would never have adopted IP (a protocol with so many security
perhaps. but IP was designed in a more naive, and less hostile, time.

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Jun 2007 15:33:43 -0400

Dave Crocker wrote:
> decision-making:  There is nearly exclusive concern about preventing
> all cases of problems, no matter how occasional or minor, with little
> apparent concern for the affirmative need to *faciliate* progress.
>
> For any interesting IETF effort, it is guaranteed that there are
> potential problems with the outcome.
>
> So the mere citation of that potential cannot reasonably justify any
> decision, such as denial or such as imposing a requirement for
> approval in a process that is, by its nature, intended for providing
> coordination rather than for demonstration community support.
> </rant>
>
> The need is for balance, rather than the constant focus *only* on
> corner cases.  Corner cases are expensive... and rare.

I agree with the need for balance, but strongly disagree with the
characterization of corner cases.  For example, corner cases that are
recognized as security holes have a tendency to become frequent
exploits.  And for anything that operates at the scale of today's
Internet, rare cases can cause major problems even when they're not
security issues.

It would be grossly irresponsible for IETF to ignore identified
problems.  Of course such problems should be evaluated in terms of
risk-versus-benefit.   But the discussion is naturally going to focus on
the details of those problems rather than the big-picture benefit.  You
can that the big picture is still being kept in mind because the goal of
the discussion of the problems is generally to find a way to solve those
problems rather than to throw out the flawed protocol entirely.  While I
certainly agree that we can get bogged down in fixing trivial problems,
especially when those problems are identified late in the process (or
identified early, and ignored), I also think we don't go back to the
drawing board often enough.

Keith

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 17 Jun 2007 14:41:08 +0200

> it that participates in the IETF.
In my opinion: No. There's no magic in names.

The IANA is a function carried out by a department of ICANN. It has 
inherited the name from the work done by Jon Postel since the time when 
the Internet was small enough that all the users knew each other by 
name. But there is no magic in the name that makes this department have 
any more credibility than any other group that performs functions.

We, as the IETF, whose mission it is to "make the Internet work better", 
need to look at what the function we want to have performed is, and 
whether the current entity is the best one to perform the function we 
want performed. Others have to perform the same evaluation when 
entrusting their registration functions to this entity.

The name is just a name.

                  Harald

---

From: Jari Arkko <[email-masked]>
Date: Sun, 17 Jun 2007 23:38:59 +0300

All,

The ongoing thread has asked some pretty fundamental
questions about how we deal with allocations. Many
opinions have been expressed.

The general discussion is one thing, but I also wanted
to make an offer regarding specific cases where people
feel that the current IANA rules for a specific number space
are obviously wrong, need room for experimentation, etc.
We frequently run into such cases. If you have trouble
with a specific number space, I would be happy to be the
sponsoring AD for a document that fixes that issue. (Or
help you find another AD whose area it belongs, point
you to an existing WG that could handle it, or help you
find a willing author to write the document, whatever
is most suitable for the case at hand.)

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Jun 2007 11:39:29 +0200

On 2007-06-17 14:41, Harald Alvestrand wrote:
> want performed. 

And we did, which is why there is an MoU and an SLA in place between
the IETF and IANA, both of which were open for debate here before
they were concluded.

      Brian

> Others have to perform the same evaluation when

---

From: John C Klensin <[email-masked]>
Date: Tue, 19 Jun 2007 20:22:13 -0400

Thomas,

Sorry for the delay in responding to this.  I think you have
misunderstood my position (although maybe not the position of
others).  See below.

--On Tuesday, 12 June, 2007 12:25 -0700 Thomas Narten
<[email-masked]> wrote:

>> progressed in three years or more -- may suggest either that
>> (i)  if modifying it is the most constructive way forward, we
>> have a  problem or (ii) that it is not an effective way
>> forward, whether  or not it is constructive.
> 
> IMO, completing this document is long overdue. It is a
> tremendous improvement over 2434.

Indeed.

> Some general comments on this thread. I understand the
> argument that some make that we should just give out code
> points in all cases, because otherwise we invite squatting. On
> the other hand, I do believe that withholding code points does
> prevent (in some, but not all cases) use of extensions that
> are potentially problematical. As one concrete example, other
> SDOs are generally hesitant to endorse/use protocols that have
> not been properly granted code points. This has been a
> carrot/stick in the past to get those SDOs to come to the IETF
> with the work rather than just having them "embrace and
> extend" our protocols. Do you think this is not
> useful/necessary or that it can be done in other ways?

I have never advocated "just give out code points in all cases".
I think requirements for good documentation and evidence of
interest that extends significantly beyond the proposers are
quite reasonable.  I agree with the comments in 2434bis about
the problems with unreviewed extensions and code point requests.
I think your SDO case could be dealt with by requirements on the
document and for IETF review of the documentation.  I recognize
that we have gotten ourselves into some situations where there
is code point scarcity and believe that we need to deal with
them with some finesse.    And, while I believe that there are
usually better ways to deal with those cases, I wouldn't lose
any sleep over withholding a code point for an idea that the
IETF community had concluded was likely to be harmful (note
"IETF community...concluded", not just "one reviewer thought it
was a bad, unnecessary, or even redundant idea"... even if that
reviewer is an AD).

Where I think we go astray is when we say "the IETF has to reach
consensus that it _likes_ a particular idea in order to get a
code point".  We also go astray when we use a combination of
procedures to turn a code point registration requirement for
"RFC publication"  into a requirement for enthusiastic IESG
approval.  Interoperability considerations suggest that, if
something is going to actually be out there, the community
benefits by as much knowledge of it as possible.   Holding up a
code point to get good documentation that contributes to that
knowledge is reasonable.  Asking for evidence that the thing
will actually be deployed in ways that might interact with other
uses of the registry is reasonable.  Trying to block deployment
by refusing to allocate a code point is a bad idea because it
won't work and will cause people to ignore our registries.

In the light of this discussion, the problem with 4243bis is
that it is fairly neutral in Section 4.1 wrt the various
statements/ requirements that can be imposed on a registry.  I
now believe that any registry provision that requires someone to
agree to the idea of assigning a codepoint --not just to agree
that, e.g., documentation is adequate such as with the
"Specification required" category-- should require significant
justification in the registry proposal for the additional
restrictions.  I think 4243bis should make that requirement and
that it should contain text that indicates that "RFC Required",
"IETF Review", "Standards Action", and "IESG Approval" are all
exceptional cases that require convincing the community that
interoperability and other important values are well served by
the relevant body being able to deny code point assignment by
failure to act affirmatively. 

Of course, if there are provisions for private or alternate
assignments that can be used by parties who do not achieve
strong levels of approval without constraining the ability of
their protocols to work, those strong levels of approval may
rationally be applied to the the more restricted assignment
cases. 

> Also, if one thinks that code points should just be given out
> in all cases, how do we deal with stuff like RFC 3427? 
> 
> And, does this also mean, for example, that anyone should be
> granted ICMP code points?

I think these are largely red herrings, for the reasons outlined
above.  However, I think it is generally unwise to try to use
control of code point assignments as a means of retaining IETF
control over a protocol.  We need better ways, if only because
taking the code point route encourages code-squatting and
undocumented extensions, neither of which are, in general, in
the best interest of the Internet.  I also believe that we
should, in the future, be very cautious about creating new
protocols or registries that narrowly constrain the code point
space.

> Are you really calling for essentially granting code points to
> anyone who asks? (That is what I hear when the bottom line is
> that the IETF can't say no, because, the reality is (IMO) that
> some only come to the IETF because they have to. They'd just
> as soon do their own thing and don't appreciate having their
> proposals get seriously reviewed.)

Again, I think there is a huge difference between requiring good
documentation and serious review and requiring that the IETF
community (or the IESG, or specific ADs) _like_ a particular
idea.  If there are parties whom one wants to try to force into
serious review, then let's focus on that: require documentation,
require an opportunity for review, require that the parties
respond clearly and openly to review comments.   But, unless
there are very special circumstances, don't refuse to allocate
code points because we don't like an idea.

Put differently,

	* It is reasonable for the IETF to say "no because you
	don't have documentation adequate to determine what this
	code point identifies".
	
	* It is reasonable for the IETF to say "no because you
	have not participated in a review process in good faith"
	
	* It _may_ be reasonable for the IETF to say "no because
	you don't intend the protocol to be used on the public
	Internet and therefore you don't need a code point"
	
	* It is reasonable for the IETF to say "no because there
	is clear evidence, which we are willing to document in a
	public way that your idea, or assignment of a code point
	to it, will be harmful to the Internet if used as
	intended"
	
	* It is not reasonable for the IETF to say "no because
	some of us think your idea stinks" or "no because we
	don't like elements of your business model or your IPR
	entanglements".

With regard to the exception/ override language of 5.3, I think
it is extremely useful, but doesn't have much to do with this
issue as I see it.  Yes, it could be used to fix a code point
for draft-housley-tls-authz-extns if the IESG thought that
appropriate, just as Harald's "one-line document" kludge would.
But the real issue here, as I see it, isn't having a mechanism
for making better exceptions, it is cleaning up our acts about
what we expect and require.

     john