Re: Call for review of proposed update to ID-Checklist

"Spencer Dawkins" <spencer@wonderhamster.org> Wed, 13 August 2008 18:13 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 E5ED128C173; Wed, 13 Aug 2008 11:13:06 -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 8D89F28C173; Wed, 13 Aug 2008 11:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.369
X-Spam-Level:
X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001]
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 b5+B-TpOb28y; Wed, 13 Aug 2008 11:13:04 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 9364E3A6A80; Wed, 13 Aug 2008 11:13:04 -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-1KTKqG0ZMp-0003Wb; Wed, 13 Aug 2008 14:13:06 -0400
Message-ID: <0ed001c8fd70$55714430$ad600240@china.huawei.com>
From: Spencer Dawkins <spencer@wonderhamster.org>
To: ietf@ietf.org
References: <D78EAB64AF674E24B2199B2C1DBDA1FE@BertLaptop> <489F13F2.3060707@dcrocker.net><6F1B41ACCFC0441E8E86CD61B5874A02@BertLaptop><48A0626E.8060507@dcrocker.net><98CA2246DD534DCBBF7FEE196F833AC8@BertLaptop> <48A31FF9.2080700@dcrocker.net>
Subject: Re: Call for review of proposed update to ID-Checklist
Date: Wed, 13 Aug 2008 13:13:46 -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/7UkQGDQLW6nKUF+CGkEWQYaHBRXuryfeW5HH p1iXi47FVAN88CFvpL9jaU+xx5zw58dgirgPQP2+H6nIbF6IlG 2OmVF8NNsh8GOuYLnFbJ19HM1MF+jgYd5akFTra8j8=
Cc: iesg@ietf.org
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

Hi, Dave,

> While it is vastly more convenient, for the IESG, to have it take 
> initiative and
> decide on its own to make a more strict rule and issue it in a document 
> that
> does not go through public vetting, it isn't the way things are supposed 
> to be
> done in the IETF.

Just to ring one of the changes here...

I'm actually OK with the process that Dave is not OK with, because I'm 
assuming that "public vetting" can also be retroactive - as long as the IESG 
announces rules publicly, I trust the community to point out problematic 
rules with great enthusiasm, and trust that the IESG will not go into 
"because we said so" mode when someone does point out that a new rule is 
problematic.

If my trust is misplaced, we have bigger problems than process changes, I 
think.

> If the IESG is now responsible for inventing IETF policy, that ought to be
> acknowledged and documented explicitly.

One of the many contortions we went through on process change was trying to 
distinguish between policy and procedure. Our "current"(?) process BCPs 
don't make this distinction well.

I'm totally good with the IESG inventing IETF *procedures*, and that's what 
I think most of the ID checklist is. I would not be good with the IESG 
inventing IETF *policy* without community involvement, but that's not what I 
think is on the block.

Unannounced rules ("double SECRET probation") would be a problem, but I 
don't see anyone arguing in favor of undocumented late-surprise barriers.

Thanks,

Spencer 


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