Re: BCP97bis

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 18 October 2021 02:44 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 5E3813A0CAD for <ietf@ietfa.amsl.com>; Sun, 17 Oct 2021 19:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 0TZ4oKCyP7CC for <ietf@ietfa.amsl.com>; Sun, 17 Oct 2021 19:44:23 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB91F3A0CA9 for <ietf@ietf.org>; Sun, 17 Oct 2021 19:44:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id ACC3418142; Sun, 17 Oct 2021 22:44:52 -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 h9VIFrUrJGtP; Sun, 17 Oct 2021 22:44:51 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A2A39180EC; Sun, 17 Oct 2021 22:44:51 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B5136527; Sun, 17 Oct 2021 22:44:20 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Murray S. Kucherawy" <superuser@gmail.com>
cc: ietf <ietf@ietf.org>
Subject: Re: BCP97bis
In-Reply-To: <CAL0qLwaBgTVFahe58GJZ6z3+sh-Ny8gKSEr9z747=DHgDvVzrQ@mail.gmail.com>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.com> <15645.1634416152@localhost> <CAL0qLwaBgTVFahe58GJZ6z3+sh-Ny8gKSEr9z747=DHgDvVzrQ@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: Sun, 17 Oct 2021 22:44:20 -0400
Message-ID: <26583.1634525060@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/NDN8dlt2fwthrKI6qQdlCW71DAk>
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 02:44:29 -0000

Murray S. Kucherawy <superuser@gmail.com> wrote:
    > } 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.

    >> It seems to me, if this requirement is to be taken seriously, that either
    >> the
    >> DT or some other resource needs to contain notes on how to obtain the
    >> references.


    > That'll be different for every source of the references, right?  I'm not
    > sure how we could do that programmatically for all cases.

Programmatically? Not what I meant.

Freeform text in the datatracker... as in, "email bob and tell you are
                        reviewing FOO, in order to get document BAR"

    > Really how you go about getting it is somewhat orthogonal to the point
    > we're trying to address with this update, which is: If you're going to make
    > a normative reference to something access to which is restricted, that has
    > to be resolved somehow before it goes to the IESG; we (and any other
    > reviewers, e.g., the review teams) need the referenced material to be able
    > to do our jobs.

If people who work on ITU-T,3GPP,IEEE,ANSI documents come to us with a
document for us to publish, it seems like they ought to make all the
background available to us.

Are we getting this kind of minimum?

    >> So I am reacting the word "At a minium", and I don't think we are even
    >> getting to that minimum.   There are a bunch of specifications that aren't
    >> just transitioning from some legacy specification to an RFC, but which we
    >> are
    >> allocating numbers/etc. for entities which make it very difficult to read
    >> their
    >> documents.  I think that we should be doing more than the minimum here.

    > What do you suggest in terms of text changes here to address what you're
    > talking about?

} At a minimum,

**prior to WGLC and sectorial review**

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

Maybe then add:
"Access to the documents should be noted in the Shepherd write up."

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide