--On Friday, May 15, 2009 14:16 -0400 Eric Burger
<eburger at standardstrack.com> wrote:
If we really think the problem is 80% of the documents are not
ready for IESG submission when the WG thinks it is, and if 80%
of those documents have "classic" bugs, I would offer we do
the (gasp) ITU-T thing and hire 3-4 full-time, PAID (i.e.,
IETF/IAD/ISOC staff) experts to review submissions before they
get to the IESG.
A week or two lag in Editor Purgatory(tm) would be well worth
it if it saves 50-100 days of AD/Author cycling.
That model could also help get documents edited into
intelligible and coherent form before they go into Last Call,
reducing the number of changes that are made in either IESG
notes to the RFC Editor or by the RFC Editor at AUTH48. That
might take more than a week or two in Editor Purgatory, but
would considerably streamline the process elsewhere and
eliminate several of the risk factors our model of approving
documents for publication.
However...
(1) The possibility of having professional staff do this sort of
evaluation and possible tune-up was why a few of us fought for
more flexibility when BCP 101 was done and again for a
Secretariat model that could contribute more directly to the
IETF's work (I think we tried to make a distinction between
administrative/meeting planning Secretariat and Standards
Secretariat functions at the time). Without trying to review
the reasons, we lost and lost fairly clearly. It may or may not
be the right time to reopen the question, but it is a very basic
one.
(2) There are some very significant interactions between what
you suggest and the RFC Editor model and allocation of tasks.
In the present arrangement, where what we are now calling the
ISE (a role that inherently requires considerable technical
understanding) is part of the same organization as the
"Production House" and RSE activities and the three are hosted
in a definitely technical and sophisticated engineering
organization, one can easily imagine shifting some of the
vetting and editing activities from the current "back end" model
to a "partially front end" one. However, going forward, the
"RFC Production" operation may not be sophisticated enough
technically to perform the sort of evaluation you suggest. That
would suggest needing to adopt an entirely new structure to
handle the evaluation (remember that BCP 101 requires that the
IASA have only one employee) and to sort out interactions
between that pre-IESG evaluation process and the RFC Editor
(certainly, one would not want to have that evaluation process
make some changes that the RFC Editor function would want to
change back). If you see that as a problem, you are running
out of time to complain about it.