Re: "IETF work is done on the mailing lists"

Eliot Lear <lear@cisco.com> Thu, 29 November 2012 09:42 UTC

Return-Path: <lear@cisco.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 A872F21F88C8 for <ietf@ietfa.amsl.com>; Thu, 29 Nov 2012 01:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.098
X-Spam-Level:
X-Spam-Status: No, score=-110.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 4mudCb4ng6yz for <ietf@ietfa.amsl.com>; Thu, 29 Nov 2012 01:42:20 -0800 (PST)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id D6A1721F8430 for <ietf@ietf.org>; Thu, 29 Nov 2012 01:42:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3742; q=dns/txt; s=iport; t=1354182140; x=1355391740; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=4K8iQZkbGSedwL3tnpHXqr17sB6OR1I9nVFCBHB6qEU=; b=hPlt8viyzXE6pVRpnB3GetLmH6kEBy3GpcmRJ4c2eNoAfOXLZ9XvOqvV 81ulL9B/zDKg3Qnpf+t2CvaVaTzwFbpO+1/uM77uPdH2hNLj6PgzyVkrn +Wm1MFoBfbRFnhzpc98j/BQuMzl03NIkdfrREz72smUmS+oNZSyXfTrdd c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai4FAHEst1CQ/khM/2dsb2JhbABEgkmDYoVftBkWc4IeAQEBAwEOFUIJBgQBBQsLBAoTFgsCAgkDAgECAUUGDQEHAQGIBgasZZJlj22BEwOWAZBEgnM
X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="10003041"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 29 Nov 2012 09:42:18 +0000
Received: from ams3-vpn-dhcp5205.cisco.com (ams3-vpn-dhcp5205.cisco.com [10.61.84.84]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAT9gH0b013386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2012 09:42:18 GMT
Message-ID: <50B72DF9.9030901@cisco.com>
Date: Thu, 29 Nov 2012 10:42:17 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Geoff Huston <gih@apnic.net>
Subject: Re: "IETF work is done on the mailing lists"
References: <CAC4RtVCogYS4tmY1LLi0C-E+B+di2_wTD0N-=AZrVR7-A8Mz+A@mail.gmail.com> <20121127231404.GC1941@verdi> <m2mwy26iud.wl%randy@psg.com> <50B63CA3.4040907@cisco.com> <D0EF612C-DFF5-4D16-BA96-F65204CC1CB2@apnic.net>
In-Reply-To: <D0EF612C-DFF5-4D16-BA96-F65204CC1CB2@apnic.net>
X-Enigmail-Version: 1.4.6
Content-Type: multipart/alternative; boundary="------------000507000401010203050705"
Cc: IETF discussion list <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: Thu, 29 Nov 2012 09:42:20 -0000

[apologies to some for duplicates]

Hi Geoff,

On 11/29/12 3:56 AM, Geoff Huston wrote:

> It's nice to have reasonably well thought out ideas come in.
>
> Which then become highly defined precepts that become incredibly resistant to IETF change on the basis that they have been well thought out already (and probably are IPR-ridden) and at that stage the IETF process is functionally reduced to rubber stamping. At that stage the value of the IETF imprimatur becomes highly dubious to the industry its meant to serve.

In my experience, when the IETF has been offered work that the other
party felt was "complete" and would refuse to allow changes to, we've
demurred (c.f., html).  On the other hand, in the instances I'm aware,
when the IETF did accept the work, it was always made clear that the
IETF had change control (and used it).  A perfect current example of
this right now is scim.  There were numerous implementations of scim,
and it was brought to the IETF not only for the imprimatur but also to
improve the work.

A simpler explanation is that the authors and editors of work are more
immersed than others, and therefore project more authority.  Certainly
that has been the case in nearly all efforts I've been involved, with a
notable exception that also is illustrative: oauth, where an editor left
the IETF precisely because he could not agree with the results.  that's
a good indication that we're striking a balance.

Eliot