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
- BCP97bis Murray S. Kucherawy
- Re: BCP97bis Russ Housley
- Re: BCP97bis Scott Bradner
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis David Farmer
- Re: BCP97bis Brian Carpenter
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Scott Bradner
- Re: BCP97bis Russ Housley
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Michael Richardson
- Re: BCP97bis and Informational-as-Standard Michael Richardson
- RE: BCP97bis Larry Masinter
- Re: BCP97bis Joel M. Halpern
- Re: BCP97bis Michael Richardson
- Re: BCP97bis Brian E Carpenter
- RE: BCP97bis Larry Masinter
- Re: BCP97bis John Levine
- Re: BCP97bis Scott Bradner
- Re: BCP97bis John C Klensin
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Brian E Carpenter
- Re: BCP97bis Russ Housley
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis John C Klensin
- Re: BCP97bis John C Klensin
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis John C Klensin
- Re: BCP97bis Michael Richardson
- Re: BCP97bis John C Klensin
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis tom petch
- RE: BCP97bis mohamed.boucadair
- RE: BCP97bis ned+ietf
- Re: BCP97bis John C Klensin
- BCP97bis and "freely available" John C Klensin
- RE: BCP97bis John C Klensin
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- RE: BCP97bis mohamed.boucadair
- Re: BCP97bis a process problem tom petch
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Warren Kumari
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Lars Eggert
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Warren Kumari
- Re: BCP97bis Salz, Rich
- Re: BCP97bis and "freely available" Scott O. Bradner
- Re: BCP97bis and "freely available" Brian E Carpenter
- Re: BCP97bis John C Klensin
- Re: BCP97bis and "freely available" Michael Richardson
- Re: BCP97bis and "freely available" John C Klensin
- BCP written by another AD [was Re: BCP97bis] Brian E Carpenter
- Re: BCP97bis a process problem Brian E Carpenter
- Re: BCP97bis Michael Richardson
- Re: BCP97bis and "freely available" Sandy Wills
- Re: BCP97bis and "freely available" Michael StJohns
- Re: BCP97bis and "freely available" George Michaelson
- Re: BCP97bis and "freely available" Randy Presuhn
- Re: BCP97bis and "freely available" George Michaelson
- Re: BCP97bis and "freely available" Brian E Carpenter
- Re: BCP97bis and "freely available" Salz, Rich
- Re: BCP97bis a process problem Michael Richardson
- Re: BCP97bis and "freely available" Michael Richardson
- RE: BCP97bis ned+ietf
- Re: BCP97bis a process problem Brian E Carpenter
- Re: BCP97bis and "freely available" tom petch
- Re: BCP97bis a process problem tom petch
- Re: BCP written by another AD [was Re: BCP97bis] Erik Kline
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Murray S. Kucherawy