Re: [Ianaplan] on considering consensus
John C Klensin <john-ietf@jck.com> Wed, 26 August 2015 15:00 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 8D9651B2FB8 for <ianaplan@ietfa.amsl.com>; Wed, 26 Aug 2015 08:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] 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 nlIrPnZIBXpK for <ianaplan@ietfa.amsl.com>; Wed, 26 Aug 2015 08:00:45 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574B31B2EAE for <ianaplan@ietf.org>; Wed, 26 Aug 2015 08:00:45 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ZUcBv-0005KA-RF; Wed, 26 Aug 2015 11:00:43 -0400
Date: Wed, 26 Aug 2015 11:00:38 -0400
From: John C Klensin <john-ietf@jck.com>
To: Olivier MJ Crepin-Leblond <ocl@gih.com>
Message-ID: <8942451ED29E2CC2FFA2D91F@JcK-HP8200.jck.com>
In-Reply-To: <55DC9F86.40002@gih.com>
References: <55DBFC39.5000701@cisco.com> <55DC0030.5080809@gmail.com> <55DC00CD.9040804@cisco.com> <A446C143EF3E8721BB647FA6@JcK-HP8200.jck.com> <55DC8ABD.7010304@cisco.com> <55DC9F86.40002@gih.com>
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
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/WzsLsYlonCMc5YnNRDxTsvlWmbQ>
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] on considering consensus
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: Wed, 26 Aug 2015 15:00:47 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Tuesday, August 25, 2015 19:01 +0200 Olivier MJ Crepin-Leblond <ocl@gih.com> wrote: >... >> There are two problems with this devil's advocate statement. >> The first is that not all the authority is left in assorted >> ICANN entities. Rather it is found in the three communities. >> Second, any debate about the individual proposals should have >> happened within the communities. > FWIW, I agree with the points Eliot is making in this thread & > others. The IETF & RIRs can walk away from the agreement with > ICANN if they want to, so I do not see any "decision authority > left in assorted ICANN entities". If you see IETF & RIRs being > assorted ICANN entities (god forbid! :-) ) then I'd agree with > you. But IMHO the decision authority is in the Operational > Communities. Olivier, I think there are some important distinctions to be made in this discussion. If we cannot agree that they exist, I doubt that either of us will be able to persuade the other. There are more general cases (see below), but this specific one, from my perspective, looks like this: To at least some degree, most of us believe that splitting the IANA function into two or three separate pieces, with completely separated management, decision processes, staffing, and accountability would be undesirable. Probably keeping the function together is less important today than it was 20 or more years ago when IANA had and exercise real decision-making authority, but it is notable that, AFAIK, no one has seriously made what might have been the most simple and straightforward transition proposal, which would simply be to split things up now, making each of the three functions separately accountable to the three customer communities with no interactions that require agreement among them (or with ICANN). To the degree to which that "it is better to keep IANA together" view is relevant, the "walk away" plan has to be understood as a last-resort and very drastic (aka "nuclear") option. It may be vital to preserve that option (I think it is), but saying "you have that option, so there is no problem" is really not helpful except as rhetoric. In addition, as others have pointed out several times on this list, the only plan so far for an IANA income source involves ICANN resources, which means the IANA budget decisions are in the hands of "ICANN entities". Similarly, PTI is specified as an ICANN subsidiary (whatever the terminology) and is hence also an ICANN entity. Obviously, a response to those concerns is that the various safeguards and authority built into the system --the budget veto, the board removal provisions, etc.-- are adequate protections against abuse or external (to IANA) control or capture of the IANA function. However, that isn't the argument I understand you to be suggesting, i.e., that ICANN entities are not involved or don't have significant authority. More important, for at least two reasons I don't believe those provisions are likely to be effective. First, if the groups that have the ability to make those "reset and reboot" decisions are at all responsible, those options are, themselves, last-resort moves, sufficiently likely to be disruptive and destructive to be undertaken (rather than, e.g., threatened) only after things have already reached meltdown status. Second, ICANN Counsel have consistently taken the position that the principal obligation of the ICANN leadership is the preservation and best interests of ICANN as an organization, not that of the Internet, the multistakeholder community, or other lofty abstractions. As long as that attitude prevails as a key part of the ICANN culture, I have little or no confidence that any structural change that it designed to force ICANN to act against its organization best interests will survive in effective form for very long... at least absent an external guarantor (for which see my previous notes about "transitioning" any external guarantor(s) out of the system). > The real concern I have about the current discussions (Devil's > Advocate aside, which I think is helpful) is the complete loss > of the optics of the wider picture. Are Operational > Communities in this Internet Boat together or are they living > a "Life of Pi"? In the longer term, if we do not find a way to > have more trust across all three operational communities, how > are we going to ever stand as one to defend the > multi-stakeholder model of governance? This gets to the more general part of the problem, again with multiple aspects. If the "operational communities" (a term that, I note, started being used only during these "transition" discussions) are really in the "Internet Boat" together and more or less tightly bound to each other in that boat, then the argument that the ability to walk away solves all possible problems becomes even weaker than my characterization of it above. Reaching meaningful consensus among those groups ultimately depends on a shared model of what constitutes success, but I see at least three models floating around. One is the successful and smooth "technical" operation of the Internet, perhaps with an underlying assumption that such an Internet will route around damage (technical, economic, or political). Another is the notion of a successful, profitable, and maybe competitive market in domain names. And a third is preservation and strengthening of the sociopolitical concept of a "multistakeholder model" (see below). Those goals/ success criteria are not necessarily mutually exclusive. I believe that is enough goodwill in the various communities that people can accept other groups having their needs satisfied as long as their own needs are met -- a view that, I believe, has dominated recent discussions on this list. On the other hand, the history of these discussions --for the technical / engineering community going back to the first set of pre-ICANN "the Internet is too important to be left to the engineers" comments-- suggests that each of the communities needs to be cautious about the others. That is, IMO, particularly important when "multistakeholder model" becomes a goal rather than a description of a process. In the ISO world, the phrase "materially concerned party" is often used and I personally wish the ICANN-related (and "Internet governance"-related) criteria had found an expression closer to that. "Multistakeholder" should, arguably, mean the same thing, but seems in practice to include a lot of parties whose are less involved; have, as the saying used to go, far less "skin in the game" of a well-working Internet; who are interested in disrupting the current model and discussions in favor or an entirely different vision; who see these discussions and the entire "governance" discussion as an opportunity to test or demonstrate theories about non-governmental world governance or other personal theories; or who, in the words of a prominent ICANN staff member, just have too much time on their hands. Put differently, it is sometimes hard to differentiate between a constructive and Internet-focused multistakeholder model and a leaderless and unfocused mob each of whose members have managed to find a large pointed object somewhere. Until and unless something changes in that version of the "multi-stakeholder model of governance", standing together to defend it may not only be impossible but undesirable. best regards, john -----BEGIN PGP SIGNATURE----- Version: Encryption Desktop 10.3.0 (Build 8741) Charset: utf-8 wj8DBQFV3dSJ5pJ/EbOJ8NoRAh9sAJwO9JKYZGYfvSJ+6CjdxeX1TXguWwCgnR4L BE47UjdF7LwvC5JTickWPbo= =Iq6L -----END PGP SIGNATURE-----
- [Ianaplan] on considering consensus Eliot Lear
- Re: [Ianaplan] on considering consensus Brian E Carpenter
- Re: [Ianaplan] on considering consensus Eliot Lear
- Re: [Ianaplan] on considering consensus Richard Hill
- Re: [Ianaplan] on considering consensus Eliot Lear
- Re: [Ianaplan] on considering consensus Richard Hill
- Re: [Ianaplan] on considering consensus Richard Hill
- Re: [Ianaplan] on considering consensus John C Klensin
- Re: [Ianaplan] on considering consensus Eliot Lear
- Re: [Ianaplan] on considering consensus Olivier MJ Crepin-Leblond
- Re: [Ianaplan] on considering consensus Jefsey
- Re: [Ianaplan] on considering consensus John C Klensin
- Re: [Ianaplan] on considering consensus John C Klensin