Re: BCP97bis

John C Klensin <john-ietf@jck.com> Mon, 18 October 2021 13:08 UTC

Return-Path: <john-ietf@jck.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 6B9F23A1361 for <ietf@ietfa.amsl.com>; Mon, 18 Oct 2021 06:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y0ym-jldIqm2 for <ietf@ietfa.amsl.com>; Mon, 18 Oct 2021 06:07:59 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764AE3A11AF for <ietf@ietf.org>; Mon, 18 Oct 2021 06:07:59 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1mcSMt-000P8C-4e; Mon, 18 Oct 2021 09:07:55 -0400
Date: Mon, 18 Oct 2021 09:07:48 -0400
From: John C Klensin <john-ietf@jck.com>
To: Carsten Bormann <cabo@tzi.org>, "Murray S. Kucherawy" <superuser@gmail.com>
cc: ietf <ietf@ietf.org>
Subject: Re: BCP97bis
Message-ID: <0AADD3C960E978FBF6689654@PSB>
In-Reply-To: <C8FE98F4-70CA-42C7-98BC-159AC50DE4A1@tzi.org>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.c om> <CAL0qLwa4ChOsuMkmoP_sAGv3Wn2AcSz1OkijmxZzP+MGvnwviA@mail.gmail.com> <C8FE98F4-70CA-42C7-98BC-159AC50DE4A1@tzi.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/V1yk7VTO34vJVTSee_XpXX4G_MQ>
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 13:08:05 -0000


--On Monday, October 18, 2021 09:02 +0200 Carsten Bormann
<cabo@tzi.org> wrote:

>> This procedure is not to be used if the proper step is to
>> move the document to which the reference is being made into
>> the appropriate category. It is not intended as an easy way
>> out of normal process. Rather, the procedure is intended for
>> dealing with specific cases where putting particular
>> documents into the required category is problematic and
>> unlikely ever to happen.
> 
> So does this now end the practice of certain areas to publish
> a normative specification as Informational first, and then do
> the proper vetting (but with a weaker process) of the document
> at the time it is first used in a downref?
> 
> The third level of maturity that this creates (pre-PS :-) is
> actually quite useful to give specifications some time to
> mature before we fully commit to them. It is a variant of what
> Experimental was meant to be, but that label has acquired a
> mostly pejorative meaning, just as
> 
>   "We are not sure this is a good idea"
> 
> can mean that you are really just not sure (so you make it
> Informational in the above undocumented process) or that a
> sizable part of the community thinks it will turn out not to
> be a good idea (so you make it Experimental).

Actually, Carsten, a different way to look at that practice is
not that it substitutes for the traditional use of Experimental,
but that it restores the three-step/ maturity level standards
process.  Originally, Proposed Standard was fairly close to
"this is normative, we think it is a good idea but some of the
details might not be quite right, it needs additional vetting
and test implementations, and no one sane would deploy it at
scale into a production product before those other steps occur".
My first task as a AD turned out to be explaining to a major
vendor who complained that, by changing some details in a PS we
had made their already-shipped product non-conforming, they were
not going to get any sympathy and should go back and read the
definition of PS.

So, if this is what is now being done with Informational specs
that are treated as normative, deja vu.

    john