Re: BCP97bis

Carsten Bormann <> Mon, 18 October 2021 07:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C6CE3A1217 for <>; Mon, 18 Oct 2021 00:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zVlmiSztG5oI for <>; Mon, 18 Oct 2021 00:09:17 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E39D83A0A10 for <>; Mon, 18 Oct 2021 00:09:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4HXnzv0XzRz2xKG; Mon, 18 Oct 2021 09:09:15 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_490FBB62-7787-4F7E-A97E-9313FF60314C"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Subject: Re: BCP97bis
From: Carsten Bormann <>
In-Reply-To: <>
Date: Mon, 18 Oct 2021 09:09:14 +0200
Cc: ietf <>
Message-Id: <>
References: <> <> <>
To: "Murray S. Kucherawy" <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Oct 2021 07:09:22 -0000

> At a minimum, authors/editors of source documents need to secure freely available copies of the target documents for use by all anticipated reviewers during the source document's life cycle, which includes working group participants, any member of the community that chooses to participate in Last Call discussions, area review teams, IANA expert reviewers, and members of the IESG. The mechanism for acquiring access to those documents is to be be specified in the shepherd writeup. <>
As John Klensin has pointed out, this really can apply only to type-1 documents (and, actually, only if there is a certain power relationship).

I don’t really have a constructive suggestion, but I think if we enshrine this bit of existing policy/practice into a process document, we need to be more careful about what we actually require.
Maybe a downref needs to be explicit on whether this is a type-1 or a type-2.

Grüße, Carsten