ietf
[Top] [All Lists]

RE: call for ideas: tail-heavy IETF process

2013-05-03 14:06:12
Pete Resnick wrote:
Not disagreeing with your message, but a couple of clarifying points:

On 5/3/13 12:41 PM, Tony Hain wrote:

I would agree with you that weighting longer term is the 'right
thing', but given that people wait for an RFC number to implement, and
then take the position that RFC (PS) == STD, you never get to the
longer term because the bar is set so high on the first hurdle that it
becomes impossible for people to justify the effort to go for the next
one.


When Thomas said "longer-term", I took him to mean *all* of the things
that
are longer time horizon, like management/mentoring of WGs and chairs,
doing more early cross-area participation (including by ADs) in the design
of
and work on protocols (not just review), etc. In particular, I didn't
understand
him to mean longer-term as having anything to do with advancement on the
standards track. I think the above longer-term goals are important. I
think
movement along the standards track will be the outcome if we get to
working well, but not a goal in-and-of itself.

I actually view all of the housekeeping activities as short term. Thomas
will have to state what he meant.


In any case I don't see 60/40 as a tail-heavy process. If the WG time
were cut in half and the IESG/RFC-editor time stayed the same, maybe
it would be tail-heavy, but realistically more 'balanced'.


I'll point you to Jari's excellent reminder that "time" is probably the
least of
the heaviness on the tail end. What is tail heavy is the work
investment: We do WG last call reviews, IETF-wide Last Call reviews,
directorate reviews, IESG reviews, all at the end of the process. We spend
scant little energy (of the wider IETF community and leadership) on early
design reviews and protocol development early and in the middle of the
document process. As Jari said, that model ends us up with late surprises,
lack of transparency, etc., and probably uses much more energy overall
than
if we invested it earlier in the process. Sure, this can translate to
delays, but
that's only one (maybe minor) effect of being tail-heavy.

While I agree that it would appear to be a heavy workload, that is just
because it is concentrated enough to see. If you actually did all the work
across all the participants to review every document at every iteration,
nothing would get done. Even when the IETF was ~60 people creating a few
documents a year, reviews happened late, and changes were made. Yes earlier
comments from outside the WG will reduce overall surprise and workload, but
finding the right reviewers is tricky.

One could require that every BOF be presented to every Open Area meeting,
then required public comment from every other AD before being allowed to
form a WG. This would front load the review and raise general awareness
about what is being discussed. Unfortunately since that event and resulting
documents are half a decade apart, potential reviewers have long since
forgotten any concerns they might have had, and need to start fresh anyway.
For long standing WGs one could consider doing the same at every charter
change, but again, document movement within the WG needs to be faster for
any of that to matter. 

The only way I can see to reduce the time from BOF to RFC is to reduce the
public expectation on the quality of that initial document which will get
wide review and initial implementation.  We should be talking about ~ 3
years to get to STD, not the initial draft that gets review beyond the WG.
In practice what we have today is functionally STD at initial publication,
so there is a very concentrated effort at one point in time. If the process
to get from WG I-D to initial RFC was basically a sanity-check, the detailed
IESG and cross-area review could be spread out during implementation prior
to the update that removed the DRAFT: status. Realistically though, human
nature would take over and nothing would happen until the WG tried to take
that step and we would be having the same discussion about tail work load. 

Bottom line, we need a signal to other areas that a WG document is ready for
serious in depth review, and a document title change seems to be what people
are looking for. At the same time WGs need to do a better job of spreading
awareness earlier in the process to get comments from those that have
different perspectives, then actually listen to them during document
development. Surprise comes from being isolated, and/or shouting down voices
that later come back during review to highlight flaws. If the process to get
to DRAFT: status was less burdensome, documents would move more quickly and
less effort would have gone into the flawed document before it got seriously
reviewed. 

Tony



<Prev in Thread] Current Thread [Next in Thread>