RE: BCP97bis Mon, 18 October 2021 14:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E62D3A1488 for <>; Mon, 18 Oct 2021 07:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Status: No, score=-2.798 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TQnLp6TIQ__J for <>; Mon, 18 Oct 2021 07:57:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D71C73A1482 for <>; Mon, 18 Oct 2021 07:57:46 -0700 (PDT)
Received: from (unknown [xx.xx.xx.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4HY0NS58gWz5vhG; Mon, 18 Oct 2021 16:57:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1634569064; bh=AlbonZPyiXhMSss4dfqftGOdawYlo8lc7bR0PdFDZQY=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=HkBti9bbVGr9iPCE+M9yCBY2lMMjqrIdlB6lCkYOyDpjYYfH+Sq6DQtSYvkelU3N9 yYlJYV8nxtEOfb6RHLZX/D1AReUGiI5szBA74Ssagw7WR7ejwDZ1aDQ7zxgQqt4vxV M0YWugejppAgwa3+L+54BVUW8jhPGhQ0F3W/mDRZOamPY2s7naq0W/c34M+UnsSQQK FmP4cYXrVSzB/zBdiPyAtPosabX/bH6dyvV9+y8UZiip88j+sIKmNszwqHRBoPLVIz kfky06A+zgR+nS2yIjeKa7a7JdNOkw0SUE5FJIQUuqmbv/mk5kSRSnQkgXV4PwGg1m dj3nnM0HwM5Hw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4HY0NS4Jp0zDq7C; Mon, 18 Oct 2021 16:57:44 +0200 (CEST)
To: "Salz, Rich" <>, "Murray S. Kucherawy" <>
CC: ietf <>
Subject: RE: BCP97bis
Thread-Topic: BCP97bis
Thread-Index: AQHXwef7YbcJzymQ9E23b0PBRXQisqvYd0eAgAAmFACAADe6gIAABmPQ
Date: Mon, 18 Oct 2021 14:57:43 +0000
Message-ID: <2284_1634569064_616D8B68_2284_224_1_787AE7BB302AE849A7480A190F8B93303542DECC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2021-10-18T14:51:40Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=80214e31-b55b-4315-ae04-e652faa5a716; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303542DECCOPEXCAUBMA2corp_"
MIME-Version: 1.0
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 14:57:53 -0000

Hi all,

I agree with the concern raised below.

It is likely that securing access would be to pay the fees for every access. I’m not sure this can be fixed by write-up unless we have in mind something similar to the approach considered in my write-up at:

All normative references are published RFCs, except a reference to an
external specification ([F3411-19]).

Note that [F3411-19] is not freely available ($88), but an early
version is publicly available at
OpenDroneID_Bluetooth_0.64.3.pdf.  A pointer to this freely available
document is also cited in the document.  This is clearly called in
the draft (see the text right after Figure 2).


De : ietf <> De la part de Salz, Rich
Envoyé : lundi 18 octobre 2021 16:29
À : Carsten Bormann <>; Murray S. Kucherawy <>
Cc : ietf <>
Objet : Re: BCP97bis

  *   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.

I understand the desire for everything that is defined by the IETF to be built on public freely available resources.  I think this goes WAY WAY WAY too far.

Can I buy a copy of a standard and require it to be postal mailed to everyone serially?


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.