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

Seth Johnson <seth.p.johnson@gmail.com> Mon, 19 October 2015 16:52 UTC

Return-Path: <seth.p.johnson@gmail.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 192851A8A75 for <ianaplan@ietfa.amsl.com>; Mon, 19 Oct 2015 09:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ap-y_gMqjG4g for <ianaplan@ietfa.amsl.com>; Mon, 19 Oct 2015 09:52:14 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98EBA1A8988 for <ianaplan@ietf.org>; Mon, 19 Oct 2015 09:52:14 -0700 (PDT)
Received: by qgem9 with SMTP id m9so14118099qge.1 for <ianaplan@ietf.org>; Mon, 19 Oct 2015 09:52:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ITiNa7aYG/tgWjMob/vZDIrURH9S9adAoStOuH2Ye7I=; b=YoRc6H5tqSBAJOawkxtc5mACMMvZpLQ+V2mTYKWgleBTFmOKi01uwJwX2PbOmRg2y2 0SgcuBBVQEy4y21Hym1RWgftxdtllSSBzcX7T6b0gGuIOtZ8cknLBinYzqI550R8DELa zZKiYdqvzDsS03JduK09nkF8G6Bw8K3QQ4pJV2pBGVSxq3ZvBfTaZvvcFBgwf/0vCO7k rmIn7sFQ8DDyISCxypBcHadM6TXZWUhY7YR6UCL76KKXKBiWy+8DcjR2VTZGzkf6/dLp v+511jSdy/1Lo3vk2Iw/lDuj8I66wy38Vyy5btWcqnFtGwnIlXIGTiSpXEayZs5og46/ zSWQ==
X-Received: by 10.140.19.136 with SMTP id 8mr2849597qgh.72.1445273533776; Mon, 19 Oct 2015 09:52:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.207.72 with HTTP; Mon, 19 Oct 2015 09:51:34 -0700 (PDT)
In-Reply-To: <BDB816652A89FC266ED53495@JcK-HP5.jck.com>
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: Seth Johnson <seth.p.johnson@gmail.com>
Date: Mon, 19 Oct 2015 12:51:34 -0400
Message-ID: <CAJkfFBzDGLMuvn9GA156wSCmRNA-q8DAdXxGubuzJSzzB7Jstg@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/hbamKG1EF30R3kWg041kZGtSUNo>
Cc: "Ianaplan@Ietf. Org" <ianaplan@ietf.org>, John Curran <jcurran@istaff.org>, Avri Doria <avri@acm.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 16:52:17 -0000

On Mon, Oct 19, 2015 at 9:51 AM, John C Klensin <john-ietf@jck.com>; wrote:
>
> --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.


Not to make a habit of this, but I want to make the following comments
once again in response here:

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.

- and -

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 you won't be in any sort of position to stand against
intergovernmental [policy authority] (which is not subject to the same
limits).

I'll also say I sort of agree that the NTIA did not "ask the right
questions" -- or more precisely, didn't frame the problem right.  And
we haven't improved the defect -- the CCWG-Accountability stress test
exercise completely fails to characterize the nature of the transition
and therefore the nature of the problem.


Seth


> 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
>
>
>
>
>
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan