Re: WG Charter Milestones

Jeffrey Hutzelman <jhutz@cmu.edu> Mon, 04 July 2011 03:42 UTC

Return-Path: <jhutz@cmu.edu>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC4D1F0C43 for <wgchairs@ietfa.amsl.com>; Sun, 3 Jul 2011 20:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qovpuIr5YY56 for <wgchairs@ietfa.amsl.com>; Sun, 3 Jul 2011 20:42:10 -0700 (PDT)
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 472B31F0C39 for <wgchairs@ietf.org>; Sun, 3 Jul 2011 20:42:10 -0700 (PDT)
Received: from [128.2.184.182] (JHUTZ-DYN5.PC.CS.CMU.EDU [128.2.184.182]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p643g6x3027049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Jul 2011 23:42:07 -0400 (EDT)
Subject: Re: WG Charter Milestones
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <15059_1309559056_p61MOFVT031343_8FA52682-6B97-4DEC-A8D6-B766612A66C1@vpnc.org>
References: <79E2D726-5079-4CA4-96EE-D55471D50A09@vigilsec.com> <25548_1308673188_p5LGJhFF011820_BD798D7C-1B0E-4BDE-9783-944E6FE8A522@cisco.com> <1309298392.30670.105.camel@destiny> <AB9282C0-3A6D-435B-9B04-171373FC3ED4@vpnc.org> <0c8a01cc3768$a4977ea0$edc67be0$@olddog.co.uk> <48D006AB-1F30-43F2-A15D-0BBA924CA99B@vigilsec.com> <21757_1309470211_p5ULhUbn028276_9780C759-8F99-4E57-8154-02F5854D2298@nostrum.com> <1309554609.7830.26.camel@destiny> <15059_1309559056_p61MOFVT031343_8FA52682-6B97-4DEC-A8D6-B766612A66C1@vpnc.org>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 03 Jul 2011 23:42:08 -0400
Message-ID: <1309750928.3597.25.camel@destiny>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on 128.2.217.198
Cc: IETF WG chairs <wgchairs@ietf.org>
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/wgchairs>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jul 2011 03:42:11 -0000

On Fri, 2011-07-01 at 15:24 -0700, Paul Hoffman wrote:
> On Jul 1, 2011, at 2:10 PM, Jeffrey Hutzelman wrote:
> 
> > The change we're discussing is to get the human secretariat staff out of
> > the loop, on the grounds that they already have too much to do and that
> > latency on these sorts of operations will be lower if they don't have to
> > wait to reach the top of someone's work queue.
> 
> That is not, in fact, the grounds on which we are making the change. I
>  apologize if the introduction to draft-ietf-genarea-milestones-tool
>  didn't make that clearer. What it currently says is:


> That is, this is not about "too much to do" or "latency"; it is simply
>  about more automation.

You're right; I made an inference.  "More automation" is generally not
an end-goal; it's usually a means to some other end like saving labor,
improving performance or reliability, etc.



> With the model as it is currently described, an
>  AD gets to decide how much to maximize the automation. He or
>  (historically) she can set it to 10 for a WG by allowing the chairs to
>  do all the steps without AD approval, or set it to 8 by requiring AD
>  approval. (Having this all be done in the web pushes it well past the
>  "hopefully the email gets read" automation of today.)

That's fine.  I was simply trying to reject the notion that this is a
policy change.  Just because the tool is configured to allow a chair to
make a change without the AD going in and telling the tool it has been
approved, does not mean that it is appropriate for the chair to make a
change that has not in fact been approved.

> In fact, the draft is mostly silent on this. The draft says "Any AD can
>  add or update any milestone for any WG", and the unstated intention is
>  that if a WG chair makes a change that an AD disagrees with, the AD
>  can reverse the change. That is quite different than "not effected
>  until approved by an area director".

Yes, it is.  But, if the policy is that milestone changes must be
approved by an AD, then the "change" that chair made wasn't a change to
the milestones; it was a change to the records, with the effect of
creating an incorrect record (or, alternately, a correct record of an
incorrect assertion).  Of course, as Russ already pointed out, it is
this very property, plus the ease of reversing changes, that makes it
reasonably safe to give the chair the ability to enter that change in
the first place.

That, and the fact that we expect WG chairs to behave reasonably most of
the time.  Well, I do, anyway.  Perhaps the rest of the IETF has less
confidence in the fitness of its WG chairs for their positions.


Again, I'm merely rejecting the notion that the tool is the policy, and
that therefore deploying a tool which could make it _possible_ for a
chair to do something counter to the present policy is equivalent to a
policy change which gives him the _authority_ to do so.

-- Jeff