Re: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard

Simon Josefsson <simon@josefsson.org> Tue, 10 February 2009 12:44 UTC

Return-Path: <simon@josefsson.org>
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 AD49028C1A1 for <ietf@core3.amsl.com>; Tue, 10 Feb 2009 04:44:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level:
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599]
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 DiNceKIWp5XK for <ietf@core3.amsl.com>; Tue, 10 Feb 2009 04:44:45 -0800 (PST)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id B5E7F28C194 for <ietf@ietf.org>; Tue, 10 Feb 2009 04:44:45 -0800 (PST)
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <simon@josefsson.org>) id 1LWryj-0000ON-D3; Tue, 10 Feb 2009 13:44:42 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard
References: <498F9419.80300@ieee.org> <4990DD75.3090206@gmail.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090210:brian.e.carpenter@gmail.com::KDYCgZY+dzi1j6EY:0iYB
X-Hashcash: 1:22:090210:ietf@ietf.org::0HkzVB9nCbTVqmL4:K2RZ
Date: Tue, 10 Feb 2009 13:44:37 +0100
In-Reply-To: <4990DD75.3090206@gmail.com> (Brian E. Carpenter's message of "Tue, 10 Feb 2009 14:50:45 +1300")
Message-ID: <87wsbytqa2.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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 12:44:46 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> writes:

> FWIW (and it would be good if other actual
> IETF participants care to indicate +1 if they agree):
>
> The actual words in RedPhone's current disclosure:
>
> "RedPhone Security hereby asserts that the techniques for
> sending and receiving authorizations defined in TLS Authorizations
> Extensions (version draft-housley-tls-authz-extns-07.txt) do not
> infringe upon RedPhone Security's intellectual property rights (IPR)..."
>
> Now, there's been some discussion of whether some use cases for
> the protocol will nevertheless lead implementors to infringe, but
> that (plus the question of whether the offered license conditions
> in that case are in fact acceptable) is frankly irrelevant. The
> draft on the table is in itself unencumbered by RedPhone Security,
> and that's all that matters as far as the IETF's IPR rules go.
>
> There may be other reasons not to advance this document; not being
> a security person, I have no opinion about that. But as far as this
> particular IPR issue is concerned, IMHO it's good to go.

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.

/Simon