Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")

Stephan Wenger <stewe@stewe.org> Mon, 25 April 2016 21:32 UTC

Return-Path: <stewe@stewe.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDAF12D0B0 for <ietf@ietfa.amsl.com>; Mon, 25 Apr 2016 14:32:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waQ9Au-KThWS for <ietf@ietfa.amsl.com>; Mon, 25 Apr 2016 14:32:01 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE3C12D149 for <ietf@ietf.org>; Mon, 25 Apr 2016 14:32:01 -0700 (PDT)
Received: from BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) by BLUPR17MB0273.namprd17.prod.outlook.com (10.162.235.144) with Microsoft SMTP Server (TLS) id 15.1.477.8; Mon, 25 Apr 2016 21:31:42 +0000
Received: from BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) by BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) with mapi id 15.01.0477.012; Mon, 25 Apr 2016 21:31:42 +0000
From: Stephan Wenger <stewe@stewe.org>
To: Jari Arkko <jari.arkko@piuha.net>, Pete Resnick <presnick@qti.qualcomm.com>
Subject: Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")
Thread-Topic: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")
Thread-Index: AQHRhDTbKR9yu1RueEWA9RrAiHSISp+FI5mAgBYyZID//5/2gA==
Date: Mon, 25 Apr 2016 21:31:42 +0000
Message-ID: <EC4CBF0D-1B7C-4FB5-85EA-E622B24E9B9A@stewe.org>
References: <0000431F-F977-4A24-BA4D-064F740977A0@piuha.net> <E7E31E22-1C86-40C4-BC5B-F65132015EF5@qti.qualcomm.com> <6CA3C554-0FF6-4779-80B9-C75698FB61C1@piuha.net>
In-Reply-To: <6CA3C554-0FF6-4779-80B9-C75698FB61C1@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: piuha.net; dkim=none (message not signed) header.d=none;piuha.net; dmarc=none action=none header.from=stewe.org;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.174.30.183]
x-ms-office365-filtering-correlation-id: f25eb691-dbb0-47d1-ebef-08d36d50fec2
x-microsoft-exchange-diagnostics: 1; BLUPR17MB0273; 5:hDa7O3G2g8Ybzrup2Sjz7m+vtKEPBsAK9tWcxKd/KPEcgjB/vf+sB7UQvol1d6cY9CwV+ezFUpWjd+JRrrj60u+4wbgC/fJ4v7R+pPdDw5xVyiTQdyvG572z7Oh88eak0r9YiG/u84yH4nBPrr4hFA==; 24:r2AAFNtzPgCL1IFyNYUUiZU+XCkuUY3PiRIey5lhdlrhWb3FkezeJmfWVLxL2rP4AO6qxbj/KE+sPK0iPQFNX0FVIFHowGkpGh191cd6wtA=; 7:m5sppoAqwXzwkmnIloIe+birerCo8spcuJIOrkurQG77o1s+yHIeQDeMC330PXxFFPk8qNQh+iluTzBZlumEf9ZRuOk2Ab5DSQ8BwnW6Mhv4Dvu7lqmo5SuYQE0uEE/ZZwKxMh67PWGNDaTqEgXPXHc3Aw1byNYuubdDrFyntgUD+b8RICM8dJfmvd7poGhv
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR17MB0273;
x-microsoft-antispam-prvs: <BLUPR17MB027354C25F9CF5B6A7848C8CAE620@BLUPR17MB0273.namprd17.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046); SRVR:BLUPR17MB0273; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0273;
x-forefront-prvs: 0923977CCA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(1220700001)(1096002)(4326007)(82746002)(5002640100001)(19580405001)(33656002)(19580395003)(36756003)(92566002)(76176999)(3280700002)(3660700001)(2906002)(54356999)(50986999)(3846002)(586003)(6116002)(102836003)(122556002)(5008740100001)(83716003)(86362001)(87936001)(99286002)(11100500001)(189998001)(106116001)(5004730100002)(10400500002)(230783001)(5001770100001)(2950100001)(66066001)(2900100001)(77096005)(81166005)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR17MB0273; H:BLUPR17MB0275.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <1A63854213E6B648AF61BC6908D0C271@namprd17.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2016 21:31:42.4463 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0273
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/nOndVfUo6ORpFi42kT38HQYMW8Y>
Cc: IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Mon, 25 Apr 2016 21:32:03 -0000

Hi,
Please see inline.  Everything I agree with (reluctantly or wholeheartedly) is deleted.
Thanks,
Stephan





On 4/25/16, 13:15, "ietf on behalf of Jari Arkko" <ietf-bounces@ietf.org on behalf of jari.arkko@piuha.net> wrote:

>
>> - Section 5.5(C): Two things:
>> 

[...]

>> OLD
>>      must ensure that such
>>      commitments are binding on any subsequent transferee of the
>>      relevant IPR.
>> NEW
>>      must ensure that such commitments are binding on a transferee of
>>      the relevant IPR, and that such transferee will use reasonable
>>      efforts to ensure that such commitments are binding on a
>>      subsequent transferee of the relevant IPR, and so on.
>> END
>> 
>> The object of the "subsequent" wasn't clear, so this just spells it out. Wordy, but more precise.
>
>Right

I’m not sure I agree that the object of “subsequent wasn’t clear from context.  However, I don’t mind to see that fixed if others feel so.  However, the fix as proposed sets a very low standard (reasonable efforts) for ensuring that subsequent transferees are bound. That a substantial change from the WG consensus, and IMO in the wrong direction.

What we want to achieve is that if A assigns a patent to B, B and all further transferees (B to C, C to D, etc. etc.) are similarly bound.  We want to make sure if any of these entities doesn’t feel bound for whatever reason, the patent is held unenforcible by a well-informed court.  It’s clear that this is much more onerous to the rightholder, and may well lower the value of the IPR. 

I would be fine if the NEW part would be reworded as follows:
NEW
      must ensure that such commitments are binding on a transferee of
      the relevant IPR, and also binding on any subsequent transferees 
of the relevant IPR.
END





>
>> - Section 7, paragraph 6:
>> 
>> The only change in this paragraph from 3979 was to add the word "all" in the second-to-last sentence. My lawyer friends tell me that this little change is opening a can of worms, having to do with licensing to makers of parts instead of implementers of the whole specification. I don't think we meant to change the meaning from the 3979 meaning, and I certainly don't think that we meant to change some implication about whether folks in general needed to license to people that make parts where they wouldn't have before. Was there something unclear about that sentence that needed the word "all" added to it? We aren't making a substantive change, are we? Can we just strike it? It seemed pretty clear to me before.
>
>Agree

I’m not sure here.
For context, the paragraph is in section 7 of RFC3979bis (which used to be the second paragraph of section 8 of RFC3979).  The sentence in question describes an purported IETF consensus established in pre-RFC3979 times, as follows (the critical and new “ALL” is capitalized):

“
An IETF consensus has developed that no mandatory-to-implement security technology can be specified in an IETF specification unless it has no known IPR claims against it or a royalty-free license is available to ALL implementers of the specification unless there is a very good reason to do so. 

“

I agree that the tightened language removes an arguably unclear loophole that has been present in RFC3979, and which Pete’s lawyer-friends probably would like to preserve.  However, generally speaking, removing loopholes like this is a Good Thing, unless the consensus at the time was such that there ought to be a loophole.  I did not follow the consensus process in sufficient detail to have an opinion, but perhaps security and IPR conscious folks in the IETF remember?