Re: BCP97bis

"Murray S. Kucherawy" <> Mon, 18 October 2021 01:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 371BB3A07A3 for <>; Sun, 17 Oct 2021 18:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 4MmSllX1cT7Y for <>; Sun, 17 Oct 2021 18:35:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6C483A08FA for <>; Sun, 17 Oct 2021 18:35:19 -0700 (PDT)
Received: by with SMTP id e10so2879968uab.3 for <>; Sun, 17 Oct 2021 18:35:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=olVfckJaqT4Lm8ViDJ5sFpgxww6rJ7JKNY5VZrZAUlg=; b=K/cM+DFq13vfC+UYxdQkbgTEDwkubIgVyhzJkQN0LaRhYhH6+GucsHEq013YGL5Ex7 VMOXzZAMUksKO3ZZ4ZCh6T8bOjzIFoYmTOhM1FdBaga8+grpFvZZB/VbA4fQBy1K1BgG PIdtBW1wEjXRkYG1WWEDHCZcN2/tOmzg9k/H8VFHoxIqdxY8v53odURHtAWeSCSfXbmA nLS9NAE+VBRB5s5f4HJ9/7WzrLg+O8itzsAerGJD57adON+B0ImVQvW1dNQvrf0IAgmZ mKbfsagj8Q51suNUPjTN/fKxMOkBMs62laYfrKbRk4x7qd5MLOZWdvVdHzB4yBHu5W/r o7BA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=olVfckJaqT4Lm8ViDJ5sFpgxww6rJ7JKNY5VZrZAUlg=; b=1FF6mhWEj5MkjdmlhI1NJzLQhJzBlvTpyQ2AtMhm9vZuAb564eTqTMwpKFRMb4B6EI BwR2vkoS7oMMGK876kN/+h6WGsekvqaxjCS8Qp6I2Wom8zyv+nwri+BxdgP8LCOuXfA8 +sxPLmnf3RFGUvRLkOBPXyw23NqCPZXg3Q2RiY9BjoPkCEtXLdrWA85YWm6/AeweUGFu ZYrGG3ZkzDfZfqhecFwnZF7Kj+NU0oXQUXnIzNdgBlsJBAOO5Dkwj4A9j9cjlgBUbxyZ SuRTSWbP8eclFk2/iW/iDFikN5r/9MtG2zJXn5Vx+/4bMf1Ab2UFZAk0zm7KiqIGghVM Larw==
X-Gm-Message-State: AOAM532e2XWGG/xN3uVsqyH8wHsbWBeNfcHV16fZlv98dXjUem0/eVv0 UuvtQZo71XTrr0U4pXU9YpHcXGbdP3mdgrFIHz9S4VcFtEw=
X-Google-Smtp-Source: ABdhPJz6vEZT344mQHNibk2YF6m5ILtIf9ZPlRZu/emwkEWGJYID9oTLQgmzoE8Y8GJAfiT8bEaEnUOzX6HDDGMFwa8=
X-Received: by 2002:ab0:3a82:: with SMTP id r2mr23017509uaw.101.1634520918447; Sun, 17 Oct 2021 18:35:18 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <15645.1634416152@localhost>
In-Reply-To: <15645.1634416152@localhost>
From: "Murray S. Kucherawy" <>
Date: Sun, 17 Oct 2021 18:35:06 -0700
Message-ID: <>
Subject: Re: BCP97bis
To: Michael Richardson <>
Cc: ietf <>
Content-Type: multipart/alternative; boundary="000000000000b8d8bc05ce968e02"
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 01:35:35 -0000

On Sat, Oct 16, 2021 at 1:29 PM Michael Richardson <>

> Are we having a problem getting downrefs identified early enough, or are
> things okay?

My impression is that idnits and the datatracker are catching these a high
percentage of the time.  In my time on the IESG (a measly 1.5 years) I
haven't managed to catch a document that failed to call out a downref.

I also wonder if we shouldn't have a process to attempt to clean the downref
> registry out, but reclassifying the documents.  The repeated MD5 and HMAC
> document listed as examples seem like good datapoints. (MD5 might be
> Historic, but HMAC is still awesome)

That's an interesting idea, but I think it's perhaps an effort separate
from this one.

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

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.

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?

} Appendix A. Changes Since RFC8067
> } The following are the changes in this document relative to the prior
> state of BCP 97:
> }
> } o Apply erratum #2793.
> doesn't mention any errata.

RFC 8067 was the last document added to the cluster that currently makes up
BCP 97, so this is a list of changes since that milestone.  I didn't mean
to imply that this erratum applies to that RFC.