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

Eric Brunner-Williams <ebw@abenaki.wabanaki.net> Sat, 10 October 2015 22:56 UTC

Return-Path: <ebw@abenaki.wabanaki.net>
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 4EED21B4AB5 for <ianaplan@ietfa.amsl.com>; Sat, 10 Oct 2015 15:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.135
X-Spam-Level: *
X-Spam-Status: No, score=1.135 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] autolearn=no
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 1g2Q_6FNzXIM for <ianaplan@ietfa.amsl.com>; Sat, 10 Oct 2015 15:56:56 -0700 (PDT)
Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360FB1B4ABC for <ianaplan@ietf.org>; Sat, 10 Oct 2015 15:56:55 -0700 (PDT)
Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.15.2/8.15.2) with ESMTP id t9AMusmh044352 for <ianaplan@ietf.org>; Sat, 10 Oct 2015 15:56:54 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net)
From: Eric Brunner-Williams <ebw@abenaki.wabanaki.net>
To: ianaplan@ietf.org
References: <56181181.50002@gmail.com> <D23F19BE.27A31A%Jonne.soininen@nsn.com> <56196F4D.3080801@gmail.com>
Message-ID: <561997B6.4010401@abenaki.wabanaki.net>
Date: Sat, 10 Oct 2015 15:56:54 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <56196F4D.3080801@gmail.com>
Content-Type: multipart/alternative; boundary="------------030705080607070309040802"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/udu50bmHUCM6bBMVt61xNwZihRg>
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: Sat, 10 Oct 2015 22:56:58 -0000

Plus N for JCK's note, and ...
> [snip]
> So, the topic is ICANN accountability. The claim is that as long as there
> was the NTIA contract on IANA there has been a backstop on ICANN's
> decisions, especially the board's.

Well, that is one of the consequences of the NTIA's delegation of rule 
making authority. Another is found in references made by 3rd parties, 
here a court considering some claim, which wrote "This is a perfectly 
logical decision, and one that ICANN, through its contract with the DoC, 
had full authority to make." [1] Absent the third clause, a perfectly 
logical decision requires some other source of authority in order to be 
made.

>                                      The theory is that if ICANN (the staff
> and the board, not the community) would do something silly NTIA could at
> least threaten to take IANA away and pressure ICANN to reconsider the
> decision get to the right path. However, with the IANA stewardship
> transition there would be no backstop anymore and potentially a future
> board could go rogue and do whatever they want disregarding the community.
> Therefore, there needs to be new accountability mechanisms.

Well, IIRC, the NTIA wasn't concerned with Mad Max scenarios, but it did 
ask for improved accountability, as it has pretty much for years, see 
the AoC.
> The main accountability mechanisms discussed have been spilling the
> complete board, removing a board member and control/veto the ICANN budget
> and bylaws changes.

True, the "accountability mechanisms" vigorously championed by various 
actors within the CCWG, for possibly divergent reasons, are removal of 
all or some of the Board, and inter alia, were the Board "spilled", the 
NomCom would seat a majority of the next Board, so one "mess" leads to a 
worse "mess" (since when was the NomCom "accountable"? and to whom?). To 
further mess things up, the potential for SO and/or AC selected members, 
but not NomCom selected members, to be removed for SO and/or AC defined 
"cause", would create two classes of Board member -- those who vote 
without risk of removal, and those who risk removal, for SO and/or AC 
specific cause, and who therefore may not act in the interests of the 
Corporation as a whole, but rather as conflicts of SO and/or AC 
interests allow. Finally, the meta-proposal requires some form of 
"membership" -- a problem we attempted circa 2002 in the Membership 
Implementation Task Force and found absolutely intractable: Who could be 
a "member of ICANN"? Who could not be a "member of ICANN"? The 
"work-around" is simply to recast the " group of participants that 
engage in ICANN's processes to a greater extent than Internet users 
generally" [2] as a "single member".


> There is pretty much consensus that in some form or
> another these are reasonable requirements.

As the CCWG is structured as "members", selected by SO and AC bylaws 
entities, the parties who might form some "consensus" need not include 
"observers", contributors who are not selected by SO and AC bylaws 
entities.

> However, the discussion is
> about what is the right enforceability mechanism. Enforcement means how
> can you legally enforce ICANN/board do something - basically, how can you
> sue ICANN if the board/staff doesn't do what the community expects it to
> do.

The enforcement mechanism argued by the various actors within the CCWG 
presupposes "members", which California corporations law allows to 
remove the Board, or accept the delegation of some specific Board 
responsibility, which has the unsought side effect that while some 
responsibility is delegated, the fiduciary responsibility may not be 
exercised by any party.
>
> In the IETF, we have a bit different approach to these things. I wouldn't
> think we would have ever the discussion the IETF community should be able
> to take the IESG or IAB to court. Interesting thought, though... ;)

What we do as individual contributors to an open standards organization 
which has no "members" and no "secret handshakes" has wicked little to 
do with how a California Corporation may be improved in its execution of 
the notice and comment responsibilities, aka "transparency and 
accountability", delegated to it by an agency of the federal government.

Eric Brunner-Williams
Eugene, Oregon

[1] https://www.icann.org/news/announcement-2-2015-07-31-en
[2] 
https://www.icann.org/resources/pages/affirmation-of-commitments-2009-09-30-en