Re: BCP97bis
"Murray S. Kucherawy" <superuser@gmail.com> Mon, 18 October 2021 01:53 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 C99CD3A091F for <ietf@ietfa.amsl.com>; Sun, 17 Oct 2021 18:53:34 -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 hkL_pIZ4LYQL for <ietf@ietfa.amsl.com>; Sun, 17 Oct 2021 18:53:30 -0700 (PDT)
Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 769013A091C for <ietf@ietf.org>; Sun, 17 Oct 2021 18:53:30 -0700 (PDT)
Received: by mail-vk1-xa2b.google.com with SMTP id l39so7836457vkd.7 for <ietf@ietf.org>; Sun, 17 Oct 2021 18:53:30 -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=sRhj4ZwMka4Y+RWX3rJzdEtXTI4lIvBvQ4+fRrh0Eng=; b=DQjsaIyGO+VYVQTUANwMVcoq+FJQQvAITiMYh14Lae7Yny0wHviu9OqEpXqSBLDUb7 C/8GsBwJ6cK0I8Kk330tHVoU9tBIhGReVkHK3FG+9/lN9A1WDceOMxU00TT9bPG2PBYT a+725tr0dyNZTtwAcR/StSADt1GcaXM4CCDkcVtU64bVSr47UdZzKwaXnf7znWp55ns+ +9o10J49mZCSQx2ZjIfhpEgbFRk5G3d8xZnv4Bj/Sf337i41a7cXp3Z+5xMP/uV3roL2 OQnXuwfHa5pkLUtghrvqOU7PWgyX6SVjgNdQ2B8PcQQ4IZEgNd9nm1Bhw197YT8b3mxf 2q3g==
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=sRhj4ZwMka4Y+RWX3rJzdEtXTI4lIvBvQ4+fRrh0Eng=; b=tgRsNclp/ehGW3VkOx7UvvzVOgFH1Y+PijBsY8nYWWiwlZ0wPbuiCa9dHghMT82hbt GvSGWLGbKZHqa9vlbB3ENh9U5z5XhHCo4PSzE+I2Rd3q8NpwItaPycTY3glN/rECg7Ur agKnNdjin/GzQiAOZRwhT7Wf37ROzMOaCA/H7Trcw7L9ezx3eFsv1fg/aib52cg6C73c euHNawDsvvLQMV7yzlQWj5uiTmZBaqnCuyryllKhJECm745u0eKds0L2iYuI6+xdTGtH +1vY8bwG5h8fUuZMcadBc07k1Q7OsZ9Q0AezOiH8GqpDXW9FJT9MkuydW7qgMgUdNkIU ZR3A==
X-Gm-Message-State: AOAM531knDrvHlBmeF6Fotambhbh2D38y53acedRTdEHFtE3y4UYms8A 0dJEbRU5EqEgeQ2hCLi/xm6ktwGhIdTXVCg7kcg=
X-Google-Smtp-Source: ABdhPJyXQX/c5d/CzlMLsU/OTxBo84B5jogK7qhGLhzfhUoflaN4cDxD5uIYiPrxg5r0VBit3BctThVp/cFNssWhIMk=
X-Received: by 2002:a1f:1c56:: with SMTP id c83mr22375684vkc.6.1634522009282; Sun, 17 Oct 2021 18:53:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <C657F78F-FF99-4898-8A08-844B32589DDE@vigilsec.com> <CAL0qLwbLqyWSqFGL2x-FpXXD19QG9-eZkrnTVm_fxt3tUfZSgg@mail.gmail.com> <C92D456E-63ED-453B-8F33-3AAECA40D1DA@vigilsec.com> <27721119-D39D-427D-8EEE-C5027DA15B06@akamai.com> <007c01d7c2dc$9090c780$b1b25680$@acm.org> <5385fd6f-b7a7-3baa-1374-f4d8d87216fd@joelhalpern.com> <6454.1634428177@localhost> <6702b78c-037f-f5fd-78a6-901a999dab54@gmail.com> <7E25FC36-0757-45EA-AB12-76F6818C797C@sobco.com> <B6BBF8C8788D1ECEACF549C0@PSB> <D290EE8C-6709-4A08-A827-41F7494D4E58@tzi.org> <A117413E-065D-478E-A1CA-3421D5FB0D12@vigilsec.com> <6803AC5BAEB3D637D13658B7@PSB>
In-Reply-To: <6803AC5BAEB3D637D13658B7@PSB>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Sun, 17 Oct 2021 18:53:17 -0700
Message-ID: <CAL0qLwYY7mRwPz=bYnKN66tNmj4agaf5eEOd8-yMh3phEGmyGA@mail.gmail.com>
Subject: Re: BCP97bis
To: John C Klensin <john-ietf@jck.com>
Cc: Russ Housley <housley@vigilsec.com>, Carsten Bormann <cabo@tzi.org>, IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bdac7b05ce96cf5a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/j5OGXVXVinZMjeOIlBZfTJjILJE>
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: Mon, 18 Oct 2021 01:53:35 -0000
On Sun, Oct 17, 2021 at 3:45 PM John C Klensin <john-ietf@jck.com> wrote: > I actually think that suggests something that should probably be > considered for BCP97bis: that the downref procedure and registry > should be used only when there are substantive reasons why the > relevant document cannot be upgraded or that doing so would > require an unreasonable amount of effort. That would strengthen > the text that now appears in the last paragraphs of Murray's > Sections 4.2 and 5 but even the current text suggests to me that > "trivial" is not a good enough reason for the use of that > registry. > > I also just noticed that the draft does not appear to describe > the contents and format of that registry, what entity is > responsible for keeping it, and where. Especially if we take > the position that, once something is in that registry, no > special procedures (or different procedures) need be followed to > use the reference in another document, the registry should > record why downref permission was granted, in which the > document's categories the reference falls, and any additional > explanation that seems necessary -- that information should not > just be in the Last Call. My instinct tells me that the RFC > Editor Function should be responsible for the registry itself, > but that might raise issues I have not thought of yet. > Describing the registry's current structure and maintenance is easy enough. I'll add that. It would probably be a nightmare to add that retroactively for the entries already present, but the publication of this revision to BCP 97 could stipulate that, going forward, the reason for downref permission needs to be recorded and made visible for future entries, and who the responsible AD was. What did you mean by "in which document's categories the reference falls"? -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