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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Tim Polk
Sent: Friday, March 06, 2009 11:26 AM
To: ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf