Re: Status of this memo

John C Klensin <john-ietf@jck.com> Wed, 28 April 2021 06:16 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 46DCA3A1B29 for <ietf@ietfa.amsl.com>; Tue, 27 Apr 2021 23:16:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 xUGWzMSkS2Jk for <ietf@ietfa.amsl.com>; Tue, 27 Apr 2021 23:16:21 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 030673A1B27 for <ietf@ietf.org>; Tue, 27 Apr 2021 23:16:20 -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 1lbdUf-000G0T-5W; Wed, 28 Apr 2021 02:16:17 -0400
Date: Wed, 28 Apr 2021 02:16:12 -0400
From: John C Klensin <john-ietf@jck.com>
To: Lloyd W <lloyd.wood@yahoo.co.uk>
cc: Benjamin Kaduk <kaduk@mit.edu>, IETF Discussion <ietf@ietf.org>
Subject: Re: Status of this memo
Message-ID: <8CC52E7293AA65FED7B41B30@PSB>
In-Reply-To: <6A7715E6-3180-423A-92AB-859C8E4A3848@yahoo.co.uk>
References: <82023B64CE2138A097AF51B3@PSB> <6A7715E6-3180-423A-92AB-859C8E4A3848@yahoo.co.uk>
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/hQ1KRwjitZva42ufRUJmpBqedLk>
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: Wed, 28 Apr 2021 06:16:25 -0000


--On Wednesday, April 28, 2021 15:32 +1000 Lloyd W
<lloyd.wood@yahoo.co.uk> wrote:

> 
>> On 28 Apr 2021, at 15:14, John C Klensin <john-ietf@jck.com>
>> wrote:
>> 
>> AFAICT, little or nothing.  I do think there is another
>> sub-issue that has confused the conversation. If the WG, in
>> calling the shots, feels a need to micromanage a document
>> editor (whomever that might be) and, in particular, gets to
>> the point of needing consensus calls on editorial --rather
>> than substantive technical-- issues to move forward, then the
>> WG has a problem.  I don't think we can make rules about
>> that, if only because sometimes the solution will be "new
>> editor", sometimes "new chair(s)", and sometimes "time to
>> shut down the WG as having lost sight of what it is supposed
>> to be doing".    Cases like that may ultimately be the reason
>> we pay you ADs the big bucks.
> 
> I think you've just described TERM, where the charter and
> its document editor are already being micromanaged.

Lloyd,

<rant>
It is probably (almost) a separate issue but as the more time
goes by and the IETF evolves [1], the more I'm convinced that it
was a mistake in the 1990s to conflate our procedures and
mechanisms for handling and defining procedures for the IETF
with those we use to deal with Internet protocol specifications.
That includes the relationship between BCPs about the operation
of the protocols and the Internet with ones about how the IETF
does its work, assumptions about expertise in WGs and maybe even
about how WGs are organized and run, and possibly whether the
same Last Call and approval model are appropriate to both.  And,
of course, the introduction of the IETF Administration LLC into
the works just heightens the distinctions.  

I remember when we created the idea of a "general area".  It was
not intended at the time to be an actual area that would run
multiple WGs, make decisions about AD-sponsored documents, and
compete with technical/engineering WGs in the other areas for
resources.  Instead, it was a quick solution (some would say
"kludge") to quickly get around our sudden realization that the
post-Kobe POISED reorganization had not made provisions for a WG
without an AD.   So now we have a full-fledged Area to add to
the responsibilities of the IETF Chair (as if IETF Chairs don't
already have enough to do) including a mechanism for generating
new WGs.   Better?  Maybe.  But I contend that trying to treat
them as the same has periodically been the source of some
awkward situations and confusion.

But there has never seemed to be any energy to try to sort it
out.  I assume it will have to get even worse before there is.
</rant>

I am not personally convinced, but maybe the nature or TERM and
the decision to run it as if it were a "normal" WG is a symptom
of the problem.

best,
   john


[1] I'd like to say "matures" but that is sometimes not obvious.