ietf
[Top] [All Lists]

Re: call for ideas: tail-heavy IETF process

2013-05-14 08:58:55

Few thoughts. 

1) don't get wrapped around the axel of STD, PS, Foo bar label, it has nothing 
to do with the problem that that IESG believes many drafts need changes to fix 
significant problems. Lots of people imply that the IESG is setting the bar too 
high but when you look at the changes that are made to drafts from point they 
go in, to point they come out of IESG it seems to be a rare example where 
people don't agree that major changes were an improvement and needed.  

2) On the point of what the IESG should be doing, I would like to see the whole 
IESG say they agree with the Discuss Criteria document and will stay within 
that (or change it if they disagree). The cross area review teams might want to 
also provide comments within this context. 

3) Require each pub request  from a WG to come with names of 3 nom com eligible 
people that are willing to say "I have carefully reviewed this draft and I 
believe it is ready to be published as an RFC". If a WG can't find 3 people to 
do this, it should probably be closed. You might consider something similar for 
AD sponsored drafts but I am more interested in the WG ones. 

4) Get the ADs involved earlier. My experience is that many ADs won't say much 
because they are worried that they would be over influencing the WG. ADs got 
the job because we think they are the right people to provide influence and 
obviously it would be better to get that early rather than late. 

5) Given how long a WG takes, I have no problem with time IESG / RFCEd takes. I 
would suggest mitigating this concern by clearly telling the community that if 
there were a spec that truly needed to be fast tracked for some real reason, 
you would make it priority. And on the rare occasion that is needed, do it and 
track the stats for fast track separately. I would guess that less than 1 in 
100 needs this and you could do theses with delays in the small numbers of 
weeks instead of months. How fast you can move when really needed is more 
important to me than the average and I know that the IESG/IANA/RFCEd team works 
well in parallel and can move fast when needed. 

6) Over the long term, set up the tools to separately track IESG / RFCEd time 
where the ball is in the authors court. 

7) Remember that in the end, the goal is not a standard. The goal is an feature 
rich interopeable internet that is a fertile ground for inovation. High quality 
and relevant standards that think about the future are the way to get there. 
The goal is not to publish lots of specification that aren't used and don't 
work. 

Cullen


On May 1, 2013, at 9:33 AM, Jari Arkko <jari(_dot_)arkko(_at_)piuha(_dot_)net> 
wrote:

I wrote a blog article about how we do a fairly significant amount of reviews 
and changes in the late stages of the IETF process. Next week the IESG will 
be having a retreat in Dublin, Ireland. As we brought this topic to our 
agenda, Pete and I wanted to raise the issue here and call for feedback & 
ideas for improving the situation with all of you.

http://www.ietf.org/blog/2013/05/balancing-the-process/

Jari