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

Loa Andersson <loa@pi.nu> Fri, 25 January 2013 10:54 UTC

Return-Path: <loa@pi.nu>
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 61DDC21F8795 for <ietf@ietfa.amsl.com>; Fri, 25 Jan 2013 02:54:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.048
X-Spam-Level:
X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, 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 vBigS6WUcxXY for <ietf@ietfa.amsl.com>; Fri, 25 Jan 2013 02:54:16 -0800 (PST)
Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id ABB5721F8759 for <ietf@ietf.org>; Fri, 25 Jan 2013 02:54:12 -0800 (PST)
Received: from [192.168.1.104] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 5A80F823B5 for <ietf@ietf.org>; Fri, 25 Jan 2013 11:54:09 +0100 (CET)
Message-ID: <51026457.9000108@pi.nu>
Date: Fri, 25 Jan 2013 11:54:15 +0100
From: Loa Andersson <loa@pi.nu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ietf@ietf.org
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$@olddog.co.uk><50FEC0B8.8060905@isi.edu> <201301222131.r0MLVK8C015116@cichlid.raleigh.ibm.com> <00b801cdfae3$1918fa80$4001a8c0@gateway.2wire.net>
In-Reply-To: <00b801cdfae3$1918fa80$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Fri, 25 Jan 2013 10:54:17 -0000

Folks,

I'm very much on the same page as Tom, the normal problem we have
is not too much review, it is that we don't have enough.

Running code is valuable, but does not normally replace review.

/Loa

On 2013-01-25 11:02, t.p. wrote:
> ----- Original Message -----
> From: "Thomas Narten" <narten@us.ibm.com>
> To: "Joe Touch" <touch@isi.edu>
> Cc: <adrian@olddog.co.uk>; <ietf@ietf.org>
> Sent: Tuesday, January 22, 2013 9:31 PM
>> FWIW, I share Joe's concerns. And Stephen's responses don't really
>> change my mind.
>>
>> 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.
>
> I agree.  This proposal asks the ADs and WG Chairs to do more work and I
> perceive lack of resouces in that area to be the single biggest reason
> for I-Ds to fail to progress as fast as they might.  Putting more load
> on the critical path can only make things worse, for the work as a
> whole.  Some favoured I-Ds will progress faster but overall, RFCs will
> take longer to appear.
>
> In this vein, I have commented before how progress in the IETF tends to
> take place in three bursts, in the course of each year, and that if only
> we had a way of bringing the three pauses to life, then progress would
> be much improved.  Quality would almost certainly also improve, since
> data would not get lost or forgotten in the pauses.  This month, most WG
> mailing lists seem to be in a mega-pause (I keep checking the archives
> to see if I have been accidentally unsubscribed!): that is the real
> problem.
>
> Tom Petch
>
>> 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 not needed.  And nothing stops an AD from
>> going to WGLC before doing a careful review. But I'd rather that be
>> done because the case at hand justifies such an optimization, not
>> because there is some "running code" checkmark that allows a special
>> case to be fast tracked..
>>
>> This document risks substituting process for judgement. I'd rather see
>> more of the latter and less of the former.
>>
>> Some specifics from the doc:
>>
>>>     In summary this experiment collapses three stages of the
> publication
>>>     process to run concurrently: working group last call, AD review,
> and
>>>     IETF last call.  Additionally, the experiment will only require
>>
>> IMO, it is almost never appropriate to collapse WG LC and IETF LC. In
>> cases where it is appropriate to do so, there presumably isn't a need
>> for a WG LC to start with.  And an AD has always been able to start an
>> IETF LC without doing a detailed review. The point, is judgement is
>> needed, and all such cases are best handled on a case-by-case
>> basis.
>>
>> Surely, we don't need a document to justify doing this in those cases
>> where it makes sense...
>>
>>>     IETF last call.  Additionally, the experiment will only require
>>>     issues raised during these three stages to be addressed if they
> meet
>>>     the IESG's Discuss criteria.  The former is not formally a
>>>     process
>>
>> and later:
>>
>>>     4.  Only comments that would be "DISCUSS-worthy" according to the
>>>         IESG Discuss Criteria [DCRIT] need be handled during last
> call.
>>>         Other comments can be handled or not, at the authors/editors
>>>         discretion.
>>
>> The above can easily become a way to dismiss legitimate review
>> comments. No doubt, when a AD or reviewer suggests "this needs
>> fixing", the proponents will hold up this document and say "you
>> shouldn't do this, per the RFC -- you're violating the spirit of this
>> document, only really really critical stuff needs to get addressed..."
>> No thanks. That is not what the IETF is about.
>>
>> If it is really urgent to get a document done, it is far better to
>> take steps to make sure the editors are engaged and responsive. That
>> is more likely the real issue!!!
>>
>>>     It is understood that the savings in time for the end-to-end
> delivery
>>>     of a proposed standard or experimental RFC may be modest,
> however,
>>>     the modifications to normal IETF process will also serve as an
>>>     indication of the importance that the IETF places in running
> code.
>>
>> Running code is valuable. Always has been, always will be. But we need
>> to resist the temptation of making "running code" more equal than
>> other criteria or putting it on a pedestal as some sort of holy
>> grail. Running code by itself is just a sound bite. The importance of
>> running code is what it tells us about a protocol specification. Just
>> the mere fact that there is running code doesn't mean there is
>> anything particularly enlightening to learn from an
>> implementation. For example, "running code" of a router function in
>> software doesn't necessarily say anything as to whether the code can
>> be implemented efficiently using ASICs, which may be the real
>> requirement.
>>
>>>
>>>     5.  The responsible AD for the WG concerned makes the decision as
> to
>>>         whether changes are required as a result of review comments,
> and
>>>         determines whether or not those have been completed.  If
>>>         significant change or extended discussion is required, or if
>>>         changes are not complete within two weeks after the end of
> fast-
>>>         track last call, then the draft is returned to the WG by the
>>>         responsible AD and the document is withdrawn from the
> experiment.
>>
>> The two week figure is too stringent. The above is too prescriptive to
>> be practical. For starters, how will the IESG telechat align with the
>> ending of LC? Or what if an IESG member issues a defer (or will those
>> be disallowed?).
>>
>> Section 4 has a bit too much detail and process in it. I'm sure it has
>> both too much and too little actually. I.e., it probably misses some
>> corner cases, and then what do you do given how prescriptive the rest
>> of the section is?
>>
>> But overall, I see this document at best as a no-op. However, I fear
>> that it can be used to short-circuit our review processes in a way
>> that doesn't help the IETF and that won't really speed things up
>> enough to justify the downsides.
>>
>> Thomas
>>
>>
>
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
MPLS Expert                                 loa@pi.nu
Huawei Technologies (consult)        phone: +46 739 81 21 64