Re: Status of this memo

ned+ietf@mauve.mrochek.com Tue, 27 April 2021 22:56 UTC

Return-Path: <ned+ietf@mauve.mrochek.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 754393A2432 for <ietf@ietfa.amsl.com>; Tue, 27 Apr 2021 15:56:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 h4DiWt0a0sBD for <ietf@ietfa.amsl.com>; Tue, 27 Apr 2021 15:56:10 -0700 (PDT)
Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B623D3A242E for <ietf@ietf.org>; Tue, 27 Apr 2021 15:56:10 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYDDDOOQG000ASLT@mauve.mrochek.com> for ietf@ietf.org; Tue, 27 Apr 2021 15:51:07 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYDBA1ZCB40085YQ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf@ietf.org; Tue, 27 Apr 2021 15:51:04 -0700 (PDT)
From: ned+ietf@mauve.mrochek.com
Cc: Lars Eggert <lars@eggert.org>, Keith Moore <moore@network-heretics.com>, ietf@ietf.org
Message-id: <01RYDDDMZSMU0085YQ@mauve.mrochek.com>
Date: Tue, 27 Apr 2021 15:26:32 -0700
Subject: Re: Status of this memo
In-reply-to: "Your message dated Tue, 27 Apr 2021 16:11:13 -0400" <57F10F0DB94377E0CDA211F8@PSB>
References: <376f83f0-89a3-cd0e-1792-c8434bd8a5d2@gmail.com> <9ACE59FA-30B6-475A-AF6B-4B874E4A2788@eggert.org> <1804294246.5904.1619512137931@appsuite-gw2.open-xchange.com> <D653D3B2-7666-409A-B856-2A4B1BA958CA@eggert.org> <620f38e4-94f7-2b8c-54f0-1895ce2dded2@network-heretics.com> <1B2562DF-A451-4FFE-BDFD-84BB31CC96DD@eggert.org> <57F10F0DB94377E0CDA211F8@PSB>
To: John C Klensin <john-ietf@jck.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/hKkrAm8w1_7OyWfXQ7m5O0GbTnk>
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: Tue, 27 Apr 2021 22:56:16 -0000


> --On Tuesday, April 27, 2021 16:01 +0300 Lars Eggert
> <lars@eggert.org> wrote:

> > Hi,
> >
> > On 2021-4-27, at 15:40, Keith Moore
> > <moore@network-heretics.com> wrote:
> >> The very notion of "adoption" of a draft by the IETF (or at
> >> least by a working group) is a Bad Idea, as it tends to
> >> indicate an assumed direction for the WG that isn't yet
> >> reflected by a deep understanding of the draft or its
> >> implications, and makes it harder for a WG to change
> >> direction.
> >
> > I'm not sure I follow. WGs have adopted I-Ds for decades; it's
> > the usual way in which the IETF works, and is what causes I-D
> > names to change from draft-yourname to draft-ietf.

> Actually, Lars, formal adoption -- in the form of requiring that
> draft-yourname-... exist before it could be reissued or revised
> and posted as draft-ietf-wgname... -- and requiring more or less
> formal consensus calls to adopt in the WG are a fairly recent
> development.  For much longer, that transition was a matter for
> the individual WG and its style, with the initial versions of
> some documents being posted as draft-ietf-wgname... with only
> the permission of, or encouragement from, a WG Chair who was
> presumably operating on a general sense of the WG and what would
> move things forward.

And in other cases documents went through the entire process
without being renamed.

And then there are the documents that go through the process
without ever being attached to a WG.

> It was possible for that approach to be
> abused although, at least in my experience and awareness, it
> rarely was and, if it was, the WG usually had much more serious
> problems.

I have to agree.

> IIR, the draft-ietf-wgname convention arose, not as an
> indication of status but simply to make it easier to find
> documents that a WG was working on or had associated with it.
> That was long before there was a datatracker or general tools
> much stronger than sorting and grep.

Agreed as well.

> It is easy to make a case that we have gained from the
> additional formality and procedural steps, but it has not been
> that way forever and, in some cases, it has almost certainly
> slowed things down without significant benefit.  And it has
> occasionally has had the downside of encouraging people to treat
> or promote WG documents -- ones that were really no more than
> preliminary working drafts --  as "nearly standards".

Formalities are always added with the best of intentions, and often have a
contingent arguing passionately for the change. And in some cases the result is
some immediate and obvious benefit that can be attributed to the change with a
high degree of confidence.

But this is actually pretty rare. In most cases there's some benefit, but
whether or not it's the result of the change is unclear. Or there may be no
benefit at all, but we retain the change anyway, because it's bothersome
to undo.

I have pointed out many times the "death of a thousand cuts" process creep
imposes. The usual response is, "But this is different! This is a change we
really need to make!"

However, in this case I would like to add that we're also having discussions
aobut the difficulty of attracting newcomers to the IETF.

If you seriously believe that adding more process overhead and formality makes
the IETF more attactive to newcomers, especially when - as has been suggested in
this thread - it adds to the required document boilerplate - I have a couple of
bridges I'd like to sell you.

> > This process is central to our way of working; we even
> > commissioned specific datatracker functionality for it ten
> > years ago (RFC6174) and discussed the common practice in
> > RFC7221.

> But, as I pointed out in another note, RFC 7221 is actually
> extremely relaxed about the degree of "finished" and about when
> consensus about actual content is required.  In that sense, it
> is completely consistent with long term practice.

> While I disagree with much of what Keith has written, I'm in
> sympathy with where I think he is coming from.  And I think we
> would be much better off if we reserved the term "WG consensus"
> for describing a document and its content until it had been
> through WG Last Call or some equivalent procedure by which the
> WG decides it is ready for forwarding to the IESG, recommending
> an IETF Last Call.  Before that "adopted by", "being used as a
> basis for discussion in", or something similar, might be much
> more appropriate, accurate, and less likely to cause confusion
> or be misused.

I've seen the phrase "call for adoption" used quite a few times. Seems
like a reasonable way to put it.

				Ned