Re: AD review delays

[Warren Kumari <[e-mail]>]

On Mon, Jun 26, 2023 at 8:24 PM, Dave Taht <[e-mail]> wrote:

> RFC8289 and RFC8290 sat in queue for 2 years. To resolve that problem we
> (The authors) sent the responsible person:
>
> Cookies
> A wrist supporter
> Bungie Cords
>
> It worked.
>

So, I'm trying to understand where this went so wrong.
I note that you said "the responsible person" and not "the responsible AD",
and I'm trying to understand if that is intentional.

Looking at RFC8290, it looks like:
2016-02-14 - IESG process started in state Publication Requested
2016-02-28 - IESG state changed to AD Evaluation from Publication Requested
2016-03-01 - IESG state changed to AD Evaluation::Revised I-D Needed from
AD Evaluation
2016-03-03 - IESG state changed to Last Call Requested from AD
Evaluation::AD Followup
[18 days from Publication Requested to IETF LC]

2016-03-17 - IESG state changed to Waiting for AD Go-Ahead from In Last Call
2016-03-17 - IESG state changed to Approved-announcement to be sent::Point
Raised - writeup needed from IESG Evaluation
[ 14 days from end of IETF LC to Approved, Point Raised. ]

2016-04-03 - IESG state changed to Approved-announcement to be sent.
[ 17 days from Point Raised until approved. This included waiting for the
SecDir review to time out ]
[ Total from PubReq to Approved: 49 days. This includes 4 weeks of IETF LC
]
It then spent 2 years, 7 months stuck in MISSREF state, probably waiting on
8289? It looks like RFC8289 only entered PubReq on 2016-11-01, 229 days
later.


So, looking at RFC8289:
2016-11-01 - IESG process started in state Publication Requested
2016-12-22 - New version available: draft-ietf-aqm-codel-06.txt
2017-03-12 - New version available: draft-ietf-aqm-codel-07.txt
2017-03-13 - IESG state changed to Last Call Requested from Publication
Requested
[132 days from PubReq to IETF LC — but the document had 2 new version
posted during this time, presumably because the AD review requested some
changes. ]

2017-03-13 - IESG state changed to In Last Call from Last Call Requested
2017-04-13 - IESG state changed to Approved-announcement to be
sent::Revised I-D Needed
[ 30 from IETF LC till Approved, revised ID needed ]

2017-09-11 - New version available: draft-ietf-aqm-codel-08.txt.
2017-09-29 - New version available: draft-ietf-aqm-codel-09.txt
2017-10-13  - New version available: draft-ietf-aqm-codel-10.txt
[  days from the IETF LC version (07) to the approved version (10) ]

2017-10-16 - IESG state changed to Approved-announcement sent
[ 3 days from new version to Approved ]

2017-12-13 - RFC Editor state changed to AUTH48 from RFC-EDITOR
[ 58 days from Approved to AUTH48 ]

2018-01-04 - RFC Editor state changed to AUTH48-DONE
[ 22 days in AUTH48 ]
[ Total from PubReq to Approved: 339 ]

>From this (very imperfect) archeology, it looks like the document spent
much of this 339 days waiting on new versions (132 days from PubReq to IETF
LC + 183 days from Approved-announcement to be sent::Revised I-D Needed to
the Approved version = 315).

Now, I have no idea (and cannot be bothered to go read the list :-P ) in
whose court the ball spent all of that time, but it doesn't really look
like the AD was the long pole in the tent here.

Yes, 735 days is a ridiculously long time from when draft-ietf-aqm-fq-codel
entered the sausage making machine until it emerged as an RFC… but 229 days
of that seem to be because it was normatively referencing another document
which hadn't entered the IESG, and then another ~300 days seem to have been
waiting on authors of that referenced document….

W


> On Mon, Jun 19, 2023 at 1:03 PM Adrian Farrel <[e-mail]>
> wrote:
>
> Stephen 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. 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.
>
> [1] https://datatracker.ietf.org/doc/ad
>
> Surely the first step is to talk to the AD.
> Setting expectations (in both directions) and communicating changes is a
> good first step.
>
> Further, I think the page that Stewart cited is enough of an indication to
> the rest of the IESG of where the problem lie, so the IESG can easily tell
> where to offer help.
>
> I know that some ADs have a backlog and are working to clear it. These are
> not the size of queues that can be fixed instantly.
>
> However, when we talk about documents regularly being held up for more
> than 100 days without any progress, I think it is time to start fixing
> something. It isn't reasonable to add such a long wait into the cycle.
>
> Cheers,
> Adrian
>
> --
> Podcast: https://www.linkedin.com/feed/update/
> urn:li:activity:7058793910227111937/ Dave Täht CSO, LibreQos
>