RE: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard
<Pasi.Eronen@nokia.com> Tue, 10 February 2009 13:34 UTC
Return-Path: <Pasi.Eronen@nokia.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ED3C3A6C7B for <ietf@core3.amsl.com>; Tue, 10 Feb 2009 05:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.542
X-Spam-Level:
X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3e2fdlg-uid for <ietf@core3.amsl.com>; Tue, 10 Feb 2009 05:34:37 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 0F7083A6A95 for <ietf@ietf.org>; Tue, 10 Feb 2009 05:34:37 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1ADYCaw016548; Tue, 10 Feb 2009 07:34:37 -0600
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Feb 2009 15:34:09 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Feb 2009 15:34:09 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 10 Feb 2009 14:34:08 +0100
From: Pasi.Eronen@nokia.com
To: simon@josefsson.org, brian.e.carpenter@gmail.com
Date: Tue, 10 Feb 2009 14:34:09 +0100
Subject: RE: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard
Thread-Topic: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard
Thread-Index: AcmLfW0Fc0TL/gKsTtq9Sqy3jDRWkwAATkIA
Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E79A68F8@NOK-EUMSG-01.mgdnok.nokia.com>
References: <498F9419.80300@ieee.org> <4990DD75.3090206@gmail.com> <87wsbytqa2.fsf@mocca.josefsson.org>
In-Reply-To: <87wsbytqa2.fsf@mocca.josefsson.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 10 Feb 2009 13:34:09.0212 (UTC) FILETIME=[409377C0:01C98B84]
X-Nokia-AV: Clean
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2009 13:34:38 -0000
Simon Josefsson wrote: > I disagree. The IETF policies around patents mention "use" as well > as "implementation". Thus, a license that permit "implementation" > but not permitting "use" should generate similar scrutiny and > discussion. It poses the same problem for actual users. > > I strongly disagree with a notion that just because someone grants a > patent license for "implementation" that the IETF community has to > consider the patent situation around the technology as irrelevant. > Use of technology goes beyond "implementation". This is > acknowledged in the IETF policy documents. Compare, e.g., RFC 3979 > and in particular the definition of the term "Covers". > > I also disagree with the claim that the draft is unencumbered. I > don't follow how you reach that conclusion from the patent > disclaimer. You quoted only one paragraph out of several, and the > other paragraphs are the ones that encumber use of the protocol. It > may be your interpretation that the draft is unencumbered, but > everyone get the same opportunity to make their own interpretation. > As implementer of the technology, and having consulted with legal > aid, I have made another interpretation. <speaking as an individual, not wearing any hats> Well, it's good to remember that there are *lots* of patents about larger systems that include IETF protocols (e.g., TLS, HTTP, MPLS, Mobile IP, or RADIUS) as components. What's claimed to be novel (and covered by the patent) is not the IETF protocol as such, but the combination: using the protocol(s) in certain environment in particular way to solve something. And of course there are lots of implementation technique patents where what's claimed to be novel (and covered by the patent) is some particular way of implementing the protocols (e.g. better performance than "obvious" implementations). Usually these types of patents are *not* disclosed to the IETF, since the protocol as such is not covered by the patent. In fact, my guess would be that we probably don't have *any* IETF protocols where someone has not patented using protocol A in bigger system B in way C to solve D (where B+C+D is something that the RFC did not describe, so it could be non-obvious and novel). If we required that IETF protocols must not have any such "field of use restrictions" (where using the protocol in certain way could be encumbered), we would not publish any protocols at all. My reading of RedPhone's IPR disclosure 1026 is that they claim to have a patent application about a larger system that includes tls-authz as one part, and uses it in particular way. If you want to build a system matching the numbered list 1..4 in the disclosure (RedPhone's description of what they claim is covered), then you would have to consider this IPR disclosure. However, I think there are many more good uses for tls-authz that do *not* match items 1..4. Just because someone has filed a patent application on some rather obscure combination of B+C+D should not prevent others from using the protocol for things not covered by that application. Thus, I support publishing this as an RFC (either Informational or Standards Track). (BTW, I think it's pretty clear that RedPhone didn't get the process right here. Some have claimed they did this knowingly with malicious intent, others have attributed it more to carelessness and ignorance -- I would say we can't really know without doing a Vulcan mind meld :-) Either way, I think we should consider the draft's technical merits and IPR situation *now*, and not put too much weight on the history.) Best regards, Pasi
- Evaluation: draft-housley-tls-authz-extns-07.txt … Dimitrios P. Bouras
- FWIW: draft-housley-tls-authz-extns-07.txt to Pro… Brian E Carpenter
- Re: FWIW: draft-housley-tls-authz-extns-07.txt to… Tim Bray
- Re: FWIW: draft-housley-tls-authz-extns-07.txt to… Marshall Eubanks
- RE: FWIW: draft-housley-tls-authz-extns-07.txt to… Powers Chuck-RXCP20
- Re: FWIW: draft-housley-tls-authz-extns-07.txt to… Simon Josefsson
- RE: FWIW: draft-housley-tls-authz-extns-07.txt to… Pasi.Eronen
- Re: FWIW: draft-housley-tls-authz-extns-07.txt to… Thierry Moreau
- Re: FWIW: draft-housley-tls-authz-extns-07.txt to… Simon Josefsson
- Re: FWIW: draft-housley-tls-authz-extns-07.txt to… Thierry Moreau
- Re: ideological opposition to patents Ofer Inbar
- Re: FWIW: draft-housley-tls-authz-extns-07.txt to… Brian E Carpenter
- Re: FWIW: guessing about draft-housley-tls-authz-… John Levine
- RE: FWIW: draft-housley-tls-authz-extns-07.txt to… Pasi.Eronen