Re: FW: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC with Running Code) to Experimental RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I do not really have time or desire to enter an extended discussion on
this document. It's pretty clear to me we just disagree. But I did
want to be on record as not supporting this document so that silence
wouldn't be taken as agreement or support.

A few specific followups below.

> > This document seems to have a bit of missing the forest for the
> > trees. In the overall scheme of things, I don't believe the draft will
> > materially help, and is at best a distraction from dealing with
> > meaningful problems.

> Do you mean the experiment or if this became a permanent
> part of the process? Your comments read as if you're concerned
> mostly about the latter, and you make no mention of the
> former.

Mostly the latter. But given I don't see this experiment being
successful, I think the community has better ways of spending its
limited resources.

> As it happens, I agree that this is not going to produce
> a huge improvement. But its not intended to, and modest
> improvements (as opposed to modest proposals:-) should also
> be ok. If not then we're in a worse process-rut than even I
> think.

If there is an improvement, I expect it will be too small to be worth
bothering with. And given the community's limited resources (a not
insubstantial amount of collective cycles has already gone into this
document), it seems better to use those resources where there is some
hope of making a real difference.

> > The crux of the issue is that any attempt at "fast tracking" is
> > fundamentally about short-circuiting some aspect of our review
> > processes. 

> I'd prefer s/short-circuiting/speeding-up/

Sorry, I think short-circuiting is the right term. Saying you are just
speeding things up is just spin.

The reality is that it takes time to do quality standards/technical
work. And, it takes iteration. The only kind of iteration that makes
sense is sequential. Get some review, revise, then review the new
version. When one tries to overlap sequential reviews, the result is
almost always a poorer quality document.  It is important that the
revisions get reviewed by a fresh set of eyes. If you short-circuit
such iteration, you inevitably get poorer quality documents. Also,
it's really unfair to reviewers to have all of them stumble across the
same issues.

> > This document risks substituting process for judgement. I'd rather see
> > more of the latter and less of the former.

> Disagree. The WG chairs exercise judgement to kick off the
> process. The IESG exercise judgement as usual with no changes.

This document would use a different kind of judgement. One that is
more formulaic. The kind of judgement I'd rather see is the WG/WG
chairs/ADs getting together and making the case for a particular
document being so important/urgent that it needs to be
accelerated. And then have them work out a plan to actually get
reviews in a more timely manner, etc. E.g., get committments from folk
to review and revise quickly. Have a realistic workplan that folk
commit to. If its not possible to get folk to commit to being
responsive, doesn't that implicitely say something about the overall
urgency of the document?  But make that case on a number of factors
(importance of having the RFC in place, etc.) rather than just on the
fact that there was some sort of running code associated with it.

> I think incorporating the discuss criteria should be an interesting
> part of the experiment. (I've found them really helpful in reviewing
> documents these last couple of years.)

Discuss criteria are an IESG-level construct, developed to find
balance between "nit picking" by the IESG very late in the process
vs. correcting real problems. That same criteria is not appropriate to
apply to a document that hasn't gone through WG LC, which is at a much
earlier stage of the process. 

> > No doubt, when a AD or reviewer suggests "this needs
> > fixing", the proponents will hold up this document and say "you
> > shouldn't do this, per the RFC -- you're violating the spirit of this
> > document, only really really critical stuff needs to get addressed..."
> > No thanks. That is not what the IETF is about.

> I don't see how you get to "No doubt..." I do entirely doubt that'll
> happen for most all editors.

This community is really good at citing process to justify whatever
action (or inaction) they would like to see. Like it or not, this
could become another such tool.

Thomas



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]