Subject: ISSUE: Procedural rapid ossification

From: John C Klensin <[email-masked]>
Date: Fri, 06 Jun 2003 14:14:54 -0400

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 6 Jun 2003 15:35:18 -0500

Dear John (Klensin),

I look forward to the Vienna meeting with increased anticipation.

Thank you for the slap across the face ("thanks, I needed that").

Since you mention I-D submission deadlines specifically -
I remember the Munich IETF, and hearing from an IAB member
who missed the I-D cutoff by several minutes (less than 10), so
we couldn't discuss the proposal (can't remember if it was a WG
document or not).

After that, I've had very high regard for the IETF's rules.

You are suggesting that my regard might have been a little TOO
high. An interesting thought.

Spencer

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: <[email-masked]>
Sent: Friday, June 06, 2003 1:14 PM
Subject: ISSUE: Procedural rapid ossification

> violated or deviated from.  It is a bad combination.

[deleted rest of interesting e-mail]

---

From: Scott Bradner <[email-masked]>
Date: Fri, 6 Jun 2003 16:52:18 -0400 (EDT)

> we couldn't discuss the proposal (can't remember if it was a WG

from 2418

7.1. Session documents

   All relevant documents to be discussed at a session should be
   published and available as Internet-Drafts at least two weeks before 
   a session starts.  Any document which does not meet this publication 
   deadline can only be discussed in a working group session with the   
   specific approval of the working group chair(s).  Since it is
   important that working group members have adequate time to review all
   documents, granting such an exception should only be done under      
   unusual conditions.  

the chair can override the deadline if the chair thinks it is important

Scott

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Jun 2003 16:55:33 -0400

> we couldn't discuss the proposal (can't remember if it was a WG

Just in case I was the relevant IAB member, note that you just 
invoked two separate rules...

	(1) There is an I-D cutoff, and documents submitted
	after it are not going to get posted.
	
	Can the IESG make an exception to that rule if they
	consider it important enough?   That has, I believe,
	always been the case.  Should they do it very often?
	No, that would probably cause chaos and accusations of
	unfairness.  But the notion that they _cannot_ make an
	exception would be, IMO, just wrong.
	
	(2) Many WGs, and some areas, have adopted a rule that
	documents that weren't posted before the IETF meeting
	starts can't be discussed because there would be
	insufficient time for people to read and assimilate
	them.  Is that a good rule?  Almost always.  Can the
	relevant AD, or even the WG Chair, waive it if that is
	in the WG's best interests?  Yes, I hope so -- if that
	is impossible, we have really gotten hung up on
	procedures to the exclusion of substance.  Should an
	exception occur very often?  I personally think that
	would be a really bad idea.

And, for whatever it worth, were I an AD or WG Chair, I'd be a 
lot more sympathetic to a 10-minute-after-deadline request to 
ask the Secretariat to post a draft anyone, or to an 
hour-after-deadline request to post a link to the draft on a web 
page and notify the WG's mailing list that it is on the meeting 
agenda, than I would to someone standing up during a WG meeting 
and saying "well, I've got this draft that missed the deadline, 
and which no one has seen, but I think we should discuss it 
anyway".  The first two options preserve the principle of early 
and widely-available posting.  The "in the meeting" one would 
seem to be nonsense and abusive of the time of the WG 
participants... but there might be an exception somewhere.

> high. An interesting thought.

Very possibly.   They are rules.  Almost all of them are useful 
rules.  They have not been chiseled into stone by a divine hand 
and I think we put ourselves at risk by pretending that they 
were.

   regards,
     john