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

Stephan Wenger <stewe@stewe.org> Tue, 05 April 2016 13:28 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 D2FD312D94B for <ietf@ietfa.amsl.com>; Tue, 5 Apr 2016 06:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 iy8oMejUyeTG for <ietf@ietfa.amsl.com>; Tue, 5 Apr 2016 06:28:55 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0141.outbound.protection.outlook.com [207.46.100.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478E312D949 for <ietf@ietf.org>; Tue, 5 Apr 2016 06:28:53 -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.447.15; Tue, 5 Apr 2016 13:28:51 +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.0447.028; Tue, 5 Apr 2016 13:28:51 +0000
From: Stephan Wenger <stewe@stewe.org>
To: Michael Cameron <michael.cameron@ericsson.com>, John C Klensin <john-ietf@jck.com>, Brian E Carpenter <brian.e.carpenter@gmail.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: AQHRhDTbKR9yu1RueEWA9RrAiHSISp9yLyaAgAgVL4CAABEFAIAANCAAgAAS5gCAAKcXAA==
Date: Tue, 5 Apr 2016 13:28:50 +0000
Message-ID: <07C199A9-6072-4ECA-8CFF-D0BF782DAF20@stewe.org>
References: <0000431F-F977-4A24-BA4D-064F740977A0@piuha.net> <56FBF599.9080605@ericsson.com> <F99F459688AAAFCDCD5D9CC1@JcK-HP8200.jck.com> <5702CBA2.2060802@gmail.com> <5ABAE5DB070828F14822B6FD@JcK-HP8200.jck.com> <36BAA6A693139D4BBCB37CCCA660E08A14FC1914@eusaamb101.ericsson.se>
In-Reply-To: <36BAA6A693139D4BBCB37CCCA660E08A14FC1914@eusaamb101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=stewe.org;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:67c:370:176:a1d4:971e:488a:a5e2]
x-ms-office365-filtering-correlation-id: a46acee8-c5b2-4656-d66b-08d35d5639fb
x-microsoft-exchange-diagnostics: 1; BLUPR17MB0273; 5:2IoqDu6W1ugnlwJ+QUE5J5HzJDNEwQ0CfUQa+PTLGzxth9ba02LYTT0NWGhUyOvCp3Erii+bWV3Scl6GVd7t6YrxUqyXjw/DHSf33SXJoCrlymNIe477iKtx+WUx4rP6uyfYgPVGTNyQiWHTTZoXsQ==; 24:bRgVk6RnmejSAY6euLaycpP2saTZxsXffai1m9B4YRsymKr4a0YPBo+anem3P4TyQhv/PcOASlzUOawfYDfPE4XT3lmOLK+JT+VOQfW6FwY=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR17MB0273;
x-microsoft-antispam-prvs: <BLUPR17MB0273B068450F2D4ACC1A4368AE9E0@BLUPR17MB0273.namprd17.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040046)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041046)(6043046); SRVR:BLUPR17MB0273; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0273;
x-forefront-prvs: 0903DD1D85
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(83716003)(1220700001)(1096002)(4326007)(76176999)(54356999)(10400500002)(5008740100001)(6116002)(586003)(102836003)(87936001)(2950100001)(2900100001)(5001770100001)(189998001)(33656002)(50986999)(5004730100002)(77096005)(93886004)(5002640100001)(230783001)(106116001)(36756003)(122556002)(86362001)(99286002)(81166005)(11100500001)(92566002)(2906002)(19580405001)(82746002)(3280700002)(19580395003)(3660700001)(3826002)(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: <8F9EE72A444F284195018E55F93AB615@namprd17.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2016 13:28:50.7310 (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/WO8Kd5cDeDB0C1tdXuZJ5TLerXw>
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: Tue, 05 Apr 2016 13:28:58 -0000

Mike, all,
Referring only to this:





On 4/4/16, 21:30, "ietf on behalf of Michael Cameron" <ietf-bounces@ietf.org on behalf of michael.cameron@ericsson.com> wrote:

>[...]
>Also, because no-one should be expected to predict the outcome of the uncertain patent prosecution process, the phrase "may ultimately Cover that Contribution" should be deleted in Section 5.1.2. 
>
>Thus, I would propose Section 5.1.2 be amended as follows:
>
>If an individual Participates relative to a written Contribution (other than a Contribution that is not intended to be used as an input into the IETF Standards Process) made by another person and such Participant    personally knows of IPR meeting the conditions of Section 5.6 which the Participant believes Covers, or which the Participant personally knows his or her employer or sponsor may assert against Implementing Technologies based on such written Contribution, then such Participant must make a disclosure in accordance with this Section 5.
>[...]

My current feeling is that the removal of the “ultimately covered” phrase would have the opposite effect you apparently desire.  It would lead to more irrelevant disclosures, not less.

The definition of “Cover” is fairly broad, and includes not only "claims of patent and applications (including provisional applications)”, but also “other IPR”, and that IPR, in my interpretation, would also cover provisional applications without claims.  In other words, from the definition of “Cover” alone it is already clear to me that a discloser must take into account applications with all the uncertainty of the prosecution process that entails.  That’s intentional, and hopefully not subject of this discussion.  We definitely want people to disclose applications, as early in their respective process as possible.  

The phrase “ultimately covers” gives some wiggle room to cut down on disclosures of applications that ultimately may not cover the Contribution, but would based on the claims currently on file.  I, at least, have interpreted that phrase in the past (yes, it is present in RFC 3979) such that if I were certain that an overbroad claim--like those routinely filed by European-trained lawyers when filing US provisionals--will not survive prosecution unamended, I would determine my disclosure requirement based on my interpolation of a claim that I think can realistically survive.  I happen to know that at least two IPR departments advised their IETF delegates to act similarly.  Doing so cuts down on the disclosure of applications that are not likely relevant to the Contribution, while still preserving timeliness of disclosures, including disclosures against provisionals.  

This is “running code”, as we call it in the IETF.  Unless I see a very clear, very detailed explanation (including case law if available) why it is bad, I would be very reluctant to support a change.

Stephan