Re: Handling IPR disclosures through draft reorganizations

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 23 July 2023 23:52 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipr-wg@ietfa.amsl.com
Delivered-To: ipr-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B81C151081; Sun, 23 Jul 2023 16:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 2pYL4DPmOltO; Sun, 23 Jul 2023 16:52:11 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D002AC15107C; Sun, 23 Jul 2023 16:52:11 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-263253063f9so2487688a91.1; Sun, 23 Jul 2023 16:52:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690156331; x=1690761131; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:sender :from:to:cc:subject:date:message-id:reply-to; bh=ppp8XbUbxR3w5q944TL6bjUFaR3CuaUgjFQfnt7WeRc=; b=jeMAoLLiJYI/LY8YLYrb98DfWs3CAcjmCjRoYU1Pds8m5Z4BKp/0dzBWMWUSIWgloW 0yjQlOd+te+XEFJH2U010mSMKTegVlWyCnThT+0Nh7IwxVfJ8VzJZnR+w4YM3n1jdgXb KP7ZjTP6YyXnXqTYxwHgj9ubYWQRILcQYZsFB/CpDEolQrH5ShSNSVLgCty/3TXhY8IT Et2P1dzDj2Obx9es8+rx8u6x8pL29DOAbujflRXF9PDCF+wUykNDqcE7zjSbbT+7Eeri MCsIDe2uXB7qYP/ZJSV7v6FUraaRrC3WZhF7mOn0If/eOBgQrcmbXivaX4DQQgIEo065 F3Ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690156331; x=1690761131; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ppp8XbUbxR3w5q944TL6bjUFaR3CuaUgjFQfnt7WeRc=; b=fNdJZrCcsN1HpKbcVe2a16zMXV8siOLq7QrBefonIbLKritbWvguGsW0R/SUsSn6nR DiGc0RGnnVcRR+NIoalPD8S4G6EV5fa7xw0uThVjkVNlVYqMvoJPbEzuDBxnVo0LzWyc fuzW2OKrjCXKn3tTGSc/P2uxnozbooAfHugzeF9T2X7oL6L/cf+TC8kJ82EVWs+VF9og aP+sK9yxR00onLIfcGltyYXYzo0ouyG3Ylbfd+dADvZHZIYF6UrHhDwqnyXFtTEDVI+2 VUtKAqsUuDi6e1L67UVJpvcQGMl6O/5tUolFQVliJswq4cgL7Leymq4q5wtiW9TtjHwm 6V5A==
X-Gm-Message-State: ABy/qLbzAwj8LRghJGcq5zuWnkiWVBw1pVd7/oU7Pz0TT+MzPQYnMo26 ZxF//k3MJ492VWI3RJEa1yoLk+Vu4To=
X-Google-Smtp-Source: APBJJlEea2MCCFOflgWfhH7m15BhgzlQfP+HI1gGPUpei1wcUHY9qInqg08AFqY0SA8JzOK86eKZjA==
X-Received: by 2002:a17:90a:6f65:b0:268:1d1e:baaf with SMTP id d92-20020a17090a6f6500b002681d1ebaafmr1215833pjk.17.1690156330801; Sun, 23 Jul 2023 16:52:10 -0700 (PDT)
Received: from ?IPV6:2406:e003:10cc:9901:b2e1:1101:7ba7:19fd? ([2406:e003:10cc:9901:b2e1:1101:7ba7:19fd]) by smtp.gmail.com with ESMTPSA id gf4-20020a17090ac7c400b00263d15f0e87sm5434893pjb.42.2023.07.23.16.52.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 23 Jul 2023 16:52:09 -0700 (PDT)
Sender: Brian Carpenter <becarpenter46@gmail.com>
Message-ID: <33942b92-0734-fc56-7dce-af96e1fc3e04@gmail.com>
Date: Mon, 24 Jul 2023 11:52:03 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Handling IPR disclosures through draft reorganizations
To: Jay Daley <exec-director@ietf.org>
Cc: ipr-wg@ietf.org, Carsten Bormann <cabo@tzi.org>, "Scott O. Bradner" <sob@sobco.com>
References: <4B64CBB8-E002-4562-836E-0D6F63629837@tzi.org> <21eff136-d68a-ccff-761f-48398c45ad66@gmail.com>
Content-Language: en-US
In-Reply-To: <21eff136-d68a-ccff-761f-48398c45ad66@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipr-wg/bzhtaOOHUI-ZfOFU1VmU4Xuet6U>
X-BeenThere: ipr-wg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IPR-WG <ipr-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipr-wg>, <mailto:ipr-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipr-wg/>
List-Post: <mailto:ipr-wg@ietf.org>
List-Help: <mailto:ipr-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipr-wg>, <mailto:ipr-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jul 2023 23:52:16 -0000

