Since the discussion about scenarios for structuring the
administrative arrangements seem to be settling down, it is
probably time to try raising some questions that might really
impact the problems that get solved.
The issues raised below interact directly with the problems of
getting better-quality standards produced more quickly. Unlike
some recent discussions, they address those problems directly,
rather than hoping that sufficient administrative reorganization
will help by raising the tide.
At a very high level, Carl's document splits the current
Secretariat task into a meeting planning function and a "Clerk"
one. There has already been some discussion about nit-picking
the boundary between the two. But, ignoring that, the Clerk
function can be summarized as "what the secretariat is supposed
to be doing now, if only if worked well". Because the way in
which this is structured may have a profound impact on what we
can and cannot do in the future, I think the community ought to
consider what we really want from that function... or at least
which options we wish to close and which ones we wish to leave
open.
Two examples (there are others, but I am _not_ going to write
another 300+ line note):
(1) Standards Secretariat function: It has been observed
repeatedly that the IESG has too large a workload, with many bad
consequences. The solution that other standards bodies have
adopted for similar problems involves developing strong
secretariat functions that can provide significant staff support
to the standardization effort itself. For example, ADs spend
significant time reviewing and checking documents to be sure
that they are structurally ready for Last Call, developing
ballot statements and draft protocol action notices, etc. In
other standards bodies, the equivalent tasks are done by
interactions between what we call WGs and secretariat staff: in
those models, the AD would see something only when all of the
non-substantive nits, and maybe some of the substantive ones,
were picked and the ducks lined up (or in response to a
complaint about secretariat behavior). The review committees
called for in various proposals might be appointed or approved
by the ADs, but coordinated by the secretariat: documents could
be sent out for review, and reviews accepted and collated for
AD/ IESG review, with no AD interaction at all. In extreme
versions of this model, the Secretariat might even have people
with engineering skills on staff who could perform preliminary
technical reviews, check for overlap with other IETF activities,
etc.
The good news about that sort of model is that it could
significantly reduce IESG workload and increase throughput,
especially if we selected ADs who were willing to trust the
Secretariat and let them do the job as outlined. Doing that
might permit us to put people on the IESG who lacked sufficient
external support to devote most of their lives to the IETF,
which would almost certainly be good. The bad news is that it
is very risky: a number of standards bodies have gone down this
path without adequate management controls and adequate
understandings of boundaries and authority and discovered that
they had ended up with Secretariats who could block anything
they didn't like (or even coming from people they didn't like)
and who might be able to put some proposals at considerable
advantage relative to others.
I suppose it is also obvious that it wouldn't be cheap. But the
various supporters of the IETF --in dollars or via the in-kind
contributions of the most of the time of senior people-- either
care about throughput and leveraging those dollars or they
don't. If I were the employers of most of the IESG members, I'd
be happy to put some additional number of dollars (Euro, Kroner,
Yen, ...) into the pot if it simultaneously improved IETF
efficiency and got me a significant fraction of the attention of
those people back.
It is a tradeoff, and it involves decisions that the current
IESG should not be expected to make, if only because most of
them have figured out how to work in the current environment and
presumably like it (at least to the extent needed to continue).
However, moving in that direction is incompatible with notions
of "it is a generic function and we can contract it out to
anyone who provides generic support functions to standards
bodies and consortia". It wouldn't have to be done within the
IETF Administrative operation itself, but it would certainly
need to be very closely coordinated (much more closely and with
much more responsiveness than we usually think of with
"contractor") and it would have to be staffed by people who had,
at least, a good understanding of the subject matter and
relationships in IETF's work.
If there is any chance that we want any version of this
"standards secretariat" function, we had best make certain that
the administrative structure can accommodate it, and that it can
do so with little disruption to its basic design parameters.
(2) Document editing prior to Last Call. With more pressures on
everyone, and more documents being written and edited by people
who are not fluent and native speakers and writers of English,
we are getting an increasing number of documents submitted for
Last Call that are painful to read and sometimes more ambiguous
than we would prefer, especially in standards-track materials.
Then either the ADs try to fix them (resulting in considerable
delays and interactions) or they go out for Last Call, where
people who might skim through and check a focused and
well-written document sometimes conclude that they have better
ways to spend their time, reducing quality of review. They then
cycle back to the IESG, where there is some chance of the
problem being repeated. And then they go to the RFC Editor,
where there is an inevitable set of conflicts about whether
editing can be done without damaging meaning, whether they have
any business intensively editing something that the IESG has
approved, etc. If they do make extensive editorial changes, we
may end up with a standard published as an RFC which the WG that
created it barely recognizes. If they don't, we may end up with
one that no one except the author(s) and WG can understand. And
the time between approval and publication keeps going up because
editorial review and correction take time.
If we think this is a problem, one obvious way to fix it would
be to include editorial checking and, if necessary, professional
technical editing, prior to Last Call. That would give us a
situation in which the documents that are Last Called would be
more comprehensible, easier to read, and a closer approximation
to what would finally be published (if approved) than we have
today. Structurally, the activity could either be part of the
RFC Editor function or complementary to it. It might or might
not increase the time between WG signoff on a document and
actual Last Call -- today, the ADs sift through the documents
and negotiate clarifications before Last Calls are issued, and
that is rarely a fast process -- but it would almost certainly
improve quality.
Again, this would not be cheap. It would require getting
management procedures in place to make sure that documents were
properly assigned and flowed smoothly. A little less "Clerk"
and a little more "Standards Secretariat" would help with that,
but is not a requirement. It may or may not be compatible with
the models anticipated by Carl's document. But, if we might
want it, we had best be sure, now, that whatever administrative
model is adopted is compatible with it.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf