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
- [Gendispatch] FW: New Version Notification for dr… Salz, Rich
- Re: [Gendispatch] New Version Notification for dr… Greg Skinner
- Re: [Gendispatch] New Version Notification for dr… Brian E Carpenter
- Re: [Gendispatch] FW: New Version Notification fo… Eric Rescorla
- Re: [Gendispatch] FW: New Version Notification fo… Adrian Farrel
- Re: [Gendispatch] FW: New Version Notification fo… Salz, Rich
- Re: [Gendispatch] FW: New Version Notification fo… Eric Rescorla
- Re: [Gendispatch] FW: New Version Notification fo… Salz, Rich
- Re: [Gendispatch] FW: New Version Notification fo… Eric Rescorla
- Re: [Gendispatch] FW: New Version Notification fo… Salz, Rich
- Re: [Gendispatch] FW: New Version Notification fo… Eric Rescorla
- Re: [Gendispatch] FW: New Version Notification fo… Brian E Carpenter
- Re: [Gendispatch] FW: New Version Notification fo… Rob Sayre
- Re: [Gendispatch] FW: New Version Notification fo… Adrian Farrel