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

Seth Johnson <> Wed, 14 October 2015 12:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B26541A1BCB for <>; Wed, 14 Oct 2015 05:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eXdIoDmHyzQw for <>; Wed, 14 Oct 2015 05:34:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FD3B1A1BDE for <>; Wed, 14 Oct 2015 05:34:14 -0700 (PDT)
Received: by qgx61 with SMTP id 61so40705072qgx.3 for <>; Wed, 14 Oct 2015 05:34:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=X5MvJi5amxrobRWqy/Ru53IEZA3mQoOmfWWqXKtpMsA=; b=W2hXE5Ee31bOHzRuCq/FfIlx2hrMp6TvCpEfwSzYQdExK8OrNTXgxJtspZelWz+3mz 9MGNqrwVwrt7QKSQOGt7L6DzIEfl2w4bouIcmCDMjW4/JwXbIRb2KV+c9CQ2i7ei5boU hNxBpyRwhmiTufg/wJjhX1trlhd/epSl6TnYQDMYkcP8xqDFvpCI5TPvssDWubM8L2GA Dh5dlUeYM4F/7k+zLz875T4eem9wSFcpupC+/zHTKYbr2Xe9NAF5WJG43hFB3AmrD1bm roPVhZSqr05xIMl1IGQ4CygChdDVQuRr3gm+rcJG9Cgl+9J3tzxTxO2dZb1MVh0Fu0av FjaQ==
X-Received: by with SMTP id e77mr3737714qhc.27.1444826053507; Wed, 14 Oct 2015 05:34:13 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 14 Oct 2015 05:33:33 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Seth Johnson <>
Date: Wed, 14 Oct 2015 08:33:33 -0400
Message-ID: <>
To: Avri Doria <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "Ianaplan@Ietf. Org" <>
Subject: Re: [Ianaplan] What's happening at ICANN?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Oct 2015 12:34:23 -0000

IETF has also been able to emphasize a stance more about "technical
merits" whereas ICANN deals with areas that are more relatable to

Indeed, that distinction is why the naming portion of the IANA
transition has been characterized as more problematic in the
transition.  (However, that's an illusion, as will become evident in
due course.)

Here's the key to this though: the "more technical" areas have had the
ability to operate in that way because they are in a stewardship
context where governmental inroads have been proscribed.  The NTIA
"backstop" is related to that stewardship context in the following
ways: 1) it has afforded a focal point for "normal" politicking, a
place to lobby if ICANN were to start doing things we don't like in
our ("exceptional" US) environment, plus i2) t has meant the US
government was involved, so -- by a hairy process, because we do allow
private corporations to do things, even for the government, that our
government is not allowed to do -- there might be some prospect of
suing the government if it had allowed a circumstance to arise where
ICANN allowed intergovernmental policy to invade our fundamental

We haven't done a lot in either of those avenues, though ICANN has
occasionally gotten into problematic areas.  But 1) that's because
within the US the government does avoid meddling in fundamental
rights, especially in communications areas -- our systems of recourse
function that way so we hardly have to think about how we take our
rights for granted; and 2) the relation to the US also just gives us a
general sense of operating in that context.

The thing the "more technical" folks don't get is that removing the US
and privatizing doesn't simply privatize -- it puts us in the
intergovernmental context.  That means as long as our various own
governments keep acting like we're accustomed, we won't see a
difference.  But as soon as the intergovernmental frame is in place
and our own governments choose to lay claim to that legal basis, it
will "simply apply," and, for instance, ICANN won't be in any sort of
position to stand against intergovernmental pressure.  GAC's role will
be very different -- even without changing anything structurally in
ICANN.  Neither will the IETF.

There's a fundamental failure to understand that there's huge change
in the nature of the context involved in the transition -- and that
will affect even areas besides the naming functions to which we've had
our attention directed.  The tech community's general orientation
toward "just not changing the way we've done things" is actually
keeping them from confronting the nature of the change.


On Tue, Oct 13, 2015 at 2:05 PM, Avri Doria <>; wrote:
> Hi,
> One essential difference is that IETF has an appeal mechanism on process
> to the Internet Society Board of Trustees.
> This is the backstop for the IETF.
> >From what I have learned in the ICANN Accountability process, the most
> legal training I have ever had, the IETF as the IETF might have trouble
> suing anyone given that is is not a legal person.  Fortunately the IETF
> does not live in an environment where suits, of either kind, are the norm.
> avri
> On 10-Oct-15 12:57, Soininen, Jonne (Nokia - FI/Espoo) wrote:
>> Hi Brian,
>> like Bernard and Dave said, part of the story is the press tries to spin
>> an interesting story. Partly the story is that there are strong emotions
>> in play at the ICANN in this topic.
>> 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. 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.
>> The main accountability mechanisms discussed have been spilling the
>> complete board, removing a board member and control/veto the ICANN budget
>> and bylaws changes. There is pretty much consensus that in some form or
>> another these are reasonable requirements. 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.
>> 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... ;)
>> I hope this helps.
>> Cheers,
>> Jonne.
> ---
> This email has been checked for viruses by Avast antivirus software.
> _______________________________________________
> Ianaplan mailing list