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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:harald@xxxxxxxxxxxxx] 
Sent: Wednesday, June 13, 2007 4:54 PM
To: Russ Housley; John C Klensin; ietf@xxxxxxxx
Cc: mark.brown@xxxxxxxxxxxxxxxxxxxx; iesg@xxxxxxxx
Subject: Re: Withdrawing sponsorship of draft-housley-tls-authz-extns

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 think of it....


--On 12. juni 2007 16:50 -0400 Russ Housley <housley@xxxxxxxxxxxx>
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.
>
> 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:
>
>
>> --On Tuesday, June 12, 2007 07:11 -0700 Dave Crocker
>> <dhc2@xxxxxxxxxxxx> 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
>>
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@xxxxxxxx
>> https://www1.ietf.org/mailman/listinfo/ietf
>>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf
>





_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]