Re: BCP97bis

"Murray S. Kucherawy" <> Mon, 18 October 2021 01:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C99CD3A091F for <>; Sun, 17 Oct 2021 18:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hkL_pIZ4LYQL for <>; Sun, 17 Oct 2021 18:53:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 769013A091C for <>; Sun, 17 Oct 2021 18:53:30 -0700 (PDT)
Received: by with SMTP id l39so7836457vkd.7 for <>; Sun, 17 Oct 2021 18:53:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <007c01d7c2dc$9090c780$b1b25680$> <> <6454.1634428177@localhost> <> <> <B6BBF8C8788D1ECEACF549C0@PSB> <> <> <6803AC5BAEB3D637D13658B7@PSB>
In-Reply-To: <6803AC5BAEB3D637D13658B7@PSB>
From: "Murray S. Kucherawy" <>
Date: Sun, 17 Oct 2021 18:53:17 -0700
Message-ID: <>
Subject: Re: BCP97bis
To: John C Klensin <>
Cc: Russ Housley <>, Carsten Bormann <>, IETF <>
Content-Type: multipart/alternative; boundary="000000000000bdac7b05ce96cf5a"
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: Mon, 18 Oct 2021 01:53:35 -0000

On Sun, Oct 17, 2021 at 3:45 PM John C Klensin <> 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

What did you mean by "in which document's categories the reference falls"?