Re: [tsvwg] Summary: IPR Declarations on draft-ietf-tsvwg-aqm-dualq-coupled

"De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com> Tue, 09 July 2019 14:40 UTC

Return-Path: <koen.de_schepper@nokia-bell-labs.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B136B12046B for <tsvwg@ietfa.amsl.com>; Tue, 9 Jul 2019 07:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 4WflxdCtWAKS for <tsvwg@ietfa.amsl.com>; Tue, 9 Jul 2019 07:40:40 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70105.outbound.protection.outlook.com [40.107.7.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F89120438 for <tsvwg@ietf.org>; Tue, 9 Jul 2019 07:40:37 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gZBN92SFuIrSan+UNY1XZTBYU3GdTMjVDe4qTtJay56nYAd8jBF/ejMa8+z22sPPB8XJGp79OlPe8hur4lG6J/RiwPp48SjogP0O+y2iDmsY0iVKlG1cAFNMj4SlwmxGd9n5Xc+/rF2uUmbsGGfkwq9RqIuZjcdGDIcNSr1zdt6++XF/YXzLKRAh6D3miFkYQ1mdrs4CTkh8e8ViwJQqNLhiO7t+p1cQ8pGGV4HGRGV9ID0UfvmMkp4nbdfTRLNO3Nq5mxon9Ik+j0k1BQKjZN+LnMu5FdnqqRVvHRbExkH7z/0aeZ7dZKBgt3DIUj3FbpooZhj5zcE8rMjOedgbQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MINUA/PicWPhmQ+ZPWdZU3cr1G2teSssMN+fynLdJY4=; b=Osom7T+SKPHZPA517srn3nc6BIpCDMqNXxzdjBax4om2j9ZDv53gbNR1gJLfFzJnmrqZs0JKM6GBN1I+EAlF1r8tdBYXh4L8SzMwJA2hyWKPpOHkH7wUwavr4V8mmW/JP3AFGBbJ0c+ZeVSArxfnDHCHCed2NzdDZnn2WK5T5jfNx8ps8f+L4q3mkSVm75f7wdDogyofK3V30mjHnT4jGoEvS3faEY/fCgrMqfgfHaJO7GPBV7C6z61XDrMyaVwGiKOKG0oWzxKBM70w7GWe8V/VBEMlvImKK3m3MrJZNEE8fSFWGD99EL1jMVscsvLROLRx4XWrCtIp9kNkdfVQIQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=nokia-bell-labs.com;dmarc=pass action=none header.from=nokia-bell-labs.com;dkim=pass header.d=nokia-bell-labs.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MINUA/PicWPhmQ+ZPWdZU3cr1G2teSssMN+fynLdJY4=; b=ppmqXCAyugP5iJSWkDv2y380XfycqeTSX5Y07F93Q+tYqC8/lybCOkdR2QMY8cqmHOp3TT9AKnmrFWJFypSGi8oR2y3k2B9IJvUiyqosHhvB7uzi+UlZSggb73i7zFJJYVy+1OsiibE+fxMF4zeKfZjJYOPeD94vDmktnce9ri4=
Received: from AM4PR07MB3459.eurprd07.prod.outlook.com (10.171.191.155) by AM4PR07MB3171.eurprd07.prod.outlook.com (10.171.188.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.5; Tue, 9 Jul 2019 14:40:34 +0000
Received: from AM4PR07MB3459.eurprd07.prod.outlook.com ([fe80::e589:2ef4:599e:6290]) by AM4PR07MB3459.eurprd07.prod.outlook.com ([fe80::e589:2ef4:599e:6290%7]) with mapi id 15.20.2073.008; Tue, 9 Jul 2019 14:40:34 +0000
From: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>
To: Toke Høiland-Jørgensen <toke@redhat.com>, "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Summary: IPR Declarations on draft-ietf-tsvwg-aqm-dualq-coupled
Thread-Index: AdUtxul2LZjPDHRsSHaIVtGmvqAo9wEmjmsAAQBxfyA=
Date: Tue, 09 Jul 2019 14:40:34 +0000
Message-ID: <AM4PR07MB3459A43CF29C83976CE51E16B9F10@AM4PR07MB3459.eurprd07.prod.outlook.com>
References: <CE03DB3D7B45C245BCA0D24327794936305EA1E0@MX307CL04.corp.emc.com> <87pnmq2eah.fsf@toke.dk>
In-Reply-To: <87pnmq2eah.fsf@toke.dk>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=koen.de_schepper@nokia-bell-labs.com;
x-originating-ip: [2a02:1810:1e00:cb00:80d6:c32c:9227:6149]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8744b1b8-54ad-4631-3210-08d7047b66d2
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM4PR07MB3171;
x-ms-traffictypediagnostic: AM4PR07MB3171:
x-ms-exchange-purlcount: 9
x-microsoft-antispam-prvs: <AM4PR07MB3171F2DF1E779D32AA779EE1B9F10@AM4PR07MB3171.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0093C80C01
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(39860400002)(376002)(366004)(136003)(346002)(13464003)(199004)(189003)(21473003)(66476007)(46003)(25786009)(66556008)(5660300002)(86362001)(66574012)(476003)(14444005)(66446008)(64756008)(66946007)(81166006)(14454004)(73956011)(229853002)(6116002)(8936002)(81156014)(76116006)(52536014)(2906002)(305945005)(6436002)(8676002)(102836004)(71190400001)(7736002)(6306002)(68736007)(7696005)(446003)(110136005)(316002)(966005)(55016002)(6506007)(76176011)(99286004)(11346002)(2501003)(33656002)(478600001)(486006)(9686003)(186003)(53936002)(71200400001)(53546011)(256004)(74316002)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3171; H:AM4PR07MB3459.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 9X6IGU9KhKYrJeI5EGaJ950aXeluwWwIx/XuXKzXcYpsUyuIEJsPtQogAPE1AYj7ceLy0APvsdpjLouur62H3GimwOFrUr++1Fyi8+Cx5IdePLLw3S3usbFseCzJ9NotGvHteh1yrU/h3C0pFr1H3QBy5Aq4iSyPJCm0D0IxkzrxO28HD/Wb5HBVsCFyD9XeyjnUE7P+uAfzbql01BlhJABRDGfUX80rZF7MbQs53UWw8rEsEZybvnEocLl6/St1a+UzZVGxwGfYo2BgB1KSs4lxDL//7Yg99Ajc/twY8+umvisLp2tEQmgS1M+rrZn1+g+DhDSsTJzxwd+fEtn3l4jFzYIaFODgZAbo8EuD7noXRChDPgu3fw122RGSwtqVA/ioc6PMxP2Z4TPOlj2Lpi8ocKwWkdlDCwX8CHLqB/M=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8744b1b8-54ad-4631-3210-08d7047b66d2
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 14:40:34.7825 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: koen.de_schepper@nokia-bell-labs.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3171
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/aDFXbBO-AHkZF14c9wFMiy4vUFo>
Subject: Re: [tsvwg] Summary: IPR Declarations on draft-ietf-tsvwg-aqm-dualq-coupled
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2019 14:40:45 -0000

Hi David, Toke,

Sorry for the delay in my response, but our legal counsel was out of the office last week.
Thanks David for your summary, and Toke for expressing your particular concerns.  

While the scenario outlined by Toke below is unlikely and we are not aware of any such situation ever occurring, it is an understandable concern. However, if this concern is believed in this group to be of such merit as to lead to a decision to avoid technology with these type of declarations, then it raises much wider implications for IETF and this group's work.

When we made our non-assert commitments we were careful to follow the practice of other companies making similar such commitments.  These also included defensive suspension language, as noted by David.  In the case of this group's work, I would point to the following example: https://datatracker.ietf.org/ipr/2540/

To be clear, and to respond to Toke's specific request, Alcatel Lucent (now part of Nokia) in providing its non-assert IPR commitments (#3561 and #3562) did not withdraw its former RAND IPR commitments (#2679 and #2952).  Accordingly, both remain in effect. For the reasons expressed by Toke, we hope that this will help alleviate the concerns expressed.  

I would also note that Alcatel-Lucent released the DualPI2 code under GPLv2, see: https://github.com/olgabo/dualpi2/blob/master/sch_pi2/sch_pi2.c and more recently: https://github.com/olgaalb/sch_dualpi2/blob/master/sch_dualpi2.c. Nokia is pushing this code into the Linux kernel, similar as for the above example (https://datatracker.ietf.org/ipr/2540/) which is also already part of the Linux kernel.

Finally, on a personal level, I would like to add that it took me (and others) quite some time and effort to push internally, to make these non-assert commitments.  It is Nokia's, and formerly Alcatel-Lucent's, usual practice only to provide RAND commitments - irrespective of whether it ever intends to seek royalties for its patented technology.  I do not expect it will be possible for me to cause any further changes to our commitments.

Koen.



-----Original Message-----
From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Toke Høiland-Jørgensen
Sent: Thursday, July 4, 2019 2:08 PM
To: Black, David <David.Black@dell.com>; tsvwg@ietf.org
Subject: Re: [tsvwg] Summary: IPR Declarations on draft-ietf-tsvwg-aqm-dualq-coupled

"Black, David" <David.Black@dell.com> writes:

> As promised, this note summarizes the off-list discussions on this topic.
>
> The following summary is sent in my role as WG Chair, and is intended as guidance to the Working Group (WG):
>
>
>   1.  Background:
>
>   *   Section 7 of RFC 8179 and all of RFC 3669 are important background to this discussion of intellectual property concerns  - reading both of them before responding to this note is RECOMMENDED.
>   *   The two IPR Disclosures involved are 3561 and 3562 (https://datatracker.ietf.org/ipr/3561/ and https://datatracker.ietf.org/ipr/3562/).
>
>
>
>   1.  IPR Disclosures and IETF Technology Evaluation in general:
>
>   *   The IETF and the IESG in particular disclaim responsibility for evaluating IPR Disclosures.  WG participants are expected to reach their own conclusions, consulting their own legal counsel if/as appropriate.
>   *   IPR Disclosures, including license terms, are inputs to WG evaluation of technology.  WG evaluation of technology is expected to be broad, considering all factors, and not tightly focused on license terms or IPR Disclosures.
>   *   An important factor for the WG to consider is applicability of the patent to the technology of interest to the WG - see Section 5.5 of RFC 3669.   That factor is left for the WG to discuss further as part of WG evaluation of technology.
>   *   The WG mailing list is an important forum for WG activity, hence discussion of license terms on the mailing list as part of WG evaluation of technology is acceptable.
>
>
>
>   1.  The IPR Disclosures on the aqm-dualq-coupled draft and the concern that led to the off-list discussion:
>
>   *   The license terms involved in the original concern are called "Defensive Suspension" or "Defensive Termination" - e.g., see https://en.wikipedia..org/wiki/Defensive_termination.
>   *   The original concern involves the broad scope of the "Defensive Suspension" terms in the IPR Disclosures, specifically that Defensive Suspension is triggered by assertion of any patent(s) whatsoever against the patent holder.
>   *   Perusal of recent IPR disclosures to the IETF (see https://datatracker.ietf.org/ipr/#specific) indicates that similar Defensive Suspension terms are common.
>   *   The WG remains free to evaluate the degree of acceptability (or lack thereof) of these Defensive Suspension terms to this specific WG for this specific technology as part of overall WG evaluation of technology.
>
> A number of additional topics were raised in the off-list discussion but no conclusions were drawn.   Participants in that discussion may (and are likely to) bring those topics to the list for further discussion.

Yes, thank you for the summary David. To expand on my concerns re: the termination clause:

Termination provisions in licenses vary in a number of ways, including the breadth of and the types of actions that can trigger termination, and the scope of what is terminated. Termination provisions are often found in royalty-free patent licenses, including some open source licenses (one widely used example:
https://www.apache.org/licenses/LICENSE-2.0), as well as in standards-related licenses and commitments.

Standards activities with patent rules that specifically seek to foster royalty-free solutions typically describe or outline a required or acceptable royalty-free commitment or license. These generally include a termination provision where the trigger is limited action against the standard. This avoids the possible use of a patent that is required in order to implement the standard from being used as leverage in ways unrelated to the standard, while permitting the termination to operate in the interest of the standard (tending to discouraging patent action against the standard).

These are two examples of such royalty-free patent policies; each permits termination, with differing, but limited, triggers (same standard, or any standard from the org, respectively):
https://www.oasis-open.org/policies-guidelines/ipr#licensing_req
https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements

As David pointed out, the IETF doesn't have such a patent policy, but instead leaves IPR issues to be a matter of consideration, rather than requirement, as is discussed in RFC 3669. Thus, please consider this message as material for such consideration.

As I have earlier pointed out, the feature of IPR statement 3561 that I have concerns about is that, even though the fee is zero, its termination provision could still allow the patent to be used to leverage the weight of the standard, not just the patented invention.

As termination provisions differ in their details, let me offer an example of a scenario that illustrates the leverage potential that I see with this particular termination provision. This scenario would play out by the following sequence of events:

1. Holder of a patent on the standard says: the patent is licensed for
   free; but, if you assert any patent against me, your license
   terminates and, if the patent does apply to the standard, you may no
   longer implement the standard.

2. Holder also has other patents and it uses these to engage in various
   licensing activities.

3. Holder seeks license fees from Target. Target, which holds patents
   for defensive purposes, says: I have patents, too; I wasn't going to
   charge you anything, but, since you are demanding money from me,
   let's talk.

4. Holder is unhappy with the resulting talk and sues Target.

5. As a defensive matter, Target considers counter-suing Holder. But,
   now, Target must consider the cost of being required to stop shipping
   anything that implements the standard.

6. The result is that, even though the license price is zero, Holder
   remains able to leverage the value of being able to implement the
   standard, not just the value of whatever invention the patent was
   granted for.

>From an off-list message thread, I came to understand that Nokia views
the earlier RAND statement as not being replaced by the royalty-free statement, but that both remain in effect. If this is the case, then this would reduce the leverage provided by the broadly-triggered termination provision, because one would not be excluded from implementing the standard. With the continued availability of a RAND license, while the RF license can go away and Holder is able to charge a fee for practising the standard (in theory, the value of the patented invention should be factored into the ultimate settlement), this is better than being able to shut someone out from the standard. Thus, the concern would be reduced.

I am expecting a statement to be made on this list concerning that particular off-list point.


Finally, I'll add that while the scenario above is generic, I am mostly concerned about ensuring any standard be palatable to upstream open source projects. This has different implications depending on the project, of course, and this email is already long enough that I won't go into more detail about that now. Just wanted to include this point to help make everyone understand where I'm coming from.

-Toke