Filter by topic and date
Balancing the Process
1 May 2013
One of the most rewarding parts of my job is talking to various IETF contributors or people who rely on our results, and trying to understand their experiences about the IETF process and what kinds of technical topics they expect us to tackle. This article focuses on the process aspects.
![Number of Discusses per document 2004-2010](../../media/images/iesg-telechat-discuss.original_b60JSVI.jpg)
One piece of feedback that I consistently hear is that too much of the IETF process is centered on the later stages and in particular the IESG review. Documents rarely sail through the IETF last call and IESG review unchanged. At least 90% of the documents get revised. Many of these fixes are editorial, but some have technical substance. It is surprising that documents that were expected to be ready as they left the working group need so much revision.
Having been involved in the process for many years, often the bigger changes at this stage relate to cross-area issues, or the fact that the careful reviews from the IETF last call, directorates, and 15 ADs often represents a significant increase in the number of non-WG people looking at the document.
While some of this is natural as the document gains more exposure, it is still painful. Often difficult tradeoffs get re-discussed at this stage, late surprises are discovered, and significant document changes occur. These drawbacks are amplified by our informal processes through which changes are introduced. While we try to keep the working groups in the loop, sometimes the discussion happens directly between authors and reviewers or ADs. The WGs are not always directly informed, and it is rare to conduct formal last calls.
All this results in uncertainty for the progress of documents through the IETF, increases the work load of the IESG, and makes the working groups not be as central to the standards process as they should be. And yet, based on my experience a vast majority of those changes were necessary before the RFCs got published.
But is there a way to improve our process on this aspect? We are discussing some of these issues in an IESG retreat that is coming up next week in Dublin, Ireland. Input on these topics would be valuable. Are these problems real? What suggested methods could be used to reduce their effects? Why are we not doing more cross-area reviewing (by ADs or otherwise) earlier in the process? Please send feedback directly to me or discuss at the mailing list.
Having been involved in the process for many years, often the bigger changes at this stage relate to cross-area issues, or the fact that the careful reviews from the IETF last call, directorates, and 15 ADs often represents a significant increase in the number of non-WG people looking at the document.
While some of this is natural as the document gains more exposure, it is still painful. Often difficult tradeoffs get re-discussed at this stage, late surprises are discovered, and significant document changes occur. These drawbacks are amplified by our informal processes through which changes are introduced. While we try to keep the working groups in the loop, sometimes the discussion happens directly between authors and reviewers or ADs. The WGs are not always directly informed, and it is rare to conduct formal last calls.
All this results in uncertainty for the progress of documents through the IETF, increases the work load of the IESG, and makes the working groups not be as central to the standards process as they should be. And yet, based on my experience a vast majority of those changes were necessary before the RFCs got published.
But is there a way to improve our process on this aspect? We are discussing some of these issues in an IESG retreat that is coming up next week in Dublin, Ireland. Input on these topics would be valuable. Are these problems real? What suggested methods could be used to reduce their effects? Why are we not doing more cross-area reviewing (by ADs or otherwise) earlier in the process? Please send feedback directly to me or discuss at the mailing list.
P.S. In case you were wondering where the graph came from – it is from my IETF statistics page, but unfortunately the IESG measurement parts have not been working well in the last couple of years. I’m working on fixing them, but for this article I had to include an older statistic. Intuitively, current situation is similar to that in 2010.