Re: [irsg] New document shepherd writeup

Carsten Bormann <cabo@tzi.org> Wed, 04 May 2022 16:05 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B3CC157B5E for <wgchairs@ietfa.amsl.com>; Wed, 4 May 2022 09:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 FnmURWQ5AepQ for <wgchairs@ietfa.amsl.com>; Wed, 4 May 2022 09:05:24 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 33B99C15948A for <wgchairs@ietf.org>; Wed, 4 May 2022 09:05:23 -0700 (PDT)
Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4KthW25XwbzDCc7; Wed, 4 May 2022 18:05:18 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Subject: Re: [irsg] New document shepherd writeup
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <69281967-83db-9ec3-26e1-67028a0cfa92@joelhalpern.com>
Date: Wed, 04 May 2022 18:05:18 +0200
Cc: Lars Eggert <lars@eggert.org>, IETF WG Chairs <wgchairs@ietf.org>
X-Mao-Original-Outgoing-Id: 673373118.3429919-cedf0a3d0413dcfc64e50a6689a9cf3f
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F4548AC-ABC9-4227-B509-E616E8B006F3@tzi.org>
References: <F4A44FCE-D31B-4FE8-9950-6C60CDD9DD36@eggert.org> <CAOW+2dsiHimBnUr1++Y+nq6r6oxA5jDa8sXM4g3k-vjXfDbPfQ@mail.gmail.com> <3EE82F27-F170-4E89-8491-B021C94E7B28@eggert.org> <69281967-83db-9ec3-26e1-67028a0cfa92@joelhalpern.com>
To: Joel Halpern <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/tHYhOfq45Ka-hN6MHlevTuy7XfY>
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wgchairs/>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 May 2022 16:05:26 -0000

On 2022-05-04, at 14:46, Joel Halpern <jmh@joelhalpern.com> wrote:
> 
> The important existing requirement was that the authors (and by some interpretations the named contributors) confirmed explicitly that all known IPR believed to be relevant has been disclosed. That requires explicit responses from those people.

Requirement for what?

I’m not aware of such a requirement.

(I’m aware of an obligation to disclose, buried somewhere in BCP78/89.)

I’m aware about a checklist item that a shepherd can answer based on their knowledge.  If I’m shepherding a document, and I can’t get that confirmation (e.g., because the author died or because of a more mundane reason), then I’ll write this up and send the shepherd report forward.
[Note that a typical responsible AD response, asking the WG chairs to demote that non-responding author, does nothing at all to solve the underlying problem.]

I think that we want to have two things here:

— A general “did you know that you have to/SHOULD disclose” broadcast reminder (unreliably) to the constituency (WG, …).  The shepherd could report that this broadcast reminder has been sent.

— the desire for an explicit confirmation round with a select set.  Note that we make no requirements on the formality of this confirmation (is it a signed email?  How did you verify the key?), not even that it is uttered in the public.
Whether the contents of the RFC 7322 contributor section belong to that set or not depends on how the authors are using that contributor section — “Peter Smith proposed alternative 3 that clarified the choices but after much deliberation was not included in this specification” vs. more actual authors than 5 so we shove some into the contributors section because of RFC 7322.

As an author, I wouldn’t want to be in a position that I need lie about someone’s contribution just because they have a burnout or are otherwise hard to reach.  This confirmation is good practice, but not a requirement.

Grüße, Carsten