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

John C Klensin <john-ietf@jck.com> Mon, 19 October 2015 13:51 UTC

Return-Path: <john-ietf@jck.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 BDD3A1A6F0A for <ianaplan@ietfa.amsl.com>; Mon, 19 Oct 2015 06:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3
X-Spam-Level: ***
X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] 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 gJIA_hcBNyyB for <ianaplan@ietfa.amsl.com>; Mon, 19 Oct 2015 06:51:47 -0700 (PDT)
Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEAE1A6EED for <ianaplan@ietf.org>; Mon, 19 Oct 2015 06:51:47 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ZoAqk-000GiL-CN; Mon, 19 Oct 2015 09:51:42 -0400
Date: Mon, 19 Oct 2015 09:51:41 -0400
From: John C Klensin <john-ietf@jck.com>
To: John Curran <jcurran@istaff.org>, avri@acm.org
Message-ID: <BDB816652A89FC266ED53495@JcK-HP5.jck.com>
In-Reply-To: <C1018DCA-CEBF-4FE7-82A0-F9591CE38B79@istaff.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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/B9mHb8TiJYEOFwx63C4SMsmE0SM>
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 13:51:48 -0000


--On Sunday, October 18, 2015 7:23 AM +0100 John Curran
<jcurran@istaff.org> wrote:

> On Oct 14, 2015, at 12:26 PM, Avri Doria <avri@acm.org> wrote:
>> ...
>> All I was trying to say was IETF had a binding appeals tracks
>> that ICANN does not have.
> 
> Indeed.   The appeals process is rather logical, allowing for
> appeal regarding whether the Internet standards procedures
> were properly followed, and (in the  extreme case) appeal to
> the ISOC Trustees "only in cases in which the procedures 
> themselves are claimed to be inadequate or insufficient to the
> protection of the  rights of all parties in a fair and open
> Internet Standards Process."   
> 
> Such clarity of role might be helpful in the names community
> processes...

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.

The proposed ICANN model seems to be much more focused on
adjudication by higher authorities, which was considered
inappropriate for the IETF, in part because community consensus
is very hard to measure in controversial situations.  One
reading of the CCWG proposal is that they propose to solve that
problem by the time-honored position of declaring themselves
(pre-captured by part of the community) to be in charge and
representing everyone else.  

Another difference is connected to the reason I think that,
while ICANN procedures can draw inspiration from IETF ones,
almost all further analogies do not work.  In the IETF, at least
partially because of the technical underpinnings of much of our
work, there is general agreement on criteria by which success
can be judged.  It is only when we start adjusting our own
procedures to reflect social norms (e.g., recent anti-harassment
and perhaps privacy discussions) that consensus about success
criteria start breaking down.  By contrast, disagreements about
what are ultimately success criteria are the norm in ICANN,
especially in names-related areas.  Is it better to block a
potentially-risky identifier or to allow it in the interest of
competition and "what someone wants to do"?   Is it better to
use the DNS's administratively distributed hierarchy to allow
(or even encourage) localization and diversity or to force
uniform rules to reduce the risks inherent in user confusion?
Is it better to keep the root zone small, perhaps thereby
encouraging deep hierarchy, or to make a very broad root in the
interest of competition (or greater profits)?  None of those
questions have completely objective answers; one has to start
with a particular perspective and set of preferences and then
try to reason from it.

Similarly, if the IETF community becomes sufficiently concerned
about the behavior or performance of an individual or group of
individuals, we have a recall procedure.  Again, it has not been
fully carried out to the point of removing someone in circa 20
years.  The only time we ever came close involved absence and
non-performance, not malfeasance or ignoring the clear will of
the community.  In addition, out of fear of DoS attacks and
frivolous actions, we have made that procedure nearly impossible
to use, again evidenced by our failure to use it in even some
fairly egregious cases.  One can imagine, given the frequency
with which disputes arise, various dispute resolution procedures
are applied that leave almost no one happy. and almost as
frequent debates about whether "bottom up" (however narrow or
captured the bottom) means that the Board is obligated to accept
whatever comes to it or whether it is a final source for
consideration of cross-ICANN-community (or broader Internet
community) issues, much as the IESG is expected to encourage and
enforce cross-area review.  That set of differences, especially
coupled with recent ICANN history, suggests that a Board that
actually tried to exercise judgment and  consideration of broad
community needs and tradeoffs would be removed frequently if
procedures made that easy (as the CCWG recommendations appear to
do).

Back to lurking... and wondering whether we (and maybe NTIA) are
asking the wrong questions.

   best,
     john