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