Re: BCP97bis

Russ Housley <> Fri, 15 October 2021 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA04A3A0A08 for <>; Fri, 15 Oct 2021 12:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RaHfRLlD7OYx for <>; Fri, 15 Oct 2021 12:27:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B0D93A0A05 for <>; Fri, 15 Oct 2021 12:27:24 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBE27300CBC for <>; Fri, 15 Oct 2021 15:27:24 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id KwQneSVtVk-E for <>; Fri, 15 Oct 2021 15:27:22 -0400 (EDT)
Received: from a860b60074bd.fios-router.home ( []) by (Postfix) with ESMTPSA id BD799300BD1; Fri, 15 Oct 2021 15:27:22 -0400 (EDT)
From: Russ Housley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_767EE09B-E435-4C4E-89A1-12F3C403ED05"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Subject: Re: BCP97bis
Date: Fri, 15 Oct 2021 15:27:20 -0400
In-Reply-To: <>
Cc: IETF <>
To: "Murray S. Kucherawy" <>
References: <> <>
X-Mailer: Apple Mail (2.3445.104.21)
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: Fri, 15 Oct 2021 19:27:29 -0000

Hi Murray.

I have on concern and a few editorial suggestions.


Section 4.1 says:

   o  A note is included in the reference text that indicates that the
      reference is to a target document of a lower maturity level, that
      some caution should be used since it may be less stable than the
      document from which it is being referenced, and, optionally,
      explaining why the downref is appropriate.

There are many cases where cryptographic algorithms are specified in Informational RFC, and then a Standards-Track document is used to specify protocol conventions for using that algorithm.  the algorithm specification is not unstable, and requiring a note like this sends the wrong message to the reader.


Section 1 says:

   It should also be noted that Best Current Practice documents
   [RFC1818] have generally been considered similar to Standards Track
   documents in terms of what they can reference.  For example, a
   normative reference to an Experimental RFC has been considered an
   improper reference per [RFC2026].

These two sentences are not really making the same point.  With the second sentence starting with "For example", I expected it to be related to the first sentence.

Section 1.1 uses the term "new RFC".  However, the "new" is not needed.  The defintion ofr a normative reference apply to very old RFCs too.


> On Oct 15, 2021, at 1:12 PM, Murray S. Kucherawy <> wrote:
> Colleagues,
> I've got a draft that seeks to update BCP 97, which is the guidance around how we handle normative downward references.  It's currently made up of three separate RFCs and an erratum, so this will consolidate those into a single document.  The main mission here, though, is to update the guidance around normative references to external documents, especially those behind paywalls.
> The draft is being sponsored by Erik Kline and can be found in the datatracker here:
> <>
> Feedback is welcome, either on this thread or to me or Erik directly.  If people are generally happy with it as-is, we can initiate Last Call before IETF 112 begins next month.
> Thanks,