Tim Polk wrote: > As stated in the Last Call announcement, I had intended to request > IESG evaluation for publication on the standards track. It is clear > that the community does not support publication of this document on > the standards track. However, the Last Call comments show rough > consensus for publication as an Experimental RFC. I do not understand why an "Experimental RFC" is different in principle from a "standards track RFC" when it comes to patents, since even experimental use of patented technology is an infringement. However,... As a compromise and as an IETF experiment for this one TLS proposal, I suggest that we try to apply the procedure described in the W3C Patent Policy, section 7, "Exception Handling", as adapted to conform to the IETF mode of operation. [See http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exception] Specifically that would mean: 1. IETF forms a PAG (or IETF WG equivalent) of volunteers to analyze the patent disclosure and the proposed technology, and to determine what licenses are necessary and available for full implementation anywhere in the world. 2. The PAG recommends whether, and on what licensing terms, to secure necessary technology for the proposed RFC. 3. Meanwhile, the WG continues its work. Nothing would preclude later decisions, in accordance with normal IETF consensus procedures, to adopt or not adopt a patent-encumbered standard. [See in particular section 7.5 of the W3C Patent Policy.] /Larry Rosen Lawrence Rosen Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243 Skype: LawrenceRosen > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > Tim Polk > Sent: Friday, March 06, 2009 11:26 AM > To: ietf@xxxxxxxx > Subject: Consensus Call for draft-housley-tls-authz > > Folks, > > After some time reflecting on the hundreds of messages submitted to > the IETF discussion list, I have come to several conclusions about > progressing draft-housley-tls-authz. I will summarize the conclusions > up front, then provide the rationale for those decisions in the > remainder of this message. > > 1. Last Call demonstrates that the community does not support > progression of this document on the standards track, but sufficient > support exists for publication as an Experimental RFC. > > 2. The community would like the TLS working group to develop a > standards track mechanism for TLS authorization, and strongly prefers > an unencumbered solution. > > 3. Publication of draft-housley-tls-authz should be timed to > ensure that it does not unduly interfere with acceptance and adoption > of a standards track solution. > > As stated in the Last Call announcement, I had intended to request > IESG evaluation for publication on the standards track. It is clear > that the community does not support publication of this document on > the standards track. However, the Last Call comments show rough > consensus for publication as an Experimental RFC. > > If one simply counts the messages sent to the IETF discussion list, > the conclusion would be that the document should not be published. > However, I did not weight all comments equally. In particular, I > discounted the large volume of messages from the Free Software > Foundation. To be clear, these messages were not ignored - they > represent a viewpoint shared by a significant number of IETF > participants, and the IETF has a clear preference for unencumbered > solutions. > However, many of the messages from the FSF campaign stated that it is > the IETF's mission to develop unencumbered standards to satisfy the > FSF. That is not for the FSF to decide, and is not consistent with > the IETF's traditional stance on IPR. For example: > > > We depend on organizations like the Internet Engineering Task Force > > (IETF) and the Internet Engineering Steering Group (IESG) to > > evaluate new proposals for standards and make sure that they are not > > encumbered by patents or any other sort of restriction that would > > prevent free software users and programmers from participating in > > the world they define. > > > > This position does not align with IETF IPR policy. It is therefore > inappropriate to impose the FSF's requirements on this or any other > IETF specification. > > It is very clear that the community would prefer a standards track > publication generated through the TLS working group process, assuming > sufficient interest exists to support the work. If the TLS working > group chooses to take on this work, this specification should not be > published until the standards track solution is published. This > ensures that publication of draft-housley-tls-authz does not unduly > interfere with acceptance and adoption of a standards track solution. > > If publication of draft-housley-tls-authz is approved by the IESG but > delayed in deference to working group activities, I intend to request > early IANA assignment. This will permit experimental use of this > publication while the standards track publication is under development. > > Thanks, > > Tim Polk > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf