Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)

'Andrew Sullivan' <ajs@anvilwalrusden.com> Fri, 07 November 2014 23:56 UTC

Return-Path: <ajs@anvilwalrusden.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 8ED241A001C for <ianaplan@ietfa.amsl.com>; Fri, 7 Nov 2014 15:56:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.259
X-Spam-Level: *
X-Spam-Status: No, score=1.259 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_INFO=1.448, 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 tl8_iAR5JnBp for <ianaplan@ietfa.amsl.com>; Fri, 7 Nov 2014 15:56:25 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179131A000B for <ianaplan@ietf.org>; Fri, 7 Nov 2014 15:56:25 -0800 (PST)
Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id F3EAE8A035 for <ianaplan@ietf.org>; Fri, 7 Nov 2014 23:56:23 +0000 (UTC)
Date: Fri, 07 Nov 2014 18:56:22 -0500
From: 'Andrew Sullivan' <ajs@anvilwalrusden.com>
To: ianaplan@ietf.org
Message-ID: <20141107235621.GB36672@mx1.yitter.info>
References: <54597BDB.7040305@meetinghouse.net> <5459BA98.1070006@gmail.com> <545A208A.7040304@meetinghouse.net> <631e3e3d29c843bd9c23151c63612989@EX13-MBX-13.ad.syr.edu> <20141105154903.GI30379@mx1.yitter.info> <498a39b81b774192bd2d609b3feab35f@EX13-MBX-13.ad.syr.edu> <20141105234444.GM31320@crankycanuck.ca> <0d10ba336c984561a1a5d6d81db5f26c@EX13-MBX-13.ad.syr.edu> <20141106144333.GA33081@mx1.yitter.info> <6e19bf2618a54b27bb1b859842e98144@EX13-MBX-13.ad.syr.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <6e19bf2618a54b27bb1b859842e98144@EX13-MBX-13.ad.syr.edu>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/6u9LCWwAs89WJkmkKd3t-PyGloI
Subject: Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)
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: <http://www.ietf.org/mail-archive/web/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: Fri, 07 Nov 2014 23:56:26 -0000

On Thu, Nov 06, 2014 at 04:37:36PM +0000, Milton L Mueller wrote:
> Whoa. It is completely invalid to call a final ICG proposal that was developed by the entire community, is endorsed consensually by all 3 operational communities, has survived one or more public comment periods, and is accepted by the NTIA  - as a kind of extortion, especially when ICANN itself was fully represented in the development of the proposal and had the ability to publicly comment on it. 
> 

Look, you're the one who claimed there was extortion in the first
place: that ICANN would be "extorting" the IETF if it asked us to give
something up if we wanted something of theirs.  Where I come from,
that's not called "extortion"; it's called "selling" or "making a
bargain".  

> You need to get a grip on the reality of this process; it is highly
>  public, highly political, the whole world is watching, etc.,
>  etc. The idea that ICANN could undermine a consensus ICG proposal
>  by bargaining with IETF and ask for nasty things IETF did not want
>  to give them just lacks basic plausibility. I think you'd better
>  give up on that line of argumentation.

They're not going to be _nasty_ things; they're going to be things we
don't want to give up.  For instance, they might ask for tighter
conditions on how we might change the relationship.  Surely, that's
what you or I would ask for under similar circumstances?
 
> You're saying "do nothing to avert an obvious problem" 

No, I'm not.  I keep saying that I don't think this is an obvious
problem, and I don't think that our having control over the mark or
name is an obvious solution to that non-obvious problem.  I'll try
once more, then give up.

The draft already contains a request of the continuation of the
existing state of affairs, which is that the incumbent operator agrees
to transfer the marks and domain names to some subsequent operator.
But our problem is the one where either the IETF or ICANN decides to
separate the protocol parameters from everything else, and where that
separation happens in a way that there is a big dispute such that a
redirect from the iana.org site to some new site isn't just put in
place as a matter of course.  In other words, things have broken down,
there is mistrust and ill feeling, and so on.

Under such circumstances, there is no nice state of affairs.  We don't
know now whom we should trust then, and there's no more reason to
prefer the IETF Trust than to prefer the existing IANA operator.  The
names community and the numbering communities both have legitimate
claims on iana.org too.  Indeed, if I put on my names-community hat,
the names community has at least as good a claim, because the root
zone is published there and the topmost-level whois data is there, and
there are way more people in the world who have little information
about what an IANA is who need the root zone from time to time than
there are implementers of protoocols who need the latest IANA protocol
parameters.

Moreover, were there some legal agreement, in a disputatious case the
dispute would be settled in legal terms way too late for the IETF.  So
we'd have to make a forced transition anyway.

I've already outlined a way to get around this problem for the IETF,
if we really think it's a problem; it's a path that we can take
entirely on our own without making a single request of ICANN, NTIA, or
anyone else.

Regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com