Re: Modemmgt Working Group status

[Steven Waldbusser <[e-mail]>]

Excerpts from modemmgt: 8-Feb-94 RE: Modemmgt Working Group ..
Les_Brown-LLB005@email.m (3895)

>    If there is an email posting on a particular aspect of the MIB and no one 
> responds to a proposal, does that imply that we have consensus on that aspect? 
> What if one person objects to a proposal but several others agree with a 
> proposal, is that consensus? How many must agree? What if one person
> objects and one person agrees with a proposal?

The quick answer to this is "We know it when we see it".  The reason
this is so imprecise is that it changes over time.  In the end, it is up
to the working group chair to recognize consensus.

For example, early in the process there is a void.  The working group
will often reach consensus that the first proposal to reach the working
group is a good baseline, as long as it doesn't piss off a significant
portion of the WG.  If there is more than one proposal put forth,
sometimes the group will reach consensus on one, other times the authors
will choose to work together on a joint proposal, and at other times the
group will reach consensus that the authors shall work together.  Even
after there is consensus on a baseline document, it may be quite
unrefined.  At times like this, the group may not have even agreed upon
general principles by which the standard should be designed.  When the
group agrees on a new principle, this will typically involve many
changes to the text which are typically done by an author, and agreed
upon as a whole.  As the document becomes more refined, the group
reaches consensus on decisions at finer and finer levels of granularity.
 The last set of decisions may be on a detailed set of instructions that
an editor will carry out.  On non-trivial issues, these instructions may
be as detailed as specific wording to use.

In general, silence implies consent.  Long silence affirms that consent.
 Silence in response to a declaration of consensus nearly seals it, in
my opinion.  The chair may feel around for consensus, and sensing it,
suggest that it is one way.  If consensus wasn't there, it will elicit
comments from the dissenters and the issue will be re-examined.  The
chair may be wrong from time to time, but this is just part of the
process.  People may be misunderstood from time to time, but this is
just part of the process.  Apologies/amends are made, and we move on. 
BTW, in my opinion it really doesn't have to be the chair, except on
issues of major importance.

When authoring/editing a document, the writer becomes more and more
constrained as time goes on.  In the first proposal, anything goes.  As
time goes on, the author may unilaterly change minor things, but needs
to be restrained on major things.  As time draws on, this is reduced to
clarifying text and it behooves the author to explicitely announce
unilateral changes that might suprise some people (As an example, look
for my note entitled "OID tree") .  Near the end, the auther can really
only change obvious bugs, spelling mistakes, and formatting.  

It is generally quite clear how important a particular issue is. 
Important issues usually have a deadline for comments, consensus is
explicitely noted by the chair, and a large majority needs ot be
comfortable with the decision .  Less important issues may have
consensus noted nearly off-handedly, or may enjoy only a slim majority
of support, with grudging approval from the rest.

I think we're at the stage where we are getting more and more explicit
about our decisions.  I don't think we will be doing anything important
in the next two weeks that is not very clearly defined in the working
group email, therefore there will be little chance for
mis-interpretation.

My answer is long and somewhat rambling because it is complex to
describe how reasonable people should act in these circumstances.  But,
in the end, the answer is "they should act reasonably".


Steve

P.S.  The closest there is to written policy on this matter comes from 
draft-ietf-iesg-wgguidelines-02.txt:

     3.3. Session management

     Working groups make decisions through a "rough consensus"
     process.  IETF consensus does not require that all participants
     agree although this is, of course, preferred.  In general the
     dominant view of the working group shall prevail.  (However it
     must be noted that "dominance" is not to be determined on the
     basis of volume or persistence, but rather a more general sense
     of agreement.)  Consensus can be determined by balloting,
     humming, or any other means on which the WG agrees (by rough
     consensus, of course).

     The challenge to managing working group sessions is to balance
     the need for open and fair consideration of the issues against
     the need to make forward progress.  The working group, as a
     whole, has the final responsibility for striking this balance.
     The Chair has the responsibility for overseeing the process but
     may delegate direct process management to a formally-designated
     Facilitator.

     It is occasionally appropriate to revisit a topic, to re-evaluate
     alternatives or to improve the group's understanding of a
     relevant decision.  However, unnecessary repeated discussions on
     issues can be avoided if the Chair makes sure that the main
     arguments in the discussion (and the outcome) are summarized and
     archived after a discussion has come to conclusion. It is also
     good practice to note important decisions/consensus reached by
     email in the minutes of the next 'live' session, and to summarize
     briefly the decision-making history in the final documents the WG
     produces.

     To facilitate making forward progress, a Working Group Chair may
     wish to direct a discussion to reject or defer the input from a
     member, based upon the following criteria:

     Old

          The input pertains to a topic that already has been resolved
          and is redundant with information previously available;

     Minor

          The input is new and pertains to a topic that has already
          been resolved, but it is felt to be of minor import to the
          existing decision;

     Timing

          The input pertains to a topic that the working group has not
          yet opened for discussion; or

     Scope

          The input is outside of the scope of the working group
          charter.