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

Keith Moore <> Fri, 08 November 2019 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 033371208EF for <>; Fri, 8 Nov 2019 08:25:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NONE=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 OoeBeR4xNany for <>; Fri, 8 Nov 2019 08:25:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11E5612089E for <>; Fri, 8 Nov 2019 08:25:56 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 47162210B8; Fri, 8 Nov 2019 11:25:54 -0500 (EST)
Received: from mailfrontend2 ([]) by compute6.internal (MEProxy); Fri, 08 Nov 2019 11:25:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=xa51HLn+jGfXeM4D5D5vwBscJLKUoBBYKb/rXwBel Qw=; b=kP2XdEar+7lu0l6JZtfI3gVkAQ9Fej49xRf57WGU5lj1vOgAT8BfRjMXa KmPm5+BDN99s2rZMiCtGGkemE/IjDXC5zfu9Em1NeVaQWes+GPVcsd+96sCMqsBO Wl1Sl3VsBvvq85xf5C6+T3CQdVihIn+m4j3Vrh14goMcR7Bq5kiB1Lm11LZ5lOCc Ld7qpRHQXYvoahMDCDl5dYZ2o4+O398isXHh8IFhxcLQdRk6tyv3FBqWSbMjcSc9 TJqdRq6qP4EjECTd/VPDpFHmA/+bBOKEHbgLBFJPpAZB9saRAPJPG7nvxqh9OnAV aIjA2t1+qMCi3rDB7/XPaxn/V9B6w==
X-ME-Sender: <xms:EZfFXR0Boaysg5sY-If8nAfGwV-IwmNQcfyFbVVoa5TLtUj-fo-WrA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddvuddgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucfkphepuddtkedrvddvuddrudektddrud ehnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghr vghtihgtshdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:EZfFXTR7ZOT-HbGVVbNL7dsGOPi4hNJOq6mH4aZ_EGjH14FgzbyyAg> <xmx:EZfFXRCIf0VvZVKlUskbcph0WgfpVsRssZiCSIG_XJoayV29h48N6g> <xmx:EZfFXfEM40fx4vpjrK_-b-lPaL6QG0UUcs53vaxF2M2EeBUUygohFQ> <xmx:EpfFXaUU8fLAMX2b6GtwO540rGLbtfUDLDsjOVWAFSrmVm8w28W8Jg>
Received: from [] ( []) by (Postfix) with ESMTPA id 1FC12306005E; Fri, 8 Nov 2019 11:25:53 -0500 (EST)
Subject: Re: AD workload [was Re: NomCom 2019 Call for Community Feedback]
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Keith Moore <>
Message-ID: <>
Date: Fri, 8 Nov 2019 11:25:52 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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: Fri, 08 Nov 2019 16:26:02 -0000

On 11/8/19 4:49 AM, Ole Troan wrote:
> I have for a long time been uncomfortable with the level of document changes that happens after the document leaves the working group.
>  From my perspective I would have preferred a document process, where the working group "owned" the document until publication.
> For cross-area issues:
> The responsible AD together with the chairs should identify cross-area conflicts and need for collboration earlier in the process. And as chairs/responsible ADs escalate cross area issues, those should be discussed in the IESG while document is in the working group.

That's too few people, IMO.   Also there's a tendency to call them 
"cross-area issues" but I think that can be misleading. What I have seen 
time and time again was that a WG or document author would make 
decisions that would, for example, harm the ability of the Internet to 
support a certain kind of application.   But even a typical Applications 
AD wouldn't necessarily realize that, because "applications" is 
tremendously broad.   (These days the ART area is even broader.)

I see no substitute for a community-wide review.   A message is sent to 
an appropriate list (maybe lastcall, maybe not) that summarize the WG's 
charter and list each of the documents being worked on and describes how 
they fit into that charter.   The message states that the chairs and 
IESG are interested in knowing whether these solutions harm other 
interests, and more generally solicit community feedback on the approach 
(keeping in mind that Z1 and Z2 are probably not finished yet), and 
there's a special email address for the feedback that must be used.     
Either make those solicitations for review explicitly part of a WG's 
schedule, or automatically trigger them at one year intervals after a 
group has started.   The WG chairs would have the responsibility of 
writing those descriptions, any responses would be recorded and made 
publicly available, the WG chair would summarize the responses for the 
IESG, and the WG is expected to respond to substantive feedback.

> If a document isn't good enough, the IESG should send it back to the working group. Not try to "fix" it themselves (often in a small group between chairs, authors and ADs).
Agree with the latter part.   IESG is in a poor position to "fix" a 
document, especially so late in the process, though the same is true of 
a WG that has labored years to produce something before even being aware 
of potential harm that they're doing.   That's why the reviews need to 
be done well before a group thinks the document is complete.
> Basically I want the IESG for leadership. I want the IESG for quality control. I do not want the IESG to have to read every document, nitpick or even (gasp) override working group consensus.
Mostly agree, though I don't see how the IESG can provide meaningful 
quality control without each AD at least skimming the documents that are 
relevant to that AD's area.     But I have always thought that the IESG 
and other reviewers should point out the problems and the WG should 
figure out how to fix them.   But they need that feedback as early as 
possible so they can take that input into account when making their 
compromises.    "Last Call" and IESG review should be stopgap measures, 
not the only means by which a WG gets feedback from other parties.  Most 
of the time final IESG review should be more of a process review than a 
technical review.    But part of that process review should consider how 
the document addressed external feedback.