Re: [IPsec] IPR disclosure for ESP SPI issue

Christian Hopps <chopps@chopps.org> Fri, 06 January 2023 05:44 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E83C151539 for <ipsec@ietfa.amsl.com>; Thu, 5 Jan 2023 21:44:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrJelK1oVbHx for <ipsec@ietfa.amsl.com>; Thu, 5 Jan 2023 21:44:49 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 51525C151535 for <ipsec@ietf.org>; Thu, 5 Jan 2023 21:44:49 -0800 (PST)
Received: from ja.int.chopps.org.chopps.org (172-222-091-149.res.spectrum.com [172.222.91.149]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id C0AA27D02D; Fri, 6 Jan 2023 05:44:48 +0000 (UTC)
References: <598687d8-3483-ddef-c17b-2700959211df@nohats.ca>
User-agent: mu4e 1.8.13; emacs 28.2
From: Christian Hopps <chopps@chopps.org>
To: Paul Wouters <paul@nohats.ca>
Cc: ipsec@ietf.org
Date: Fri, 06 Jan 2023 00:34:23 -0500
In-reply-to: <598687d8-3483-ddef-c17b-2700959211df@nohats.ca>
Message-ID: <m28rigi5db.fsf@ja.int.chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Cq2wCf1x3Pr87qjOxVMaj2BVlT8>
Subject: Re: [IPsec] IPR disclosure for ESP SPI issue
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jan 2023 05:44:53 -0000

Do they say what "reasonable and non-discriminatory terms and conditions" are?

here's an example of what Cisco has typically used for IETF standards:

  "The reasonable non-discriminatory terms are:

   If this standard is adopted, Cisco will not assert any patents owned or controlled by Cisco against any party for making, using, selling, importing or offering for sale a product that implements the standard, provided, however that Cisco retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a patent it owns or controls (either directly or indirectly) against Cisco or any of Cisco's affiliates or successors in title or against any products of Cisco or any products of any of Cisco's affiliates either alone or in combination with other products; and Cisco retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard.

   Royalty-bearing licenses will be available to anyone who prefers that option."

here's an example of what Juniper has used (they are identical except for the company name :)

   "The reasonable non-discriminatory terms are:

    If this standard is adopted, Juniper will not assert any patents owned or controlled by Juniper against any party for making, using, selling, importing or offering for sale a product that implements the standard, provided, however that Juniper retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a patent it owns or controls (either directly or indirectly) against Juniper or any of Juniper's affiliates or successors in title or against any products of Juniper or any products of any of Juniper's affiliates either alone or in combination with other products; and Juniper retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard.

   Royalty-bearing licenses will be available to anyone who prefers that option."

Examples of this same text can also be found from other companies as well...

Thanks,
Chris.

Paul Wouters <paul@nohats.ca> writes:

> A note on the ESP SPI overloading trick, such as used in
> draft-ponchon-ipsecme-anti-replay-subspaces for which SSH
> has IPR, they submitted an IPR statement:
>
>
> See https://datatracker.ietf.org/ipr/5880/
>
> 	In the event that any claims of the Subject Patents are necessarily
> 	infringed by such future version of IPSec (“Essential Claims”), SSH
> 	agrees, upon written request from a party, to negotiate with that party
> 	a non-sublicenseable license to the Essential Claims under reasonable
> 	and non-discriminatory terms and conditions, taking into consideration
> 	the other technologies implemented in the same product, solely to the
> 	extent necessary to implement required portions of the Future IPSec RFCs,
> 	provided that the party grants a reciprocal license to SSH and provided
> 	that the license terminates if the party initiates a claim of patent
> 	infringement, directly or indirectly, against SSH, its subsidiaries,
> 	or its affiliates.
>
> Paul
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec