Re: [Gendispatch] FW: New Version Notification for draft-rsalz-less-ad-work-00.txt

Adrian Farrel <adrian@olddog.co.uk> Tue, 25 July 2023 23:04 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: gendispatch@ietfa.amsl.com
Delivered-To: gendispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0C7C151089; Tue, 25 Jul 2023 16:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.794
X-Spam-Level:
X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp0gRzslaybt; Tue, 25 Jul 2023 16:04:34 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 A7F37C14CEFE; Tue, 25 Jul 2023 16:04:33 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.7/8.14.7) with ESMTP id 36PN4Vh9029189; Wed, 26 Jul 2023 00:04:31 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E167046055; Wed, 26 Jul 2023 00:04:30 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C1F5D46054; Wed, 26 Jul 2023 00:04:30 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS; Wed, 26 Jul 2023 00:04:30 +0100 (BST)
Received: from LAPTOPK7AS653V (dhcp-8983.meeting.ietf.org [31.133.137.131]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 36PN4SCn024220 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Jul 2023 00:04:29 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Eric Rescorla' <ekr@rtfm.com>, "'Salz, Rich'" <rsalz=40akamai.com@dmarc.ietf.org>
Cc: gendispatch@ietf.org
References: <168744432974.12836.15546856939515664242@ietfa.amsl.com> <AB2CDCEA-1A18-40BB-82A8-BCFD66EBB0CB@akamai.com> <CABcZeBO0gtE0Dd3_F=EciRXaZgFdyMiyfKKZ++YK8ZVCJLQDoQ@mail.gmail.com>
In-Reply-To: <CABcZeBO0gtE0Dd3_F=EciRXaZgFdyMiyfKKZ++YK8ZVCJLQDoQ@mail.gmail.com>
Date: Wed, 26 Jul 2023 00:04:28 +0100
Organization: Old Dog Consulting
Message-ID: <04e401d9bf4c$5e380690$1aa813b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_04E5_01D9BF54.BFFDA710"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIpc6AtQ1V8za3T+PFNG1sYQFrR1AGJ88OcAq9/K8OvCePm4A==
Content-Language: en-gb
X-Originating-IP: 31.133.137.131
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=si0UCiYkipfDZPatWpHME kTTle4Zp5mfVMZtIkjS9xk=; b=o8D35X9xZl7JRPoTTQO8wJP2/rXwhyWIG4TJF rRXV9YLRifdEiIwg+GoT+doeYf5K5XvFTGIya/KrSgVc8yAFKejG2eLNkUeUvGXz rGLs0fwqC9VtbUMLW4U9Xh1UMWv9aQse3T0vqRiZmOVOf/aPOFevYGJgSATbHdsx 5zjxUJJ9ZPYrVM3BdXw13ZheiiCACISCif5a5cjVAv3sm0i8RkQArcvlSz+82N9Q FzK2liJPh2XVa8mcZgUkOwtdroo+sjOYykElMHWcTv0jbYje/+dYvjoDcNV+88Fo pzzO0olyF8upgL1IdJx0jjC9WnRnl0IYnpyHzjDab2NA/eMXg==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27774.003
X-TM-AS-Result: No--36.475-10.0-31-10
X-imss-scan-details: No--36.475-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27774.003
X-TMASE-Result: 10--36.475100-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFrH1DfC+QNQxHFPUrVDm6jtkYC3rjkUXRK1Cm0vpf9YEpAj zBs6pqF7Rf7ZyHEj6tmJOSHLlkfNg2UP7aNI5GbmQ0Xm0pWWLkrKrKWVfpQki9RGf5c57+FFkrI 9/WPu3jenceLJy5PCoOmLngfcWjsR7MyGpGeeTJV/XQUH972sKr5wB7kIR7PzdcfU63y8xPD7Td r4xDxETUUWuNOlf2MMbs370Ri/vYAuZsLnCTwqVRfqkKQlk1I5UTBIPA569SGcLgQI+sLoSBikw 8i4WW9MS0b45Tfj4cj841VjTkoUHNyaVNVkynHDlTsGW3DmpUt4ssIDQ8PtqBbM9NvE7tH6Uqwy LcsUF9rTKAsTBuEvRb2R+6NgaFeG+RKVIcWA1UUoMe1VlAoAA6n/3nyhTdZwvBi1vSDtjC20voo vfqj1wkZA4LsIYX43FUGiMcidh6NcO5BB7MCAVfQxpA7auLwMaZATGA5/BXgtferJ/d7Ab17nN5 dEttkXIUIDik5QPJ5f4cur8LkD6Tp/m5fBYCsGD+u3ecmItPgEx2nnXvzNIy3euai/vqCsLqCWi FTFXm0KoiVTDA+B7N7e5jA6jfal139pJSwZBCWuYt4ytygzqD2ztEtrFmitebU/xPBdG2K0ibUq PtLyGi1BmHDwxO4ckjrT4dFmkw6NLR8uNPpW8Z1U1lojafr/xMZq+YajS9b7s8CQBJM67nb43pu A25sA25UN5flt2+2mVTuoQyrAQptgia0XDY8T4nbwqqmOd2khacrY8HfDlZ+9KccEt4Mq82nPLN zghGvvRWVG2VJhQDFPR7iDvfrqSKClVPLEejtANB89sV0bJ30tCKdnhB58r10pknZXGJqy5/tFZ u9S3F8QNb97+sTgvECLuM+h4RB+3BndfXUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/xjJlCfM5dsoMm5HMapytuWydYnQ>
Subject: Re: [Gendispatch] FW: New Version Notification for draft-rsalz-less-ad-work-00.txt
X-BeenThere: gendispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: General Area Dispatch <gendispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch/>
List-Post: <mailto:gendispatch@ietf.org>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jul 2023 23:04:38 -0000

Thanks Eric,

 

Yes, I think we acted as enthusiastic IETF engineers, and went straight to flying solution kites (although, as Rich said, he got poked previously for not suggesting solutions), and I’m a bit ashamed at that.

 

First we need problem definition and outcome objectives, both scoped by metrics.

 

It is even possible that, in watching the development of the definition and outcomes, the IESG will simply self-organise out of the issue and we can all get on with real work.

 

Anecdote (yes, I heard Alissa): when on the IESG I tried to get the ADs to each record how they were spending their time. I failed. I should, perhaps, have provided tooling to help them – I was, perhaps, startled to discover that I was the only person diligent^H^H^H^H anal enough to be already recording my time across tasks in 15 minute intervals.

 

A

 

From: Gendispatch <gendispatch-bounces@ietf.org> On Behalf Of Eric Rescorla
Sent: 25 July 2023 23:41
To: Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>
Cc: gendispatch@ietf.org
Subject: Re: [Gendispatch] FW: New Version Notification for draft-rsalz-less-ad-work-00.txt

 

Rich, Adrian,

Thanks for sending this. I generally agree that the AD job
involves too much work [0].

You present an array of different proposed solutions, but
I would instead start with the diagnosis of what consumes
time. At a high level, ADs and the IESG collectively have
three main responsibilities:

1. Managing their own WGs and reviewing WG drafts
2. Reviewing drafts from other WGs in IESG review
3. The administrative tasks you mention in S 5.3.

Any attempt at solutioneering here should start with an analysis of
where the time goes. While I didn't keep detailed records of my time
allocation for when I was AD but I would estimate that the majority of
my time was spent on (2), then (1), then (3) as a distant third,
except at IETF. From conversations with other ADs my sense is that
their ranking would be similar.

I don't think that (1) is really *that* reducible: in our current
structure ADs are responsible for the work of their WGs, so they
really do need to review that for acceptability. This mostly leaves us
with (2), which you address in S 5.1, 5.2, and 5.4. My sense is that
5.2 (no "revisit" douments) and 5.4 (content not language) are not
really that big contributors to IESG load.

IMO the big contributor is the assumption that the IESG is
collectively responsible for the document quality of IETF documents,
and therefore ADs feel that they need to review documents, and even
"no objection" means "I read this and it's OK" as opposed to "I just
didn't look". This is exacerbated by the fact the AD for area
A isn't substitutable for the AD for area B, so it's not like
you can just have a panel of ADs drawn out of the IESG (as US
appeals courts do). Moreover, a number of areas actually have
internal divisions of labor, so, for instance, if SEC has one
AD that has a COMSEC background and the other with an OPSEC
background, those expertises aren't substitutable.

I do, however, think that this points the way towards a solution,
though perhaps one different from what you suggest in 5.1, which
is that ADs should be reviewing not for generic quality but
rather from the perspective of their own areas. If you are the
AD for area X, you should be reviewing:

- Primarily for issues that affect your area.
- For issues that have a risk of real harm to the Internet

To take the example of security, you would review the document for
security issues and mostly ignore non security relevant content (of
which there is generally quite a bit [1]), and would also be cautious
about raising design issues that are non-serious but could perhaps
have been done better.

I do think that ADs need to be able to object to documents
which they think would seriously harm the Internet even if
they are outside their area. However, the attitude shift I
am talking about here is that they should not feel the need
to scrutinize every document to be absolutely sure it does
not contain such an issue.

My larger point here is that the problem here is community
expectations--or at least the IESG's sense of what those expectations
are--about the IESG's level of responsibility for document
quality. I think this ties into mnot's proposed DISCUSS criteria
document, which is about setting some of those expectations.

-Ekr

[0] Though IMO the vibe that it's so hard that it takes
two years to find your feet is a bit over the top.

[1] I've heard people argue that security is especially bad because
security review is so cross-cutting, but in my experience it's still
the case that there is much you could ignore.

 

On Thu, Jun 22, 2023 at 7:36 AM Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org <mailto:40akamai.com@dmarc.ietf.org> > wrote:

We would like to present this for dispatching at the next IETF.

On 6/22/23, 10:34 AM, "internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>  <mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> >" <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>  <mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> >> wrote:




A new version of I-D, draft-rsalz-less-ad-work-00.txt
has been successfully submitted by Rich Salz and posted to the
IETF repository.


Name: draft-rsalz-less-ad-work
Revision: 00
Title: Making Less Work for Area Directors
Document date: 2023-06-22
Group: Individual Submission
Pages: 8
URL: https://www.ietf.org/archive/id/draft-rsalz-less-ad-work-00.txt 
Status: https://datatracker.ietf.org/doc/draft-rsalz-less-ad-work/ 
Html: https://www.ietf.org/archive/id/draft-rsalz-less-ad-work-00.html 
Htmlized: https://datatracker.ietf.org/doc/html/draft-rsalz-less-ad-work 

Abstract:
Anecdotally, every IESG complains about the Area Director (AD)
workload, and says that it takes the first full term to understand
the job. Empirically, the AD workload is high sometimes causing
backlogs in processing of Internet-Drafts and stressing the ADs.


Empirically, the AD workload is high sometimes causing backlogs in
processing of Internet-Drafts and stressing the ADs. This is
evidenced by the limits applied to the number of pages on the regular
IESG telechats, and by the number of documents waiting in excess of
fifty days for initial AD review after a working group has requested
publication.


This document proposes a number of ways that the AD workload can be
reduced. It will be up to the IETF consensus process to determine
which proposals to adopt.


A major goal of this effort is to make it feasible for a wider
diversity of people to volunteer as candidates for AD possitions by
reducing the barriers and costs to individuals and their employers.

-- 
Gendispatch mailing list
Gendispatch@ietf.org <mailto:Gendispatch@ietf.org> 
https://www.ietf.org/mailman/listinfo/gendispatch