Re: Proposed Experiment: More Meeting Time on Friday for IETF 73

Dave Crocker <dhc2@dcrocker.net> Mon, 21 July 2008 17:18 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 7A7AB3A6ADD; Mon, 21 Jul 2008 10:18:00 -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 D967B28C0F2; Mon, 21 Jul 2008 10:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.237
X-Spam-Level:
X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
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 kdNTTB+PtclJ; Mon, 21 Jul 2008 10:17:58 -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 C974D3A6ADC; Mon, 21 Jul 2008 10:17:57 -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 m6LHITRc029224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 10:18:29 -0700
Message-ID: <4884C4E4.2000705@dcrocker.net>
Date: Mon, 21 Jul 2008 10:18:28 -0700
From: Dave Crocker <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
Subject: Re: Proposed Experiment: More Meeting Time on Friday for IETF 73
References: <20080717213322.6B3F63A68B0@core3.amsl.com> <4880653B.5040000@cisco.com> <20080718142037.A8C2434DCB2@kilo.rtfm.com> <B11F38A0EB64D3F111ABEDDE@caldav.corp.apple.com> <F41EE021-1940-4260-AE6E-5E20E0CAA037@cisco.com>
In-Reply-To: <F41EE021-1940-4260-AE6E-5E20E0CAA037@cisco.com>
X-Virus-Scanned: ClamAV 0.92/7766/Mon Jul 21 07:08:59 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]); Mon, 21 Jul 2008 10:18:29 -0700 (PDT)
Cc: iesg@iesg.org, IETF Discussion <ietf@ietf.org>
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


Fred Baker wrote:
> Let me throw in v6ops as an example. We are very efficient, I think -
>  w have 10-15 minute discussions on each of a number of drafts in our
>  time. I would often like to allow a discussion to be longer, for the
>  same reason that we meet f2f in the first place -
> 
> 
> No, cramming things in tighter isn't the solution.


Fred,

This seems to be a classic example of taking a specific counter-example
and asserting that it generalizes for the whole.  I believe it is the
single-most damaging problem with how we publicly discuss change.

Anyone promoting a point of view is going to find an example to support
it.  What we need, instead, is a sense of "typical", to use as the base
for our consideration.  Yes, we also need to consider outliers, but we
need to treat them as such.

We have working groups that are very well run.  If, indeed, v6ops is an
example -- I have no knowledge and therefore no opinion -- and if that
type of working group is typical, then your conclusions probably should
apply to this topic.  But I believe it isn't typical -- indeed, I
believe what you describe is a long way from typical -- and therefore it
shouldn't be used as a pivotal basis for formulating strategic aspects
of change.

At the least, when anyone puts forward a particular example, they need
to explain why anyone should believe that that example applies more
generally, both in terms of the group and in terms of individual
participants.  (Some don't mind hitting the weekend, others do.)

If we believe that most IETF working groups are doing productive work
and most IETF meeting time is well-used, but it isn't sufficient, then
yes we need more meeting time.

If either of these two predicates do not apply, then we do not need more
meeting time.  We need changes in how we assign and use the time already
available.


> The thing that surprises me in this discussion is, frankly, the 
> representation of it as an "experiment".

+1

> The question is whether the meetings are effective, and whether the
> Secretariat finds it easier to meet the various demands placed on it.
> I don't see how "more resources" can avoid making the Secretariat's
> job easier. The question is how we use them.

While agreeing with your last sentence, I think the rest of your 
paragraph contains the trap of assuming that more/bigger is always 
better.  I bet you don't really mean that.  For example, it does not 
make the Secretariat's job easier for them to have to work more hours...


d/


ps.  Even if we decide that the average group is not well run and
doesn't need more time, there will of course be productive, well-run
groups that do, indeed, need more time.  They should get it.  Oh, wait a
minute, they already do.  They need even more?  OK, give it to them.
Even at the expense of other wgs...

-- 

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