Re: The IETF, Standards process, and the impact on the RFC series document production

[Christian Huitema <[e-mail]>]

On 10/4/2019 9:11 AM, Michael StJohns wrote:
> Hi Christian - I thought I'd dive down into some of your specific
> comments on the standardization process.  Subject changed appropriately.
>
> On 10/4/2019 3:51 AM, Christian Huitema wrote:
>>
>> At the same time, there is a tension between the tradition and the need
>> to serve and recruit a wider community. Our document production time is
>> counted in years, and that does not help convincing open source projects
>> to work with us.
>
> To be clear, it's not (only?) the actual document production that
> takes time, but the authoring, and then getting through WG, then
> various twiddles by the IESG, and then finally IETF last call, all
> before it ever gets to the RFC editor for publication.

Yes indeed. I am trying to measure that in
https://datatracker.ietf.org/doc/draft-huitema-rfc-eval-project/.
According to my measurements, the average RFC published in 2018 took 3
years and a half from start of the individual draft to publication. Out
of this, three years were spent in the working group, three months spent
gathering IETF consensus through IETF last call and IESG review, and
three months spent in the publication phase. So it is pretty clear that
if we want shorter cycles the place to look first is the working group
process.

The RSOC and the RSE do care about the time spent in RFC edition, but
this is more a concern with the overall cost of processing than with the
delay impact. Issues such as clustering of RFC cause spikes in load and
delay, and it would be nice if we could make this part of the process
smoother. But overall, functions like copy editing do bring value to the
process and are only a minimal part of the "end to end" delay.

>
> A while back I managed to move RFC5011 from Proposed to Standard
> without a document action.  From Last Call to the announcement of the
> standards action was about 6 months.   Let me repeat that - 6 months. 
> And there were no RFC editor actions AFAICT.   I think it was most of
> a year from the time I requested the upgrade until it was done.

My little study shows that the current end-to-end delay are basically
unchanged from 10 years ago, but are about twice longer than they were
20 years ago. I believe this is due to changes in process occurring
close to year 2000, but I have not investigated which changes caused what.

For software releases, I have observed that long production cycles have
a self-perpetuating effect. If you arrange a large product in a cycle of
"big releases", then multiple participants will try to jam their
preferred feature in the release. They fear that if they miss this
release, it will take years before the next release and that their
customers will not get the desired feature for that long. But when
contributors do that, they increase the complexity of the current
release, which tends to increase production delays. I wonder the same
kind of dynamics are at play in the IETF, with participants trying hard
to get their preferred option in a big standard and thus causing
discussions to last longer.

For software products, the classic cure is to switch from big releases
defined by big features to periodic releases that ship all the features
ready at a given time. The equivalent in the IETF would be to have
periodic publications such as "here is the interoperable version of
protocol FOO as of December 2019". The "living document" effort seems to
me like a step in that direction.

-- Christian Huitema