Re: AD workload [was Re: NomCom 2019 Call for Community Feedback]

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 08 November 2019 21:30 UTC

Return-Path: <mcr@sandelman.ca>
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 B47DE1200E0 for <ietf@ietfa.amsl.com>; Fri, 8 Nov 2019 13:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.435
X-Spam-Level: *
X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 L6SmD2QVj3ou for <ietf@ietfa.amsl.com>; Fri, 8 Nov 2019 13:30:25 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D33120025 for <ietf@ietf.org>; Fri, 8 Nov 2019 13:30:25 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [142.169.78.6]) by relay.sandelman.ca (Postfix) with ESMTPS id 960E51F452 for <ietf@ietf.org>; Fri, 8 Nov 2019 21:30:23 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 473351237; Fri, 8 Nov 2019 16:30:23 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ietf@ietf.org
Subject: Re: AD workload [was Re: NomCom 2019 Call for Community Feedback]
In-reply-to: <183c2ca1-aa5e-6aa8-5f7f-bf99967518ee@network-heretics.com>
References: <157279399807.13506.13363770981495597049.idtracker@ietfa.amsl.com> <0EF64763-BA25-468A-B387-91445A61D318@gmail.com> <CAJU8_nUovmFmgNiYx0ez_1f+GPdU9xGViDYWfowEEomrn0pyDw@mail.gmail.com> <alpine.LRH.2.21.1911040841160.27600@bofh.nohats.ca> <CE06CC6D-E37F-4C90-B782-D14B1D715D4B@cable.comcast.com> <38E47448-63B4-4A5D-8A9D-3AB890EBDDDD@akamai.com> <09886edb-4302-b309-9eaa-f016c4487128@gmail.com> <0053C5D9-E4D7-4BE0-9B73-3B7FC25561FB@akamai.com> <f0069562-5b4b-3a08-124f-1a8d24dfd0cd@cs.tcd.ie> <e7ebf607-cbf8-8ebf-9dca-0aec96ff517d@gmail.com> <20191105092422.GA61969@kduck.mit.edu> <ca7a87c8-d841-c13c-3131-aa44acac226f@gmail.com> <C6AA7609-A36F-41A5-83A3-960ED7330211@cisco.com> <B788C8DF-9660-4041-9E9A-567F0B104B5A@employees.org> <7740e21f-83b1-ef83-965a-c599a0746ae3@network-heretics.com> <70ce65fb-6856-4c6e-7730-1bccaa842c05@gmail.com> <183c2ca1-aa5e-6aa8-5f7f-bf99967518ee@network-heretics.com>
Comments: In-reply-to Keith Moore <moore@network-heretics.com> message dated "Fri, 08 Nov 2019 14:34:09 -0500."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 08 Nov 2019 16:30:23 -0500
Message-ID: <23353.1573248623@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Cw73r5I4nHw1QWihdkI7TU-DErE>
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: Fri, 08 Nov 2019 21:30:28 -0000

Keith Moore <moore@network-heretics.com> wrote:
    >> And again - this is all procedural, no change to IETF rules is
    >> needed. I begin to realise that the IESG's workload is in its own
    >> hands, and we (all of us who've served in the IESG over the last 20
    >> years) have to share the blame for current practice.

    > Something I realized long ago is that IETF community expectations are
    > at least as influential as the rules, probably moreso.

    > As long as the community expects that any working group that has
    > support will be approved, that working groups can stay alive as long as
    > they keep producing documents, and that any document that a working

I'd really like them to stay alive while not producing (new) documents.
So I feel that groups sometimes are eager to recharter because that is the
only way to stay alive.  I'd like to change that.

    > And every time someone points out that IESG is overloaded, most of the
    > proposed "solutions" seem to have the intent, or at least effect, of
    > further reducing document quality.

But, the bar is already very very high.

    > Maybe it's just me, but I keep thinking that the best way for IETF to
    > serve the Internet is to produce fewer documents of higher quality and
    > greater relevance.

Fewer RFCs, I agree.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [