IETF Logo Mail Archive

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

mrex@sap.com (Martin Rex) Fri, 25 January 2013 21:36 UTC

Return-Path: <mrex@sap.com>
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 815F321F885E for <ietf@ietfa.amsl.com>; Fri, 25 Jan 2013 13:36:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 hqXAkLMDUreH for <ietf@ietfa.amsl.com>; Fri, 25 Jan 2013 13:36:34 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id AC9B321F8734 for <ietf@ietf.org>; Fri, 25 Jan 2013 13:36:29 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0PLaP8R014358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Jan 2013 22:36:25 +0100 (MET)
Subject: Re: FW: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC with Running Code) to Experimental RFC
In-Reply-To: <5102A53A.8070206@cisco.com>
To: Eliot Lear <lear@cisco.com>
Date: Fri, 25 Jan 2013 22:36:24 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20130125213624.E984F1A495@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: John C Klensin <john-ietf@jck.com>, Thomas Narten <narten@us.ibm.com>, ietf@ietf.org, adrian@olddog.co.uk
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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 21:36:35 -0000

Eliot Lear wrote:
> 
> On 1/25/13 4:27 PM, John C Klensin wrote:
> >>> a WG can skip WG LC if they think its not needed.
> >>
> >> When was the last time that happened?
> >> Did it require a consensus call to determine?
>
> > Chair discretion [... and five of paragraphs of text]
> 
> None of which answered my above questions.  When was the last time
> chairs USED that discretion?!

I don't know about the last time it happened, but I know about
one time in Nov-2009 in the TLS WG (now rfc5746).

The WG chair *did* a WG consensus call before AD & WG chair short-cutted
to IETF LC.  IMHO, at the very minimum, a WG consensus call with a specific
question or choice is necessary to gauge consensus in a WG.

WG Consensus call (20-Nov-2009):
  http://www.ietf.org/mail-archive/web/tls/current/msg04571.html

AD taking over (27-Nov-2009):
  http://www.ietf.org/mail-archive/web/tls/current/msg04928.html

IETF LC (30-Nov-2009):
  http://www.ietf.org/mail-archive/web/tls/current/msg04962.html


While I was OK with skipping the WGLC, I really didn't like some
of the AD's shortcut, in particular with respect to standardizing
two methods for signaling, and his refusal to perform a consensus
call for mandating the simpler version of the signaling, which
would have significantly facilitated the creation of fixes for
the installed base.

  http://www.ietf.org/mail-archive/web/tls/current/msg05287.html


There is a REAL issue with rushing a document pointing to implementations,
when it turns out pretty quickly that what has been implemented is really
just half of a solution.  I'm actually afraid that rushing things on
the process side is going to worsen problems.

What I was slighly missing in that process was (a) leadership, in
recognizing that mandating one signaling scheme will simplify the
spec, implementations and interop effort and (b) true consensus calls
on issues that are obviously contentious.  Even running a
consensus call during / in parallel to an IETF LC is better than
blaming time-constraints and the AD infering his "desired" outcome
from prior discussions of *MUCH* broader topics. 

Process-wise, we need to be extra careful about collision of interest,
each time when short-cutting processes.

-Martin

v2.23.0 | Report a Bug | By Email