Re: Progressing I-Ds Immediately Before Meetings

Dave Crocker <dhc2@dcrocker.net> Sun, 20 July 2008 02:27 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6E03A6A19; Sat, 19 Jul 2008 19:27:28 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6C43A699E for <ietf@core3.amsl.com>; Sat, 19 Jul 2008 19:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Level:
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkUzxMtUBkpq for <ietf@core3.amsl.com>; Sat, 19 Jul 2008 19:27:26 -0700 (PDT)
Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 106343A6849 for <ietf@ietf.org>; Sat, 19 Jul 2008 19:27:25 -0700 (PDT)
Received: from [192.168.0.3] (adsl-68-122-70-168.dsl.pltn13.pacbell.net [68.122.70.168]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m6K2RwsH022620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf@ietf.org>; Sat, 19 Jul 2008 19:27:59 -0700
Message-ID: <4882A2AD.8040405@dcrocker.net>
Date: Sat, 19 Jul 2008 19:27:57 -0700
From: Dave Crocker <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Progressing I-Ds Immediately Before Meetings
References: <043101c8e8ec$fa67c650$0200a8c0@your029b8cecfe> <200807181819.m6IIJCIR025085@mta6.iomartmail.com> <048401c8e924$ab2ce600$0200a8c0@your029b8cecfe> <XFE-SJC-211BBtNtxy0000033b7@xfe-sjc-211.amer.cisco.com> <4881CFF5.3090008@piuha.net> <1EFD708A-8509-42A6-BBC9-824C27A7DCFA@multicasttech.com> <6BA8110C64663A4908066554@p3.JCK.COM> <48821469.4050907@employees.org> <20080719191556.567F03A6A32@core3.amsl.com> <48826DC0.8000307@dcrocker.net> <01MXCGZDHDXW000078@mauve.mrochek.com> <48828D3B.4050006@gmail.com> <01MXCL869C4K00007A@mauve.mrochek.com>
In-Reply-To: <01MXCL869C4K00007A@mauve.mrochek.com>
X-Virus-Scanned: ClamAV 0.92/7757/Sat Jul 19 15:10:41 2008 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 19 Jul 2008 19:27:59 -0700 (PDT)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.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://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


ned+ietf@mauve.mrochek.com wrote:
>> That said, exceptions should definitely be possible, and I would
>> delegate that to WG Chair level.
> 
> Well, that's a step forward, but instead of delgating an exception process
> why not delegate the authority to decide on an appropriate draft handling
> policy?


Oddly, I think it really doesn't.  By keeping the view that it is an 
"exception", it enforces a cumbersome, IETF-wide, Procrustean model with 
an exception, rather than a simple model with no need for exceptions.

Either working groups know how to run themselves on a daily basis -- 
that is, excepting real crises -- or they don't.

If they do. then we do not need one-size-fits-all-except-when-it-doesn't 
rules.  If they don't, then we need to be much, much better about 
writing and enforcing rules. (And all the evidence says that we won't be.)

As of now, we fail to enforce rules that exist and we have enforcement 
of rules that don't.  The underlying problem is that folks who are 
active in the IETF are not really all that fond of following strict rules.

Personally, I think that's a Very Good Thing.  However the persistent 
Bad Thing is that we keep pretending that we need lots of rules.

What we really need to be is reasonable, open and accountable, with 
"local" control for local activities.

Fewer rules, more working group self-management.

Oversight should be just that.  And that's quite different from 
micro-management.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf