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
