ietf
[Top] [All Lists]

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

2007-06-15 07:36:18
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(_at_)alvestrand(_dot_)no] 
Sent: Wednesday, June 13, 2007 4:54 PM
To: Russ Housley; John C Klensin; ietf(_at_)ietf(_dot_)org
Cc: mark(_dot_)brown(_at_)redphonesecurity(_dot_)com; iesg(_at_)ietf(_dot_)org
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(_at_)vigilsec(_dot_)com>
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(_at_)dcrocker(_dot_)net> 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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf






_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf