Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199508240427.AAA09212@wilma.cs.utk.edu>
To: drums@CS.UTK.EDU
Subject: Getting back on track
cc: moore@CS.UTK.EDU
From: Keith Moore <moore@CS.UTK.EDU>
Date: Thu, 24 Aug 1995 00:26:55 -0400
Sender: moore@CS.UTK.EDU

Now that the latest discussion has died down, I'd like to see whether
we can find a basis for how to proceed.

There are many facets of the Internet email protocol specs which have
multiple interpretations with significant constituencies, where the
conflict between these interpretations might be considered to cause
harm.  

For any of these issues, if there are N (where N > 2) ways of
interpreting the specifications, choosing any 1 of those N is likely
to be painful to the N-1 remaining constituencies.  Yet we may be
better off choosing one than not choosing at all.

Here's the rub: 

1. In the IETF, we require at least rough concensus to make decisions. 
2. Many of our decisions that we need to make must necessarily run
   counter to the beliefs of the majority of  DRUMS WG participants, 
   thus making it difficult to acheive concensus.
3. We've got a lot of work to do and limited time to do it.

How are we going to make progress?

				  --

I believe we are going to need a bit more formal procedure than is
normal in IETF working groups.  I have some ideas for such a
procedure, for which I solicit comments (either on the list or in
private):


1. To bring up a topic for discussion, someone has to formulate a
statement of the problem which clearly expresses (a) the loss of
functionality being observed, and (b) the protocol interactions which
appear to be responsible.  

If these protocol interactions are caused by varying interpretations
of the specs, the problem statement should also attempt to state what
these interpretations are and to identify their constituencies.  

2. The problem statement is submitted to the group for private comment.
(that is, comments about the initial problem statement should NOT
occur on the mailing list, but through private email with the author
of the problem statement.)  After the author has allowed sufficient
time for private discussion of comments, he will forward the problem
statement (via private mail) to the Chair.

3. At an appropriate time, the Chair will introduce discussion of the
problem on the mailing list.

4. The WG discusses the problem statement for a few days to determine
whether there really is a problem that needs solving. (In other words,
are we better off not changing anything, or changing things so that
you don't like how it turns out?)

5. The WG members are then polled to see if there is concensus that
the problem needs to be solved, *even if that solution goes against
that member's idea of how things should be*.  

In all cases, it needs to be understood that we are NOT going to force
changes in behavior that have a significant negative impact on the
installed base.  Nobody in this group wants to break Internet mail.
But we might have to cause some minor pain for some groups to make
things better in the long run.  The WG as a whole needs to decide
whether this pain is worthwhile, but (for the purposes of this
particular decision) should assume that the solution will be chosen to
have minimal disruptive impact.

If the concensus of the WG is that the problem isn't worth solving,
then further discussion of that particular problem statement is
out-of-order.  (However, if the problem surfaces in another form,
someone can write up another problem statement.)

6. Only *after* the WG has reached concensus that the problem needs to
be solved, should proposals for the solutions be discussed at length
on the list.  But once the WG has reached this concensus, arguments
that things work just fine as-is, or that the problem doesn't need to
be solved, are out-of-order.

Keith