Re: BCP97bis
Michael Richardson <mcr+ietf@sandelman.ca> Mon, 18 October 2021 21:31 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2CA3A0D48 for <ietf@ietfa.amsl.com>; Mon, 18 Oct 2021 14:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvVF4wrWX2dj for <ietf@ietfa.amsl.com>; Mon, 18 Oct 2021 14:31:13 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3350E3A0D43 for <ietf@ietf.org>; Mon, 18 Oct 2021 14:31:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8DA201801C; Mon, 18 Oct 2021 17:31:45 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cencfjHgwcS2; Mon, 18 Oct 2021 17:31:44 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 99C5B1800C; Mon, 18 Oct 2021 17:31:44 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B9E7257B; Mon, 18 Oct 2021 17:31:10 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Warren Kumari <warren@kumari.net>
cc: "Murray S. Kucherawy" <superuser@gmail.com>, Carsten Bormann <cabo@tzi.org>, ietf <ietf@ietf.org>
Subject: Re: BCP97bis
In-Reply-To: <CAHw9_iKkm1C2BwTfSu35WQbzNYSvBAGJiDVh6kh7zYDjp4rofw@mail.gmail.com>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.com> <CAL0qLwa4ChOsuMkmoP_sAGv3Wn2AcSz1OkijmxZzP+MGvnwviA@mail.gmail.com> <849D7F9E-8AD4-4CE8-A66C-358FB1F2E6AE@tzi.org> <3AC61568-DBDC-4ADB-9935-9C53333AE7E2@akamai.com> <CAL0qLwZvCq7R=WBFsrwf51CKSN8ur0Yj-F=VOHnP=hQD0ooj-A@mail.gmail.com> <890A4965-D847-4606-849C-A0C8D8FD3B0C@akamai.com> <CAL0qLwZtBiuh5n3U_pKma1s4ymPOCy7CY0pFaaacx6NDYNu5AQ@mail.gmail.com> <CAHw9_iKkm1C2BwTfSu35WQbzNYSvBAGJiDVh6kh7zYDjp4rofw@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 18 Oct 2021 17:31:10 -0400
Message-ID: <3199.1634592670@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/RIJL-_wa1P2e-1-MjEVqQ550F5w>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Oct 2021 21:31:19 -0000
Warren Kumari <warren@kumari.net> wrote: > On Mon, Oct 18, 2021 at 10:41 AM Murray S. Kucherawy <superuser@gmail.com> > wrote: >> On Mon, Oct 18, 2021 at 7:36 AM Salz, Rich <rsalz@akamai.com> wrote: >> >>> >>> - The IESG has had multiple cases during my time there where we >>> haven't had access to some normative reference, and so we can't do our >>> job. This has added long delays to document processing. That's what we're >>> trying to address here. >>> >>> >>> >>> I believe it is far more common for the IESG to review and progress >>> documents without having all normative references tracked down and read. >>> >> >> The role doesn't matter, does it? As an Area Review Team member or even a >> Working Group participant faced with a document with normative references >> behind a paywall, you face the same problem. >> > Yes. No. Maybe. > There are some protocols where the only people > implementing/interoperating/whatever are all part of a small group that > already knows and understands the <whatever is in the paywalled document>, > and / or are willing to shell out the money to pay for it. > A recent example of this is > https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/ -- there are likely to > only be a very small number of people who will implement the tranport part, > and they already understand the "NFC Logical Link Control Protocol version > 1.3" and / or would be willing to purchase it. I think that actually, this document is a really good example of how things go badly. Because only a small number of people have access to that background document, nobody can meaningfully review it. Maybe that's why the document has been around for *7* years. The shepherd write up does not tell me where to get that background document, although apparently I'm among those who discussed the document. I don't know the background for one, and I certainly couldn't implement without the background. > Yes, in an ideal world, this would be an open, free, etc document -- but, > absent an ideal world, I still think that it's better that how IPv6 is > transmitted over NFC using 6LoWPAN is documented in an RFC than having an > undocumented protocol.... I mostly agree with you. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- BCP97bis Murray S. Kucherawy
- Re: BCP97bis Russ Housley
- Re: BCP97bis Scott Bradner
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis David Farmer
- Re: BCP97bis Brian Carpenter
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Scott Bradner
- Re: BCP97bis Russ Housley
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Michael Richardson
- Re: BCP97bis and Informational-as-Standard Michael Richardson
- RE: BCP97bis Larry Masinter
- Re: BCP97bis Joel M. Halpern
- Re: BCP97bis Michael Richardson
- Re: BCP97bis Brian E Carpenter
- RE: BCP97bis Larry Masinter
- Re: BCP97bis John Levine
- Re: BCP97bis Scott Bradner
- Re: BCP97bis John C Klensin
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Brian E Carpenter
- Re: BCP97bis Russ Housley
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis John C Klensin
- Re: BCP97bis John C Klensin
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis John C Klensin
- Re: BCP97bis Michael Richardson
- Re: BCP97bis John C Klensin
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis tom petch
- RE: BCP97bis mohamed.boucadair
- RE: BCP97bis ned+ietf
- Re: BCP97bis John C Klensin
- BCP97bis and "freely available" John C Klensin
- RE: BCP97bis John C Klensin
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- RE: BCP97bis mohamed.boucadair
- Re: BCP97bis a process problem tom petch
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Warren Kumari
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Lars Eggert
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Warren Kumari
- Re: BCP97bis Salz, Rich
- Re: BCP97bis and "freely available" Scott O. Bradner
- Re: BCP97bis and "freely available" Brian E Carpenter
- Re: BCP97bis John C Klensin
- Re: BCP97bis and "freely available" Michael Richardson
- Re: BCP97bis and "freely available" John C Klensin
- BCP written by another AD [was Re: BCP97bis] Brian E Carpenter
- Re: BCP97bis a process problem Brian E Carpenter
- Re: BCP97bis Michael Richardson
- Re: BCP97bis and "freely available" Sandy Wills
- Re: BCP97bis and "freely available" Michael StJohns
- Re: BCP97bis and "freely available" George Michaelson
- Re: BCP97bis and "freely available" Randy Presuhn
- Re: BCP97bis and "freely available" George Michaelson
- Re: BCP97bis and "freely available" Brian E Carpenter
- Re: BCP97bis and "freely available" Salz, Rich
- Re: BCP97bis a process problem Michael Richardson
- Re: BCP97bis and "freely available" Michael Richardson
- RE: BCP97bis ned+ietf
- Re: BCP97bis a process problem Brian E Carpenter
- Re: BCP97bis and "freely available" tom petch
- Re: BCP97bis a process problem tom petch
- Re: BCP written by another AD [was Re: BCP97bis] Erik Kline
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Murray S. Kucherawy