Subject: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd)

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 22 Oct 2004 16:54:25 -0700 (PDT)

Guess what faciliated this former WG's area director to write this up ...
(and you can also wonder what would have happened if this was already an 
 RFCat the time of WG closure)

---------- Forwarded message ----------
Date: Fri, 22 Oct 2004 14:41:33 -0700
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RFC 3929 on Alternative Decision Making Processes for
    Consensus-Blocked Decisions in the IETF

A new Request for Comments is now available in online RFC libraries.

        RFC 3929

        Title:      Alternative Decision Making Processes
                    for Consensus-Blocked Decisions in the IETF
        Author(s):  T. Hardie
        Status:     Experimental
        Date:       October 2004
        Mailbox:    [email-masked]
        Pages:      11
        Characters: 26493
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-hardie-alt-consensus-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3929.txt

This document proposes an experimental set of alternative
decision-making processes for use in IETF working groups.  There
are a small number of cases in IETF working groups in which the
group has come to consensus that a particular decision must be made
but cannot agree on the decision itself.  This document describes
alternative mechanisms for reaching a decision in those cases.  This
is not meant to provide an exhaustive list, but to provide a known set
of tools that can be used when needed.

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  Distribution of this memo
is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Fri, 22 Oct 2004 21:08:02 -0400

> -----Original Message-----
> From: william(at)elan.net [mailto:[email-masked]] 
> Sent: Friday, October 22, 2004 7:54 PM
> To: [email-masked]
> Subject: RFC 3929 on Alternative Decision Making Processes 
> for Consensus-Blocked Decisions in the IETF (fwd)
> 
> 
> (and you can also wonder what would have happened if this was 
> already an  RFCat the time of WG closure)

This document was first published in May 2003, long before MARID existed.
IETF last call started in June 2004.  It was approved by the IESG in July
2004.  In other words, the MARID finale had _nothing_ to do with it.

-Scott-

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 23 Oct 2004 05:39:55 -0700 (PDT)

> 2004.  In other words, the MARID finale had _nothing_ to do with it.

Ah, good to know. I was afraid what happened at MARID was a very special 
case of how IETF system failed. I guess it is not the first time and IETF 
has seen it before...

Still I don't particilarly like to see solution pushed through when
there is no consensus on it and especially when there are strong
corporate interests involved involved in the specific proposal.

I think IETF should allow for determening rouch consensus not only
for any specific proposal but also process to find if there is rough 
consensus "against" the proposal. In the case where it happens (i.e.
when there is not a 50/50 split) the proposal should not be pushed
through with this new "alternative decision making process".

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 26 Oct 2004 14:56:57 -0700

Generally applicable comments on 3929:
1)This scheme would put excessive power in the hands of the few: the 
Chairs, who are appointed (indirectly) by the elite few who can pay 
non-trivial sums of money to attend lots of IETF meetings, such sums 
generally provided by large corporations with entrenched interests.  It 
also further empowers the chairs to determine whether rough consensus 
has been reached.  Increasing the power of entrenched interests is 
DESTRUCTIVE.  This plan, if implemented, will make decision-making in 
the IETF WORSE than it is now.

2)A major failure of , e.g. the MARID WG (including the Chairs) was the 
failure to encourage/require a cost (in the broadest sense of the term) 
analysis of the proposals. This scheme fails to encourage that too.  
Instead it just says "the working group chair(s) should also make
   an explicit call for consensus, summarizing the technical issues and
   the choice to be made."
Cost analysis is not a technical issue.  (But I hope it's in MARID's new 
charter if it gets re-chartered!  (Anyone pushing for that?))

3)The author fails to adequately consider the benefits of 
experimentation: continued experimentation and discussion is removed as 
an option.

4)In general, where there are competing proposals, instead of 3929, 
there should be a push for documents providing things such as pros and 
cons, cost-benefit analyses, rationale, and context that will help 
inform the membership and lead to consensus. 

MARID specific comment:
What happened here doesn't seem to be a failure, but rather was a 
success in the following sense: There was not sufficient maturity in the 
proposals for a rough consensus to be reached that the proposals were 
adequate to meet the bare minimum of goals that they needed to meet.  
The process brought the fact to light that the proposals were 
inadequate.  Many of us weren't aware of this early on.  3929 seems to 
assume that a failure to reach a rough consensus must mean there's a 
problem in the process, when in fact it could be in the proposals.

>Date: Fri, 22 Oct 2004 
>From: rfc-editor
>To: ietf-announce
>Subject: RFC 3929 ...
Odd that the post to IETF-announce came 3 months after the IESG's approval.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 27 Oct 2004 07:16:57 -0400

On Oct 26, 2004, at 5:56 PM, Matthew Elvey wrote:

> This scheme would put excessive power in the hands of the few: the 
> generally provided by large corporations with entrenched interests.

Do you attend the IETF meetings on a regular basis?  I ask this because 
at the IETF meetings I attend I have met a non-trivial number of people 
who work for non-profits, government agencies, academic institutions, 
and one-man consulting shops.  I am good friends with several 
individuals who paid their own way to IETF meetings while unemployed, 
including trips abroad.  While funding trips to the IETF requires real 
money, characterizing those who do as the "elite few" is a 
mischaracterization.

-andy

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 27 Oct 2004 09:53:20 -0400

> generally provided by large corporations with entrenched interests.

  Even if what Andrew said wasn't true, how do you propose to fix
this?  I don't want to discuss that here, as other lists are more
appropriate.  But if you're tearing down the existing system without
proposing a new one, that's no way to move forward.

> analysis of the proposals. 

  IMHO the failure to a acheive consensus was guaranteed once the
consensus was to look at RFC 2822 identities.

> experimentation: continued experimentation and discussion is removed as 

  .... as part of the IETF process.  Nothing prevents anyone from
experimenting and discussing outside of the IETF.

> inform the membership and lead to consensus. 

  Such documents will simply move the failure to acheive consensus to
a different position in the process.  Witness the "SPF is cheap to
deploy", versus "no, SPF is expensive to deploy" arguments.

> 3929 seems to assume that a failure to reach a rough consensus must
> mean there's a problem in the process, when in fact it could be in
> the proposals.

  It's the same thing.  The process didn't empower participants to
discover problems in the proposals.  Why that happened is another
story.

  Alan DeKok.

---

From: "Julian Mehnle" <[email-masked]>
Date: Wed, 27 Oct 2004 16:19:34 +0200

> problem in the process, when in fact it could be in the proposals.

...or in the participants' objectives.  Or in all three of them.

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 27 Oct 2004 07:45:26 -0700 (PDT)

> money, characterizing those who do as the "elite few" is a 

I'm one of those who pays for conferenses out of my own money and its hard 
thing and I always try to shave off as much of expense as possible (staying 
in smaller $50/day hotels if possible, driving my car to the conference if 
its nearby, etc). The conference itself is also expensive for those of
us not working under large corporation - especailly if we have to attend
it 3 times a year. Its good thing for me lately that my main clients are 
all doing ok (.bust seems to have stabilized into slow growth).

Still Mathew is right that elite that come to every meeting are the one
that make most of the decisions. Those others of us there can advise them 
and show support or lock of it and hope the do the right thing but if you 
do not attent the meeting you can't even vote the person out of IESG - do 
remember being able to part of selection commitee that decides on area 
director posts, you  need to have attended 3 out of 5 meetings in person.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: John Levine <[email-masked]>
Date: 27 Oct 2004 17:34:30 -0000

> generally provided by large corporations with entrenched interests.

A fair number of us go to IETF meetings and pay partly or entirely out
of our own pockets.  We stay in cheaper hotels or with relatives, but
we go.  If the IETF process is important to you, you should also go.
If it's not that important to you, that's fine, too.  But the category
"very important but not worth my spending any money" simply doesn't
exist.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 27 Oct 2004 21:46:46 +0200

> "very important but not worth my spending any money" simply doesn't

What you all seem to forget is that you live in the US or at least on
the American continent where most of the meetings happen.
Paying about half of a months income (after tax) for flight, hotel and the
rest to attend one meeting and spending about half or more of my vacation
days per year to travel to IETF meetings is more than I can and am
willing to afford.
And with the current procedure of entry to the USA for foreigners I
personally feel it is kind of a frivolity to still have meetings in
the USA. I wait for the time to come when you get tatooed and a chip
implanted or one will not be allowed to entry.

Despite the fact that least 3 or the authors of input documents to the
MARID group were not from the American continent there wasn't even a
poll about where to hold the interim meeting. We were presented that
fact that the interim meetings tales place at this and that location
and that was it.
And on the meeting showed up people and names I have never seen in emails
to this list or take part in a discussion but they were part of the
dicision making process. Maybe if the meeting had been at XY Company
and they would have had their own proposal and some 100 employees had
shown up at the meeting we would have had a completely other result.

This is not the topic of this (ex-) group but these are problems that
IMHO showed up with this group and had IMHO quite some influence onm the
results.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: [email-masked]
Date: Thu, 28 Oct 2004 08:48:29 -0700 (PDT)

> money, characterizing those who do as the "elite few" is a

Here's an additional data point: Back in the days when MIME was under
development I paid my way to most of the meetings out of my own pocket since
the college I was working for at the time was uninterested in funding the work.
Subsequent to that I worked for a small company, which paid for my attendance
on a regular basis. And since going to work for a large company, I've found my
ability to attend meetings to be markedly diminished due to a variety of
factors.

				Ned

---

From: Greg Connor <[email-masked]>
Date: Thu, 28 Oct 2004 21:57:55 -0700

--Matthew Elvey <[email-masked]> wrote:
> Instead it just says "the working group chair(s) should also make    an
> explicit call for consensus, summarizing the technical issues and    the
> choice to be made."

A minor note, but worth noting.  Cost may not be a "technical" issue but it 
is certainly an "engineering" issue!  Some software engineers with little 
hardware experience might dismiss cost as an issue, but they can check with 
their colleagues (such as hardware engineers, mechanical engineers, etc) if 
they have ever been asked to design something without regard for the cost.

Even "legal" or "IPR" issues can be a real-world cost, or a significant 
barrier to adoption, if not a dollar amount.  Designing something in a 
vacuum to see if it works in the lab, without concern for implementation 
issues, is fun "science" but horrible "engineering".

--
Greg Connor <[email-masked]>