Re: The "Clerk" function and Standards throughput and quality

John,

I would like to question some of your assumptions below.

--On 3. oktober 2004 14:46 -0400 John C Klensin <john-ietf(_at_)jck(_dot_)com> 
wrote:

> 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.
I think that we cannot address the questions you raise below without the 
administrative reorganization - simply because under the current regime, we 
have running code that this does not get any better.
> 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).
We have considered such a model; in fact the General Area Review Team 
(gen-ART) has proved to me that it is possible to get a great deal done on 
a volunteer basis - and even more if you get someone to act as "secretary" 
for it, such as Avri Doria is now doing (Thank you, team!)
(see http://www.alvestrand.no/ietf/gen/review-guidelines.html for details)

Such a model would obviously be more stable if we could have parts of it 
moved into a paid-for secretariat.
But - in the current model, we have been told by the CNRI President that 
the IESG is being unreasonable already in the demands made of the 
secretariat, that no new functions can be added without financing for them, 
and that the only means available for getting more resources into the 
current secretariat are raising the meeting fees, getting direct sponsors 
for CNRI's IETF activities, holding exhibitions at the IETF and US 
government funding. Allowing the sponsors who currently sponsor the IETF 
through ISOC to pay for it was not an option.
Again, we have to fix the underlying problems before we can pop back up to 
this level. But once we get there, I don't think the current IESG is the 
biggest obstacle to doing so.
> 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.
I do not see that this follows. All of the items described above - checking 
that people are doing what they promised, following up when they do not, 
checking for adherence to formal criteria, sending back reasonably cogent 
notes when the checks fail, and following up - are fairly standard for any 
type of document-producing organization - whether it be a consortium, a 
standards organization or even a technical publishing house.
> 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.
A "contractor" would obviously have to work closely with the people running 
the process to get this done "right". But I don't see a particular reason 
to believe that an organization doing this under contract would be less 
able to make it work than a set of people hired by an organization more 
closely linked to the IETF to do the job.
But I don't see the models so far proposed blocking either possibility.

> (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.
I agree that we need a structure where it is possible to get there. And I 
think the administrative restructuring envisioned is a necessary step in 
getting there.
                    Harald



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf