Re: AD review delays

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 







On Mon, Jun 19, 2023 at 10:59 AM, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote:

On 19/06/2023 12:16, Stewart Bryant wrote:

I am wondering what the consensus of the members of the IETF is on a reasonable time for an AD to take to move a document from publication requested to the next stage in the publication process?

I think the answer is "it depends." When I was on the IESG it probably mostly depended on the length/complexity of a document and what else was going on at the time, so not sure it's possible to calculate to an expected duration for AD review.


[ Replying mid-thread as  this seemed like the best message ] 

There is some code in the DT which displays badges: https://github.com/ietf-tools/datatracker/blob/a6cc12c14b55137023f36b8d50a4149b786293bc/ietf/doc/templatetags/ballot_icon.py#L191

This lists a processing goal for each state (actually there are 2 "goals" - one is used to show an orange "warning" badge when approaching the goal, and a red "danger" badge if the goal is exceeded). These goals were based on the "Publish Path" IESG Wiki page - https://wiki.ietf.org/en/group/iesg/PublishPath - as  this page says, these goals are aspirational. 

Some examples of the badges can be seen on my AD dashboard: https://datatracker.ietf.org/doc/ad/warren.kumari
draft-ietf-dnsop-dns-catalog-zones-09 has an orange badge as it has been sitting the RFC Ed queue for 116 days, and the goal is <120.  In 4 days that will change to red. 

draft-ietf-dnsop-rfc5933-bis has a red badge as it has exceeded it's goal (201). This document is basically dead - its about using GOST in DNSSEC, and so a new document will be progressed through the ISE, and then this one will be updated to reference that. 

Often though, the status and age are simply "wrong" - as an example:
draft-ietf-dnsop-svcb-https has a red badge - it shows as  "Approved-announcement sent" for 64 days (the goal is 7). However, the actual state is RFC Ed (https://www.rfc-editor.org/current_queue.php#draft-ietf-dnsop-svcb-https) - it was returned to the WG to have a change made and then progressed through another IESG Eval, and this is an unusual enough occurrence that we don't handle "Put it back into the RFC Ed queue again". 

Some of this is the working style of the AD - as an example, I almost never use the "AD Eval" state, and instead just jump from "Publication Requested" into "IETF LC".  This is because my workflow involves syncing my queue to my iPad, reviewing and annotating documents on it, and then copying those annotations into email. This means that I just email my review to the authors (and usually the WG) and so they know that the document is being / has been reviewed (see [0] as an example). This does mess up stats, but saves a fair bit of mechanical clickin'. If I cannot get to a review for a while, or if I'm waiting on the authors for a long time (a few weeks)  I'll update the state to reflect this. 

In many cases, though the "exceeds" warning triggers because the AD is waiting on authors — as an example, I had a document last which has some (easy to address) DISCUSS positions, but I was unable to reach the authors. After 10+ emails (and a phone call), we asked the WG if anyone else would take it on - after getting no volunteers I had to mark it dead — however, it sat in "IESG Evaluation::Revised I-D Needed" for 224 days, with a big read mark lurking at me….  

W
[0]:
https://datatracker.ietf.org/doc/rfc9364/history/ went directly from:
2022-09-09 - 03 Tim Wicinski IESG process started in state Publication Requested
to
2022-09-20 - 03 Warren Kumari IESG state changed to Last Call Requested from Publication Requested


I guess historical data might produce a bell curve but not sure that data's easily assembled without a lot of datatracker foo. (In case people don't know, a lot of the current details for this are fairly transparent. [1])

I'd hope that someone unhappy with an AD's progress doing AD evaluation would let the rest of the IESG know about that as they're best placed to either pressure a slow AD or to offer help to an overloaded AD.


Cheers,
S.


[1] https://datatracker.ietf.org/doc/ad





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux