Re: Progressing I-Ds Immediately Before Meetings

"Spencer Dawkins" <spencer@wonderhamster.org> Sun, 20 July 2008 13:10 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 B27EA3A6A33; Sun, 20 Jul 2008 06:10:19 -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 8ABE13A689B for <ietf@core3.amsl.com>; Sun, 20 Jul 2008 06:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.869
X-Spam-Level:
X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.730, 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 qZquaW0VPOTz for <ietf@core3.amsl.com>; Sun, 20 Jul 2008 06:10:17 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by core3.amsl.com (Postfix) with ESMTP id 4E2293A6A33 for <ietf@ietf.org>; Sun, 20 Jul 2008 06:10:17 -0700 (PDT)
Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KKYgf0ZD0-0005gC; Sun, 20 Jul 2008 09:10:54 -0400
Message-ID: <013501c8ea6a$271e28a0$6501a8c0@china.huawei.com>
From: Spencer Dawkins <spencer@wonderhamster.org>
To: ietf@ietf.org
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> <4882A2AD.8040405@dcrocker.net>
Subject: Re: Progressing I-Ds Immediately Before Meetings
Date: Sun, 20 Jul 2008 08:11:40 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Provags-ID: V01U2FsdGVkX1/HyIBcKk3LkhoG5tmd7oFzzazBUE1015vTDt1 N4Yg+m5kiYh/fYfz8QsVcbgjlJZayArDiGXPS9AnIEj/cQRtD7 afMbMeCOAKsItGa1u4JhXCsbTfFr2jlgcXtq4CgT+Y=
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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

I guess I have a tendency to local-optimize when I post here, so the 
conversation has broadened enough that it's worth sending a clarifying 
note...

Where I chimed in, in this thread, was on a specific problem - want to have 
exceptions for drafts that would be advanced - not discussed in the 
meeting - if we could submit them, but we couldn't submit them, and it would 
require tools development to automate exception handling.

My local optimization was to stop enforcing a rule that seemed to be 
leaking, and required AD intervention for exceptions. I've spent almost 
every Thursday for more than two years listening to ADs do AD work on 
telechats. They seem busy.


I don't actually mind a two-week cutoff (it's in 2418). The relevant text in 
2418 says

7.1. Session documents

   All relevant documents to be discussed at a session should be
   published and available as Internet-Drafts at least two weeks before
   a session starts.  Any document which does not meet this publication
   deadline can only be discussed in a working group session with the
   specific approval of the working group chair(s).  Since it is
   important that working group members have adequate time to review all
   documents, granting such an exception should only be done under
   unusual conditions.  The final session agenda should be posted to the
   working group mailing list at least two weeks before the session and
   sent at that time to agenda@ietf.org for publication on the IETF web
   site.

So I don't know where the "must have AD approval for exceptions" thing came 
from, unless it's a misplaced need to have ADs approve everything.

If ADs do discover copious and uncharted spare time, I would MUCH prefer 
that they spend it steering their working groups, and specifically noticing 
milestone offsets so we can move away from the current situation, where many 
so many milestones are expressed in terms of ID cutoffs for the next 
meeting, more than half the updates are posted within two weeks of the ID 
cutoff, and we're floundering through the drafts getting ready for the 
meetings.

I am particularly irritated when I see a draft that I submitted comments on 
immediately after the last IETF meeting (which was a long time ago), updated 
for the first time within a week of the ID cutoff for the next meeting. This 
does not give us timely publication - we can't even remember what we were 
talking about, in some cases.

I do, of course, appreciate working group chairs that do stagger their 
milestones, and I do, of course, wish that Eric and I thought about this 
more often in mediactrl.

I hope this is clearer than what I posted, as a local optimization, earlier. 
I'm not opposed to global optimization.

Thanks,

Spencer

> 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
> 


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