Re: [Ianaplan] Question from the ICG

Alissa Cooper <> Tue, 10 February 2015 04:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D77951A8AFB for <>; Mon, 9 Feb 2015 20:25:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 97utT8GkLFkd for <>; Mon, 9 Feb 2015 20:25:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 209E71A8BB1 for <>; Mon, 9 Feb 2015 20:25:34 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 404B820E78 for <>; Mon, 9 Feb 2015 23:25:33 -0500 (EST)
Received: from frontend1 ([]) by compute5.internal (MEProxy); Mon, 09 Feb 2015 23:25:33 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=mesmtp; bh=Wo5XVx01U32h/MM5 haAY+B1NlQE=; b=BqW5ASCCxzazz5jkHWk7H+tKdAOJJzapxWM5b3AP0+T2NoE1 Gs/1PhFcHk+XhOhAjbSbdqFAynNgb/LitywnVIIleCgzIhXV32JFGDfjhENnfhjS 7kOf8HdBEGvpsP14Dfsjk0zoSfmtRjPwjejnIEwzETdCsVFwi1F2um7IGxg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:message-id:references:to; s= smtpout; bh=Wo5XVx01U32h/MM5haAY+B1NlQE=; b=ZfW/jbMxuNVNhhNX4Rcp R0HfeSBJMztMu5qRUOqh5qmd283c3rf4texFO/ghFz9zAmcbMG1MP7q1N+fiR1Mf /G+MMLkfx+jv7Lqq9y3IBAOmURfqYCnt7WA5HwOLFteRn0F9/5LHwRvEiCfckB9w 2+MNZr/kSwKo6QKgVbxKnms=
X-Sasl-enc: oCJWmPv3Ji0onVZPL0BeCGzieh8lNcdIkgVe7RCBy6HY 1423542332
Received: from (unknown []) by (Postfix) with ESMTPA id F355AC002A4; Mon, 9 Feb 2015 23:25:31 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7C89CCB7-48ED-4B18-A97E-9E3EA37FBF8A"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alissa Cooper <>
In-Reply-To: <>
Date: Mon, 9 Feb 2015 20:25:31 -0800
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Bernard Aboba <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: Ray Pelletier <>, "Ianaplan@Ietf. Org" <>
Subject: Re: [Ianaplan] Question from the ICG
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: Tue, 10 Feb 2015 04:25:39 -0000

Hi Bernard,

On Feb 9, 2015, at 10:35 AM, Bernard Aboba <>; wrote:

> I'm fine with the language Ray has proposed. 
> In terms of work the ICG needs to do, there is more than just a recommendation on who holds the trademark and domain.  There is the issue of where the domain is pointed to, in the event that the IANA functions are no longer handled by a single operator.  Ideally the ICG will come up with language that describes the process by which this is decided among the IETF, RIRs and names communities.  And of course, this process would need to be agreed to by the IETF trust. 

The tasks you describe above are not within the remit of the ICG. It is up to the communities to first decide if they think they need to specify any process related to multiple operators in advance, if that specification needs to be related to the NTIA transition, and to then do the specifying. And of course, even before any of those things happen, the communities need to decide that they want the Trust to hold the trademark and domain.

With my individual IETF participant hat on, I don’t see specification of that sort of process as necessary, and potentially not even possible. First of all, both communities have been quite explicit that they are satisfied with ICANN’s performance of the functions and have no intention of finding new operators in the near future. Sometimes over-specifying a contingency plan too far in advance can make dealing with the contingency harder rather than easier. Unlike actually transferring the trademark and domain, which could be considered sensitive in timing with the NTIA transition, specifying that sort of process is not.

Second, the notion of specifying a process in advance implies that having multiple operators would necessarily have some impact on where the domain points, or other issues that somehow need to get worked out among all of the communities and the Trust, when the identities of potential future operators are not even known. This would take a lot of reasonable options off the table — e.g., making no changes to the operation of the domain and just having the operators coordinate to all get their registries published on, or each community stipulating some conditions with its operator that requires it to cooperate with the other operators, etc. It seems like those sorts of things would be much better to specify concretely when the time comes than to try to do abstractly in advance.


> On Mon, Feb 9, 2015 at 9:01 AM, Ray Pelletier <>; wrote:
> > On Feb 9, 2015, at 11:41 AM, Eric Burger <>; wrote:
> >
> > I like this language. It captures our willingness to have the IETF Trust hold the registration while also capturing our disinterest in fighting for it.
> Can’t we agree on these two bits:
> With regards to the IANA trademark and the IANA.ORG domain, both are associated with the IANA Numbering Services and not with a particular IANA Numbering Services Operator.
> The IETF Trust would be an acceptable candidate for holding the trademark and domain.
> Ray
> no hats
> >
> >> On Feb 9, 2015, at 10:04 AM, Dave Crocker <>; wrote:
> >>
> >>
> >> In terms of making a discrete statement, perhaps this translates to:
> >>
> >>    The IETF is willing to have the IETF Trust hold registration of
> >> IANA.ORG, if that is the preference produced from the IANA Stewardship
> >> Transition Coordination Group process.
> >
> > _______________________________________________
> > Ianaplan mailing list
> >
> >
> _______________________________________________
> Ianaplan mailing list
> _______________________________________________
> Ianaplan mailing list