Subject: RE: Input solicited: IETF problem pinpointing at the plenary?

From: Edward Lewis <[email-masked]>
Date: Mon, 4 Nov 2002 09:14:00 -0500

These are my opinions...I've read the thread, but I can't reach the 
doc right now.:

1. Problem:  What consensus means has been lost.  It's not "rough 
majority," it's the process of reaching a point of general agreement. 
(Not to pick on someone's post in this thread, but - I believe - 
agreeing to disagree is not an acceptable part of building consensus. 
In the instance I cite I am quoting out of context, but I've seen the 
sentiment come up in technical threads elsewhere.)

2. Problem: When an employee of Company A proposes Z and someone from 
Company B proposes Y, interested WG members seem to take up sides 
along "party lines" and not try to dig into Z and into Y and 
determine what is needed for "interoperability."

3. Problem: "Adversarial process" which is prevalent in much of the 
US culture has spread into the IETF.  While this process, when 
working in a healthy manner, has proven to be a fairly efficient 
means to resolving disputes in the past, the IETF has and is crossing 
into other cultures in which an adversarial approach is not the best 
solution to problem solving.

I don't think the problem is the bottleneck in the IESG.  I think a 
perception of a bottleneck at the IESG is a symptom of the problem.

I think the rancor apparent in the process is also not the problem by 
a symptom.   This is an expression of frustration, and frustration is 
a result of unmet expectations.  I really think that a lot of folks 
don't understand "consensus" and how it is achieved, thusly don't 
take time to tear into competing proposals to determine what are the 
salient elements needed from each to reach interoperability, 
resulting in a lot of subpar documents reaching the IESG.

Now, the situation is not as simple as I've stated above, nor do I 
think it is.  I'm being brief for email.

Now, assuming I just happen to be right (which is unlikely), here are 
some suggestions:

1. Being that the IETF is a non-membership, individual volunteer 
organization, we cannot expect to appoint any one to a post.  We can, 
however, ask for a volunteer to perform a function.  So, I would 
propose asking for a small set of volunteers in a WG to handle the 
responsibility for checking every aspect of an internet draft.  The 
editor/author retains primary responsibility for the content, but it 
is up to the a review committee to check for things from 
grammatical/spelling errors and other pedantic items.  It remains up 
to the chairs to make sure changes are reflected in the doc, and up 
to the WG to determine what the content is, but I think we need to 
hold someone(s) responsible for the construct in the document.

As these are volunteers, I would propose that the best incentive to 
get people to perform this is to include their names in a "reviewers" 
section somewhere near the acknowledgements.  To avoid the appearance 
of this representing an employer's "stamp of approval" I would simply 
list the volunteer's name but not affiliation.

This function would nudge up against directorates, WG, chair and 
editor's responsibilities.  The first goal of this would be to 
coexist with the current process, but be the focal point for clarity 
and construction.  This might help nonnative-English speakers be able 
to participate.  This function is already done in some groups, but it 
would be good to formalize it and spread it out amongst the WG 
members.  (Sometimes, when raising nits, I've felt that the editor 
thought I just making light of the language difficulties, instead of 
trying to be helpful.  It would be good to let editors know to expect 
such comments.)

Oh, besides grammar/language, getting documents that are standards 
track to use the SHOULD/MUST language correctly, and getting 
informational documents to *not* include requirements, etc. are other 
goals.

2. Education of editors.  They should set their expectations to be 
that they are serving at the behest of the WG, and not people leading 
the WG.  (I prefer editor to author too.)  Making this clear might 
help fend off organizations who are trying to play the IETF like 
other standards bodies get played.  (Please don't ask.)  Anyone 
getting their document into a WG needs to understand the gravity of 
the meaning - they go from author to editor and give up change 
control.

3. In general better "expectation setting" throughout the community. 
Knowing what is meant by "achieving consensus" seems to be lost lore. 
I think that reclaiming that is important.  Perhaps via more 
enforcement of WG chairs - gentle nudges to ask thread-members to try 
to get to agree on something, even if it is "lcd" - recall we are 
after interoperability (of good protocols).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Melinda Shore <[email-masked]>
Date: Mon, 04 Nov 2002 09:33:59 -0500

> sentiment come up in technical threads elsewhere.)

I think you may be misrepresenting something I posted
earlier about consensus as process.  I should mention that a
particularly good book on this is "Beyond Majority Rule,"
written by ???Michael Sheeran??? ??Sheehan?" and published
by Pendle Hill.  But I'll restate that we have bigger
problems with consensus process than simply not being
familiar with it, and those include 1) it doesn't work if
the participants don't share a similar level of investment
in the process itself, and 2) there's a pervasive attitude,
among the leadership (for whatever value of "leadership")
that we're engineers, not process monkeys.

But I absolutely agree that the failures we're seeing are
process failures, not structural failures.

Melinda

---

From: Edward Lewis <[email-masked]>
Date: Mon, 4 Nov 2002 10:36:14 -0500

