Re: [Ianaplan] What's happening at ICANN?

Eliot Lear <lear@cisco.com> Mon, 19 October 2015 20:17 UTC

Return-Path: <lear@cisco.com>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D9C1A9238 for <ianaplan@ietfa.amsl.com>; Mon, 19 Oct 2015 13:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUvlXIn39pou for <ianaplan@ietfa.amsl.com>; Mon, 19 Oct 2015 13:17:54 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F209E1A9060 for <ianaplan@ietf.org>; Mon, 19 Oct 2015 13:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3228; q=dns/txt; s=iport; t=1445285874; x=1446495474; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=koJTvd6wqy89CMzfLdO3/TuVdcr6M7NZTZ7TcbEaSkU=; b=l758jIJjPG8A+050HzocqgDuzn8ue6FRdV4sYB6uJff29wsJSdpTRsSg 3y/IU2sgMxYY9XpFT/oqWPOjTo8NeVFPZUwflOS4ZYNDOPsYoJrNNIoHW 8RLTIbhGh0Mgs8Vu0yJr00fv4zs+ch2LiTs51b19AWhWhBmxWVa4tPe2Z 0=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CoBAAkTyVW/xbLJq1evmeGCYYeAoIIAQEBAQEBgQuELgEBBCNVARALGAkWCwICCQMCAQIBRQYBDAgBARCIHLFzkm0BAQEBAQEBAQEBAQEBAQEBAQEBEQmLdYQ+TweCaYFFAQSSWoNJgk6BYYhugViHPSOSYGOEBTyGGwEBAQ
X-IronPort-AV: E=Sophos;i="5.17,703,1437436800"; d="asc'?scan'208";a="607678188"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 19 Oct 2015 20:17:50 +0000
Received: from [10.61.196.70] ([10.61.196.70]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9JKHo4J021249; Mon, 19 Oct 2015 20:17:50 GMT
To: John C Klensin <john-ietf@jck.com>, John Curran <jcurran@istaff.org>, avri@acm.org
References: <56181181.50002@gmail.com> <D23F19BE.27A31A%Jonne.soininen@nsn.com> <561D47DD.2010704@acm.org> <CAF4+nEHDxq1fgAqdb5Kwe6cNn9uK5jS2+wnNVXRFpLY44+Y=4g@mail.gmail.com> <561E3BDD.4020502@acm.org> <C1018DCA-CEBF-4FE7-82A0-F9591CE38B79@istaff.org> <BDB816652A89FC266ED53495@JcK-HP5.jck.com>
From: Eliot Lear <lear@cisco.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56254FED.1020207@cisco.com>
Date: Mon, 19 Oct 2015 22:17:49 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <BDB816652A89FC266ED53495@JcK-HP5.jck.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UxuL2pheuVddTSwifVNsRmJ0vtmGNQavc"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/JdcwtVWNeNWWLP5S-Unvh8YF8bU>
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] What's happening at ICANN?
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2015 20:17:56 -0000

Hi,

On 10/19/15 3:51 PM, John C Klensin wrote:
> Yes, but there is another difference between IETF appeals and
> most of what has been contemplated for ICANN.  The IETF process
> is designed to force what other bodies call "reconsideration".
> The IESG is told to take another look and the IAB's maximum
> authority in most scenarios is to tell the IESG to look again
> and consider a specific set of issues.  The ISOC Trustees have
> more power to actually make changes and final decisions (at
> least the way some of us read the spec) but we have no actual
> experience with the use of that part of the model to conclusion
> in the 19 years since the ISOC BoT provision was introduced in
> RFC 2026.

Indeed.

The IETF moved to the current model thanks to a sequence of events that
irked the community.  The first, and seemingly small, involved a
situation in which the ETHERNET-MIB working group sent something through
for publication, and between it and the RFC-Editor, a counter width had
been changed without discussion.  At the Atlanta meeting in 1991, the
chair of the ETHERNET-MIB working group exploded that the WG's output
had been edited without their consent (and, I believe, knowledge).  A
grey bearded guy with a squirelly pony tail started screaming a
profanity in the back of the room.  Yes, that was a few people's
introduction to Jon Postel, including my own.  Anyway, that stuck in
some people's craws.

But the one that really caused change was the IAB's decision, on their
own, to choose a next generation IP.  This I affectionately call the
Kobe Kabal.  Their decision was so unpopular that what followed was a
very well known apology from Vint at Danvers, which I like to think of
as the Boston Tea Party.  Not too long after that, RFC 2026 was
introduced to specifically enjoin the IAB from making actual changes to
standards.

This is the essence of oversight.  To see, observe, and review as
requested.  To indicate agreement or disagreement with a party when
called upon to do so, but NOT to do the work of fixing what is broken in
a specification.

As John writes, other analogies break down for various reasons, but this
oversight model is actually the IETF's strength and worth reiterating
(again and again).

Eliot