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

Stephen Farrell <> Fri, 25 January 2013 13:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B57021F854F for <>; Fri, 25 Jan 2013 05:07:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.953
X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wl+38ql+cyt2 for <>; Fri, 25 Jan 2013 05:07:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9294021F853E for <>; Fri, 25 Jan 2013 05:07:33 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2F95BE62 for <>; Fri, 25 Jan 2013 13:07:10 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y20c23at8QQV for <>; Fri, 25 Jan 2013 13:07:09 +0000 (GMT)
Received: from [IPv6:2001:770:10:203:810d:eba8:c654:6e65] (unknown [IPv6:2001:770:10:203:810d:eba8:c654:6e65]) by (Postfix) with ESMTPSA id 5377FBE65 for <>; Fri, 25 Jan 2013 13:07:00 +0000 (GMT)
Message-ID: <>
Date: Fri, 25 Jan 2013 13:07:00 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
Subject: Re: FW: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFCwith Running Code) to Experimental RFC
References: <017001cdf017$c394df00$4abe9d00$><> <> <00b801cdfae3$1918fa80$> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Jan 2013 13:07:37 -0000

Responses to some points below but I'd really like to ask
people to consider a few things here:

- what's proposed is an experiment, it'd likely get tried out
  a few times and won't consume any huge resource anywhere
- its optional, WG chairs that want to try it could, those
  that don't can just ignore the whole thing
- argument that there are other or better process issues to
  address is misdirected
- on a meta-level, if every process proposal, even small
  experiments like this, generates huge concerns then we're
  not in a good place and it seems to me that we are in that
  bad place (that's not an argument to do this experiment,
  but just an observation)

On 01/25/2013 10:54 AM, Loa Andersson wrote:
> Running code is valuable, but does not normally replace review.

This proposal doesn't "replace review." Its an optional way
to get some of that done in parallel with a few other rule

On 01/25/2013 10:30 AM, Brian E Carpenter wrote:
> Speaking as a Gen-ART reviewer, I am indeed worried by this aspect.
> I feel I would have to spend much longer reviewing a draft if I
> knew it had not been through WGLC.

Its an experiment that would be used for a few drafts, your
concern might be justified if this were proposed as a
permanent change (it's not) that applied to many drafts (it
won't ever IMO, but certainly not during the experiment).

On 01/25/2013 10:02 AM, t.p. wrote:
> This proposal asks the ADs and WG Chairs to do more work

It does not. WG chairs *choose* to take this route if they
want to. The timers and checking the implementation could
increase the workload for the responsible AD at a time not of
her choosing and its the timing that's more pertinent but not
so bad since ADs are already clearly gullible enough when
it comes to additional workload:-)

On 01/24/2013 06:34 PM, John C Klensin wrote:
> As co-author of the process experiment model, I also object to
> its use when it is not demonstrably necessary,

That's a really weird objection. I just re-read 3933 and it
says nothing whatsoever like that, in fact it says 'This
specification permits and encourages the IESG to adopt and
institute "process experiments"...' and the whole tenor of
the RFC is that stuff ought be tried out.

John also said:

> this document moves a number of informal IESG
> procedures -- including the DISCUSS criteria and even the
> Shepherd report requirements (now Informational in RFC 4858 plus
> a number of less formal "statements" and "templates" that have
> sometimes changed rapidly) -- into the status of formal
> procedural requirements

That's just wrong. It includes those as part of an experiment
that is optional to use which I don't think qualifies as
"formal process requirements" in any useful sense.

And lastly...

> In my experience in the IETF, we almost
> never allow a individual submission document that is obviously
> very controversial to turn into a extended debate on the IETF
> list with the author trying to refute every comment.

"Trying to refute every comment" is (IMO wildly) inaccurate.
This was proposed a couple of months ago. Some people liked
the idea of trying it out, others didn't. I'm following up
on that as described in 3933. Every proposal to do with
process seems this controversial unfortunately, even teeny
little ones like this. I'd love if it were otherwise.

And if Adrian or the IESG decide we should not go ahead and
try this particular experiment, that's just fine and the
world will not end. (And nor will it end if this experiment
is run.)

What's less fine, but I suspect is also the case, is that
any proposal for process change would get the same kinds
of negative reception from a similarly sized set of folks
and with similarly good, bad and irrelevant arguments
against whatever change or experiment is proposed.