Re: Voting (again)

Dave Crocker <dhc2@dcrocker.net> Tue, 26 April 2005 16:09 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQSca-0000PP-Tt; Tue, 26 Apr 2005 12:09:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQScY-0000PD-J3 for ietf@megatron.ietf.org; Tue, 26 Apr 2005 12:09:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21805 for <ietf@ietf.org>; Tue, 26 Apr 2005 12:09:08 -0400 (EDT)
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQSp1-0000I2-Az for ietf@ietf.org; Tue, 26 Apr 2005 12:22:04 -0400
Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j3QG9lDX025797; Tue, 26 Apr 2005 09:09:48 -0700
From: Dave Crocker <dhc2@dcrocker.net>
To: Sam Hartman <hartmans-ietf@mit.edu>
X-Mailer: PocoMail 3.4 (2130) - Licensed Version
X-URL: bbiw.net
Date: Tue, 26 Apr 2005 09:08:56 -0700
Message-ID: <20054269856.124871@bbprime>
In-Reply-To: <tslzmvm2jtq.fsf@cz.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: Re: Voting (again)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Dave Crocker <dcrocker@bbiw.net>
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

(addendum)

Sam,

Additional points:



>  See above.  I just looked at section 2.6 of RFC 3774 and it does not seem
>  to discuss the sorts of problems that lead to my comment.  If I'm missing
>  something please point me at it.

I went back and reviewed that text.  It cites exactly the point I am raising 
here:

  2.6.3.  Procedural Blockages

   The current procedural rules combined with the management and quality
   roles of the ADs can lead to situations where WGs or document authors
   believe that one or two ADs are deliberately blocking the progress of
   a WG document without good reason or public justification.  

That seems pretty clear to me.

You might also want to review the I-D draft-huston-ietf-pact-00, from 2002. 

   I-D:
     <http://www.watersprings.org/pub/id/draft-huston-ietf-pact-00.txt>

   presentation:
     <http://www.potaroo.net/presentations/2002-10-30-ietf-pact.ppt>

It was produced by a group of experienced IETF participants who thought the 
problems were serious enough and long-standing enough to warrant real change.  

Unfortunately, the reaction from some of IETF management could only be called 
paranoid ("What do you REALLY want?")  So, of course, the proposal got 
derailed.

For another perspective on fixing these sorts of issues, take a look at:

 <http://www.watersprings.org/pub/id/draft-bradner-ietf-proc-ideas-00.txt>

I cite it to show that, again, these concerns are not just from one or two 
troublemakers.

As with a diverse working group, purely undirected discussion generally has 
the effect of defeating proposals, since there are always objections to any 
interesting idea.  Countering this requires disciplined management of the 
discussion, with the clear and strong goal of making real progress.  

Changes involving the IESG will only take place when the IESG takes a 
constructive role in making this happen. So far, the only change that it has 
encouraged has been to make working group chairs handle more of the 
administrative load. While that change is a good one, it has nothing to do 
with the kinds of authority changes that need to take place.

It is certainly true that working groups sometimes produce bad 
specifications.  It is therefore essential that the late-stage quality 
assurance process remain.

However the process is sometimes used for nit-picking, second-guessing, and 
personal preference. 

Since those using the process that way have a veto, this really is a 
problem.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf