Pete Resnick wrote:
...
On 5/3/13 7:59 AM, Thomas Narten wrote:
Like everyone, I wish things moved more quickly, but every attempt
I've ever seen that tries to speed things up ends up reducing the
quality or having some other undesirable side effect.
Can you talk a bit more about this, including some examples?
I'm trying to reconcile the concern that we "end up reducing the quality"
and
that we "NOT neglect longer-term stuff that will have real and
significant, but
not immediate benefits." ADs have finite resources and can't accomplish
both immediate and longer-term stuff maximally all of the time. My
inclination would be to say, "If they are in conflict, weight the
longer-term
over the immediate, even if that might result in some reducing of quality
on
any single document." Am I over-reading your earlier message to say that
you think the weighting should go toward the immediate? I think we agree
that doing the longer-term stuff will end up with increased quality over
the
long term, but doing more of the longer-term stuff is sure to reduce the
amount of time spent on immediate, which means document reviews and
therefore some short term lowering of quality. Is that OK, or is that an
example of the kind of thing we've attempted that ends up with bad
results?
Pete,
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 the I-D series was introduced specifically to deal with the issue of
RFC == STD, we didn't get it right. In hind sight we should have done
something more like the IEEE does with 802.11, and explicitly put a big
DRAFT: in the title. Industry doesn't seem to get confused about DRAFT: N or
DRAFT: AC, and still deploys, then moves on with full standards. We could
still do that, and likely get motivation to move a DRAFT: to PS (remove the
DRAFT: from the title) by wider review and deployment. I realize this is
really doing nothing more than introducing an extra step in the process, but
in some ways it is more of a formalization of the expected behavior at the
first RFC step. One could go so far as to not remove DRAFT: until the spec
met DS, and move the default from PS to DS at the same time as removing the
extra step from the process. One could really get crazy and just remove DS
from the list, because nobody understands what that one is for anyway, and
then when the DRAFT: gets removed from the title it is really the STD people
are expecting ... ;)
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'. At the end of the day, the
only way to reduce the time at IESG review is to have a document with clear
objectives up front that the document can be evaluated against, and for the
WG to put a quality document in their hands. Too often the WG takes so long
that the objectives drift, if they were even clearly stated up front, and
comments like "you have to have been involved in the mail thread" show up
during review. If something is not clear in the document, and it was cleared
up in a meeting or on the mail list, that clarification needs to get moved
into the document or subsequent reviewers / implementers will never get it,
and the result is delay and/or poor quality documents.
Tony