ISSUE: Procedural rapid ossification

[John C Klensin]

A number of list transactions/ discussions in the last few 
weeks, and a few recent offline discussions, have convinced me 
that we have another problem that both belongs on the list and 
calls for thought about this WG, its processes, and those it is 
spawning.

Summary: In a system that is designed around having firm general 
principles and considerable IESG discretion within those 
principles, we are showing a disturbing tendency to turn IESG 
"rules of convenience" into rigid strictures that cannot be 
violated or deviated from.  It is a bad combination.

----

At least prior to the current round of discussions, IETF 
discussions of procedures have been driven by a model in which 
the procedural BCPs construct a framework for doing work, but 
the details of that framework are left for the IESG to fill in. 
When issues or crises have arisen, we've generally avoided 
making specific procedural changes to compensate, instead 
realizing that we could not anticipate all cases and that 
"fighting the last war" is not a good way to proceed.

It is exactly this model that makes trusting the IESG so 
important: if they cannot be counted on to fill in those details 
appropriately and fairly, and to avoid moving their authority 
past the boundaries of the framework or ignoring the framework 
entirely, we have a problem that no amount of low-level 
procedural tinkering is going to fix. That is part of a 
different thread; this note is about the present situation and 
assumes a trusted and well-behaved IESG.

Over the last decade, the IESG has established a great many 
rules to fill in process details.  Most of them are well within 
IESG authority to "manage the process".  But it is important to 
remember that these are rules created by the IESG -- in some 
cases without a great deal of debate or consideration.  As such, 
the IESG can change them, make exceptions to them, etc.   And we 
seem to have lost sight of that and, instead, are burying 
ourselves in procedures that rapidly move from organizational 
conveniences to rigid and immutable doctrine.

Some examples:

	* I-D submission and WG/BOF scheduling deadlines: The
	various pre-meeting deadlines for submitting I-Ds and
	for requests to schedule meeting slots were worked out
	between the IESG and the Secretariat.  In the I-D case,
	the goal was to be sure that documents could actually
	appear well before the meetings started. In the meeting
	slot case, a deadline date was needed to permit
	carefully balancing requests and the desire to avoid
	conflicts of sessions that required the same people.
	An additional, although later, constraint involved
	getting the agenda printed and ready for distribution at
	the meeting.
	
	The reasonableness and appropriateness of such rules is
	obvious to anyone who has even carefully contemplated
	organizing a complex meeting.  But the suggestion that
	the IESG cannot make an exception if they consider it
	important enough falls somewhere on the scale from
	"silly" to "dangerous".  The deadline dates are not
	fundamental principles that are critical to the
	existence of the IETF as we know it.  They are useful
	guidelines that the IESG has set up and can modify, or
	make exceptions to, at will.
	
	* BOF scheduling.  Over the years, as pressure for
	meetings slots and requests for BOFs has increased, the
	IESG has become increasingly specific about requirements
	for requesting, and being granted, a BOF.  Again, this
	is clearly necessary since the alternative would be
	having all meeting time taken over by BOFs.  Whatever
	the requirements are at a given time, they are
	requirements imposed by the IESG as part of their job to
	efficiently manage the meetings and the process.  But,
	if the IESG decides that something is important enough
	to waive the rules in a particular case, they can do so
	since these are _their_ rules.  I assume they would not
	do that capriciously; I hope that they would explain the
	logic for making an exception to the community (and
	especially to those whose BOF requests were denied).
	But they clearly have authority to make exceptions;
	nothing else makes sense.
	
	* What is a WG?  And what isn't a WG or BOF?  RFCs 2026
	and 2418 make some fairly specific statements about WGs
	and BOFs and how they operate, particularly those
	involved in the standards process.  But, unless we get
	enough carried away with procedures to read those
	documents with an "anything not explicitly permitted is
	forbidden" perspective, they don't prohibit other forms
	of WG or BOF organization for other purposes, nor do
	they prohibit completely different kinds of structures.
	So I suggest that, in the general case, a BOF is
	anything the IESG says is a BOF, a WG is -- subject to
	some constraints about charters, etc.-- anything the
	IESG says is a WG, and, if the IESG wants to create a
	special type of gathering called, e.g., A Big Hokum and
	give it meeting time and mailing lists, nothing we have
	procedurally prevents them from doing so and we
	shouldn't waste time trying to create specific rules for
	such things.
	
	* What, really, is an "umbrella WG"?  Along the same
	themes as the above, we've had some recent discussion
	about "umbrella WGs".  I used to think I knew what an
	"umbrella WG" was... we had a special word for it, and
	the word was "Area" or "Subarea". Under the formal
	procedures, the IESG can create and delete areas at its
	discretion.  It is actually easier, procedurally, to
	create an area than to create a WG, since there is no
	formal requirement for posting draft charters, allowing
	for comments from the community and other standards
	bodies, and so on.  There are practically no constraints
	on the IESG about getting rid of any area either.  The
	only thing the IESG is prohibited from doing involves
	creating an Area and appointing someone outside the IESG
	to head it -- that appointment has to be made by the
	nomcom.   The procedures leave the boundary between
	"area" (with an AD on the IESG) and various subarea,
	umbrella, and super-WG concepts strictly in the IESG's
	hands (along with Big Hokums).  But we should avoid
	getting so rigid about what any of those terms might
	mean with regard to structure and duration that it
	prevents our thinking clearly and creatively.
	
	* What is the procedure for submitting a document for
	IESG processing?  The IESG makes these procedures up,
	and defines them as needed.   Having procedures is A
	Good Thing -- they very much reduce the possibility of
	general confusion and apparent abuse.  But, if the
	procedures need to be tuned, or if different procedures
	are needed for particular cases, we shouldn't need to
	spin up a WG to write a document: a WG Chair should be
	able to make a determination that the idea has some
	consensus and then pass it off to the IESG as a
	recommendation by sending a simple email note.  The IESG
	then ought to be able to hold a short discussion, adopt
	the idea if they conclude it would be useful, and
	briefly explain not --or engage in some discussion on
	the subject-- if they think it is not.   Spinning up WGs
	and writing documents at that level could actually be a
	disadvantage: we really don't want to start getting the
	IESG so tied up in BCPs that micromanage their
	procedures that we need big-structure working groups
	every time some special case comes along.

Let's look for ways to move forward while creating as little 
bureaucracy and formal structure as possible.  We really don't 
have the extra cycles to waste on that stuff if there is any 
reasonable alternative in a given case.

       john