Jay,

Are you aware that the IPR disclosure page apparently does not enforce the very precise rule in BCP 79 that I-Ds cited in disclosures must be referenced by specific version number?

This seems to be a 9-year-old bug, with consequences as described in Carsten's original message at https://mailarchive.ietf.org/arch/msg/ipr-wg/Vr13La4lbl5Ck61ISlPC20V1Hmo .

Regards
     Brian Carpenter

On 20-Jun-23 09:08, Brian E Carpenter wrote:
> I believe that Carsten has uncovered a very serious situation.
> 
> On 19-Jun-23 19:50, Carsten Bormann wrote:
>> In July 2021, the CoRE WG split the draft-ietf-core-dynlink into two parts, draft-ietf-core-dynlink proper (about dynamic link bindings), and the separately progressed draft-ietf-core-conditional-attributes.
>> It has been slow going, but we now have mostly completed work on the latter, and would like to take up finishing the former.
>>
>> One situation that is a bit weird after the split is that the original dynlink (that was including both what is now dynlink and a previous version of the conditional attributes specification) came out of an individual draft that has IPR disclosures on it:
> 
> Up to and including IPR disclosure #2508 on 2014-12-19, disclosures against I-Ds specified the draft version number. For reasons that I have forgotten, if I ever knew them, disclosures since then have not specified the version number. That change creates the breakage that you describe, and I believe it's a *serious* bug - disclosures must be against a specific version number rather than against unspecified past and future versions of the draft.
> 
> RFC 3668 (applicable from February 2004) and RFC 4879 (applicable from March 2005) were rather precise:
> 
> "The disclosure must also list the specific IETF or RFC Editor Document(s) or activity affected.  If the IETF Document is an Internet-Draft, it must be referenced by specific version number."
> 
> RFC 8179 (applicable since May 2017) is equally precise:
> 
> "An IPR disclosure must include ... (c) the specific IETF Document(s) or activity affected, and (d) if the IETF Document is an Internet-Draft, its specific version number."
> 
> I really hate to say this, but it seems to me that all IPR disclosures against I-Ds since 2014-12-27 do not conform to RFC 4879 or RFC 8179. Indeed, RFC 8179 confirms that the change made in late 2014 was a serious error.
> 
> If the disclosure that Carsten refers to had been correct, i.e. specified the version number as required, his problem would not exactly go away, but it would be tractable.
> 
> Does anyone here know why we started to break our own rule in December 2014?
> 
> How can we fix the ~3500 broken IPR disclosures since then? Presumably, we must deem them to apply to the draft version that was current at the date of the disclosure.
> 
>       Brian
> 
>>
>> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-core-dynlink
>>
>> IANAL, but it very much seems the disclosure might be related to the part of the specification that went into conditional-attributes.
>> So, after the split, these disclosures are now associated in our database with the wrong draft.
>>
>> The then holder of the patent claims in the disclosures apparently has since decided to abandon those claims.  It does not seem easy to obtain a formal statement from them to that effect (the abandonment, however, appears to be easy to ascertain from the patent databases; IANAL though); after all, there no longer is any patent claim that needs to be disclosed.
>>
>> So it seems I have two questions:
>>
>> (1) How do we handle IPR disclosures that stick to the wrong draft after a reorganization like the split we did?
>>
>> (2) How do we handle the absence of negative IPR disclosures?
>>
>> Grüße, Carsten
>>
>>
>> (This could also be discussed in the more general context of updating IPR disclosures, e.g., <https://mailarchive.ietf.org/arch/msg/ipr-wg/IHlcUZmeyanJ1f_hXKqu9yvSy_8>.)
>>
>>
>>
>> _______________________________________________
>> Ipr-wg mailing list
>> Ipr-wg@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipr-wg