Re: FW: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC with Running Code) to Experimental RFC

Spencer Dawkins <spencer@wonderhamster.org> Tue, 29 January 2013 21:35 UTC

Return-Path: <spencer@wonderhamster.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3789621F8816 for <ietf@ietfa.amsl.com>; Tue, 29 Jan 2013 13:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.699
X-Spam-Level:
X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, 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 N62AuFFDIl7R for <ietf@ietfa.amsl.com>; Tue, 29 Jan 2013 13:34:59 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD4221F855A for <ietf@ietf.org>; Tue, 29 Jan 2013 13:34:59 -0800 (PST)
Received: from [192.168.1.79] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net [99.108.174.213]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MIuiv-1TyO5E31Cr-002MhO; Tue, 29 Jan 2013 16:34:58 -0500
Message-ID: <51084076.3090907@wonderhamster.org>
Date: Tue, 29 Jan 2013 15:34:46 -0600
From: Spencer Dawkins <spencer@wonderhamster.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
Subject: Re: FW: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC with Running Code) to Experimental RFC
References: <017001cdf017$c394df00$4abe9d00$@olddog.co.uk> <50FEC0B8.8060905@isi.edu> <201301222131.r0MLVK8C015116@cichlid.raleigh.ibm.com> <84D9F6D1AE454253626C8859@JcK-HP8200.jck.com>
In-Reply-To: <84D9F6D1AE454253626C8859@JcK-HP8200.jck.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V02:K0:l4v+D2SVyImOB08vtAPEptOBjIOLmXM0xm++PV1wMPU JzxXEz0im+DwIhJzGVmg/l4qmT9GB1nnO+oEAr8Ii5X2hOHLLT hURP0CMLYiZCdunUyzR0CPvvBTVN2uL3YT4b/d8FHqHtr/wXL1 weCRcmay4QhfUOPj52JcFjbhb61keVUZGJkaY2atBEV311X1SU y/WwlYQx3ql0eBz3wrL/Ao2ej02ZyjXn5Hw+nCSqFx5k9AYMeH 6gaMpfXAjG4fqTGWaPaZLg1qnAwqpLBIOl+um3thMh6Qq6i2ut ZSVjf+dfc02rH/lHL7KqaAInTmK56Lepp49c7PaGgWGkwO5Q76 ph3bCbyYyWbHBxOCNikKwyPPVJTmheEL3bUnfjGm/
Cc: Thomas Narten <narten@us.ibm.com>, adrian@olddog.co.uk, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
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>
X-List-Received-Date: Tue, 29 Jan 2013 21:35:00 -0000

Just as a follow-up here ...

I was John's co-author on RFC 3933 (http://tools.ietf.org/html/rfc3933). 
When we were working on the draft, the problem I thought we were 
solving, was that the IESG needs to update the IETF's BCP processes from 
time to time, but (1) it was like 32 simultaneous root canals to 
actually get community consensus to modify the IETF's process BCPs 
including untried changes that might be improvements, so (2) the IESG 
was using informal IESG statements developed with much less community 
involvement than was expected for process BCP changes, in order to get 
anything done at all.

I (and, I think, John as well) saw RFC 3933 process experiments as a 
middle path between lightweight IESG decisions and full process BCP 
revisions. That's what I thought Section 2 of RFC 3933 was trying to say.

I had assumed that if the IESG clearly had discretion to do something 
under the current process BCPs, and thought it was the right thing to 
do, they would just do it, rather than set up a process experiment.

For what that's worth.

Spencer

On 1/24/2013 12:34 PM, John C Klensin wrote:
> --On Tuesday, January 22, 2013 16:31 -0500 Thomas Narten
> <narten@us.ibm.com> wrote:

>> This document seems to have a bit of missing the forest for the
>> trees. In the overall scheme of things, I don't believe the
>> draft will materially help, and is at best a distraction from
>> dealing with meaningful problems.
>>
>> The crux of the issue is that any attempt at "fast tracking" is
>> fundamentally about short-circuiting some aspect of our review
>> processes. We should only do that very carefully. In almost
>> all cases, individual judgement is needed as to when it is
>> appropriate to do that. ADs/WG chairs already have some
>> flexibility here. e.g., a WG can skip WG LC if they think its
>> ...
>
> Hi.
> First of all, I am completely in agreement with Thomas and his
> analysis.  Anything  that can reasonably and appropriately be
> done by this sort of effort can be done by discretion without
> adoption of a formal procedure and adoption of a formal
> procedure creates additional and unnecessary risks.
>
> As co-author of the process experiment model, I also object to
> its use when it is not demonstrably necessary, for example to
> give extra status and force IETF-wide use where the actions
> suggested can be carried out as a matter of normal discretion
> (see Section 5 of the document).