>earlier about consensus as process.  I should mention that a

Not (intentionally) so - the "picked on" post was someone else's, but 
the idea above is something that I personally believe from other 
experiences.  Not to claim ownership, but just to state that "this is 
how one (more?) person feels."

Perhaps what I mean is that the spirit of consensus is missing - 
fewer and fewer folks are taking time to "work things out" and 
instead "agreeing to disagree" as a short cut to closure.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Marshall Rose <[email-masked]>
Date: Mon, 4 Nov 2002 08:08:20 -0800

> instead "agreeing to disagree" as a short cut to closure.

melinda - no, he's politely commenting on my note to frank.

ed - the problem is that at some point "closure" becomes necessary. if one or
more perspectives can move towards rough concensus, that's great... you'll get
closure as a by-product.

but, if it's clear that you can't move towards rough concensus, then you don't
get closure you get impasse.

i'm sure there are many schools of thought on this, but the two most prevalent
are:

1. no rough concensus = no closure. by extension, when it's clear you have this
kind of situation, you have to be willing to shutdown the working group. for
some reason, we don't seem to like to do this. i'm not sure, because i think if
we made an example of a couple of working groups, then rough concensus would
start to become more appealing. i'm sure there's some biblical analogy regarding
solomon here.

2. no rough concensus = separate the perspectives and let the market decide. we
tend to do this a fair amount, e.g., snmp/cmot, impp, etc. sometimes we penalize
everyone by requiring there be an interworking document (e.g., cpim) just in
case the market decides not to decide.

now, i get the feeling you favor the first school on this, and that's fine. if
the ietf learns to say "no" more often, then i think it can also learn to say
"bye" more often too. however, we just don't have a good history in saying "no",
and that's a problem.

an even bigger problem is that we should also consider a third school:

3. no rough concensus = get some luminaries to spend the cycles to figure out
which perspective makes the most sense (in terms of architecture, consistency,
etc.) and just go with that. the problem here is that we don't have a good
record in terms of making choices like this, and when we do, the luminaries end
up going with the 2nd school of thought above...

/mtr

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 4 Nov 2002 08:38:53 -0800

Hi -

> From: "Marshall Rose" <[email-masked]>
> To: "Edward Lewis" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Monday, November 04, 2002 8:08 AM
> Subject: Re: Input solicited: IETF problem pinpointing at the plenary?
....
> i'm sure there are many schools of thought on this, but the two most
prevalent
...

Another, not terribly prevalent one is this:

If all these engineers are unable to determine that one proposal is clearly
superior to the others, then perhaps there really isn't an overwhelming case
for any of them.  However, if a standard is truly needed, then it simply
comes down to: "Just pick one!"

Randy Presuhn

---

From: Frank Kastenholz <[email-masked]>
Date: Mon, 04 Nov 2002 11:53:27 -0500

>comes down to: "Just pick one!"

Except that company X has invested umpteen million dollars in
one proposal and company Y has invested umpteen million dollars
in the other one. Your observation means that one of the two
companies throws its investment away and reinvests (losing
money and time in the market). 

Yes, I know, in theory, the IETF is all individual engineers 
making the right decisions for The Internet and not biased
by crass commercial considerations. But let's face it, the
reality is very different.

Frank Kastenholz

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 4 Nov 2002 09:39:41 -0800

Hi -

> From: "Frank Kastenholz" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Monday, November 04, 2002 8:53 AM
...
...

If the additional value to having a *single* standard is that easily
offset by the development and time-to-market costs, then I think
it's fair to question (in this hypothetical case) whether it is really
needed.

A more fundamental question is whether the trend towards
"late standardization" (after implementation and perhaps even
deployment) would exacerbate matters by increasing the stakes.

Randy Presuhn

---

From: Edward Lewis <[email-masked]>
Date: Mon, 4 Nov 2002 13:41:07 -0500

>melinda - no, he's politely commenting on my note to frank.

;)

I guess I operate by school #1 - that if consensus isn't reached it's 
best to walk away from declaring any solution.  It's happened in 
provreg (we've had about 9 documents[0] so far enter the WG - 1 has 
gone to RFC, 5 are in front of the IESG, 3 have been dropped and just 
1 still under consideration).  I.e. 33% of our documents to date have 
been killed because no consensus could be reached.  (Whether because 
of "I don't like" or "I don't care" sentiments.)

My rationale is that consensus means that the group has found common 
ground.  If there is no common ground, then we don't have 
interoperability - and that is the single most important feature of 
an IETF standard.  If interoperability isn't the overriding goal, 
then the WG ought to be conforming to some other standards body 
anyway.

As far as "closing the WG" - that's not always the solution.  I've 
seen individual issues (DNS is loaded with them) that fail to achieve 
consensus and then wither away without closing the group.  (I suppose 
that the intent in school 1 was not to always result in a fatal error 
for the WG, but when I first read the message, I didn't recognize #1 
as my solution because of the "closing" phrase.)

[0] 2 are knocking at the door but haven't been allowed in.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer