ietf-mxcomp
[Top] [All Lists]

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

2004-10-27 06:42:58

Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote:
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.

  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.

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. 

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

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

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

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. 

  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.


<Prev in Thread] Current Thread [Next in Thread>