Re: BCP97bis

"Murray S. Kucherawy" <superuser@gmail.com> Sat, 16 October 2021 04:56 UTC

Return-Path: <superuser@gmail.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 5E4CB3A096F for <ietf@ietfa.amsl.com>; Fri, 15 Oct 2021 21:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 qEjTqaQGa4ZS for <ietf@ietfa.amsl.com>; Fri, 15 Oct 2021 21:56:20 -0700 (PDT)
Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3063A096D for <ietf@ietf.org>; Fri, 15 Oct 2021 21:56:20 -0700 (PDT)
Received: by mail-ua1-x92a.google.com with SMTP id i15so666464uap.0 for <ietf@ietf.org>; Fri, 15 Oct 2021 21:56:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9XH1MCbTDAg5mvwPjeFNeGsSZeIHUvFAwTP697NaSno=; b=N1oYhZwyRSGIQnFGKG1ezdm5oYu2GT+wty9hqZeLXn2Re5nO9dI1Ey7unp42Fmkfq3 QuNeN9Ip16KnPSx26c2XEBtFN2p7CHc6lq/X+2XonCXVODOqEz2c1ZD707jzZZkpP6k6 ohgrsDqD/sCNyoyES0IWmUR/S4cxAUYqaNsFn9aAjWI90vYhJTuswAO19fvTqhRXwORc esIVshWNRr2IgpKpSawMsjFWXKLIqWGOn5/m+LGIKr1MAuTpR5pUV53WnIcJVhn6k+ij eLPe59G0PNBNQb2VskVq1NQpkQETRa0oHPvk4Q759tcCc8xc6eIVLtAMFTUGeGZMjJ7s Iclw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9XH1MCbTDAg5mvwPjeFNeGsSZeIHUvFAwTP697NaSno=; b=YozlvAT2nuHH8JVcO05NUB7arYRrqg/d25Ztq3REH4rrK2F3kcJeCJyhOs+h47fL8Q tee5QpId/mFrf7vi0tapD8ebYpq95i7l86h+6urZsmzf6cZbbf6RYvhdcan4loXrwHLL 6yopB+U4r0aKB+7+MzUzxtkd5pdlPlQ8xSI7G+5BrbRk+t3GuqsC6Oiwf57LUqsDnJaf v7C8auQrHcnAh6G5UkNgWg8/4gNmcIq2xRq1LTfu1+rH2h9xQo4LEIOc+8t8FtRcyqGc 3NMRxaW4iIoEsdk3w3YSh92tDnNyh1ix1yZGnrmgLdtwZC1Md6kg6SwQoXhUGsFSyCTl W76Q==
X-Gm-Message-State: AOAM5318GWAt85QaWaxwZ9IT2qU0yYI6tLZIzcFjvsZ8diUJML0+GjqP 2dnbG690EUgv9Cg/pwGdsrbMGHxTQXvrurrwmBtRhKH0
X-Google-Smtp-Source: ABdhPJyCilQ7tVjU467PMdpsyt1u73IyaxbHuVjyWJ21T6EwxqSWyTRjWAbXgvT4dU6UzrzX2QUVL11v/9UJi9/88MI=
X-Received: by 2002:a67:d38e:: with SMTP id b14mr18443382vsj.13.1634360179090; Fri, 15 Oct 2021 21:56:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.com> <C657F78F-FF99-4898-8A08-844B32589DDE@vigilsec.com>
In-Reply-To: <C657F78F-FF99-4898-8A08-844B32589DDE@vigilsec.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Fri, 15 Oct 2021 21:56:08 -0700
Message-ID: <CAL0qLwbLqyWSqFGL2x-FpXXD19QG9-eZkrnTVm_fxt3tUfZSgg@mail.gmail.com>
Subject: Re: BCP97bis
To: Russ Housley <housley@vigilsec.com>
Cc: IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e8e8c205ce7121a0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/5IkoQTr2wrPgieOD2XI7gTgs_P8>
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 04:56:26 -0000

Hi Russ,

On Fri, Oct 15, 2021 at 12:27 PM Russ Housley <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.

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 ..." ?

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.

-MSK