Christian, > On Nov 7, 2019, at 10:21 PM, Christian Huitema <huitema@xxxxxxxxxxx> wrote: > > > On 11/7/2019 11:44 AM, Nico Williams wrote: >> Yes. That includes faster RFC-Editor turnarounds. If we remove the >> other bottlenecs, then RFC-Editor queue time will become the next >> bottleneck to address. > > That's not what the numbers say. I took a hard look at the delays in > https://tools.ietf.org/html/draft-huitema-rfc-eval-project-01, and the > RFC Editor queue time is by no means the largest part of the delay from > 1st draft to RFC publication. The RFC Edition delay proper is about 2 > months on average, plus about 1 month on average for the Auth48 period. > The edition delay does not vary much, but the Auth48 delay varies a lot, > and the main reason for this variability is the responsiveness of the > authors. > > In the path from 1st draft to RFC, the bulk of the delays happen in the > working group. In my sample set, the average delay from start to finish > is 3 years and 3 months, of which on average 2 years and 8 months are > spent getting consensus in the working group. That’s matches my experience as well. Also, one of the significant causes for long delays in the RFC Editor queue is mis refs. That is, when it has normative references to drafts that are not yet approved. This can add considerable delay and can’t be speeded up by the RFC Editor. Bob
Attachment:
signature.asc
Description: Message signed with OpenPGP
