Re: BCP97bis

Russ Housley <housley@vigilsec.com> Sat, 16 October 2021 15:45 UTC

Return-Path: <housley@vigilsec.com>
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 C80343A0B70 for <ietf@ietfa.amsl.com>; Sat, 16 Oct 2021 08:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 5-66oVZNqoNb for <ietf@ietfa.amsl.com>; Sat, 16 Oct 2021 08:45:35 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DC03A0B6F for <ietf@ietf.org>; Sat, 16 Oct 2021 08:45:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 17100300C19 for <ietf@ietf.org>; Sat, 16 Oct 2021 11:45:36 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jte2DcQCvcDz for <ietf@ietf.org>; Sat, 16 Oct 2021 11:45:33 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 4ADC4300B74; Sat, 16 Oct 2021 11:45:33 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <C92D456E-63ED-453B-8F33-3AAECA40D1DA@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_784EC65A-413E-4BF0-8009-86E271CF579B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Subject: Re: BCP97bis
Date: Sat, 16 Oct 2021 11:45:30 -0400
In-Reply-To: <CAL0qLwbLqyWSqFGL2x-FpXXD19QG9-eZkrnTVm_fxt3tUfZSgg@mail.gmail.com>
Cc: IETF <ietf@ietf.org>
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.com> <C657F78F-FF99-4898-8A08-844B32589DDE@vigilsec.com> <CAL0qLwbLqyWSqFGL2x-FpXXD19QG9-eZkrnTVm_fxt3tUfZSgg@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/iA-xzX9r3YTYhnJ7PqqlkFjYJss>
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: Sat, 16 Oct 2021 15:45:40 -0000


> On Oct 16, 2021, at 12:56 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
> 
> Hi Russ,
> 
> On Fri, Oct 15, 2021 at 12:27 PM Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
> I have on concern and a few editorial suggestions.
> 
> CONCERN
> 
> 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.
> 
> Interesting.  This text is preserved from RFC 4897.  But now that you mention it, I don't think this particular bit of process has ever been used for as long as I've been observing.
> 
> Also, the paragraph immediately after that one gives the IESG discretion about what such a note should include.  The case you cite seems to me to be an ideal one in which to use that discretion, perhaps with the advice of the authors/editors/chairs.

I think that the text should be included ONLY when the downref is less stable than the document making the reference.

> 
> EDITORIAL
> 
> 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.
> 
> And that one is copied right out of RFC 3967, which got all this started.  But I agree.  Perhaps "For example, a normative reference from a BCP to an Experimental ..." ?

That is an improvement.

> 
> 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.
> 
> Also copied from RFC 3967, but I agree.  Will edit accordingly.

Thanks.

Russ