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