Re: [Ianaplan] Question from the ICG

John Curran <> Mon, 09 February 2015 20:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7D9351A88DD for <>; Mon, 9 Feb 2015 12:56:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b2F33Z8D4uPV for <>; Mon, 9 Feb 2015 12:56:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C473D1A8777 for <>; Mon, 9 Feb 2015 12:56:03 -0800 (PST)
Received: from [] (helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from <>) id 1YKvN8-0004jN-Sj; Mon, 09 Feb 2015 20:55:59 +0000
X-Mail-Handler: DuoCircle Outbound SMTP
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX18q/sRtfobMTbrnGfFf8x6x
Content-Type: multipart/alternative; boundary="Apple-Mail=_DEE8CD00-4290-4C86-8390-3DE6C5DC9358"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Curran <>
In-Reply-To: <>
Date: Tue, 10 Feb 2015 04:55:57 +0800
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Bernard Aboba <>
X-Mailer: Apple Mail (2.2070.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: Mon, 09 Feb 2015 20:56:06 -0000

On Feb 10, 2015, at 2:35 AM, Bernard Aboba <>; wrote:
> 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. 

Agreed that procedures would be necessary in that particular case, uncertain that 
the ICG would come up with them (my understanding of the ICG is that it is a 'review
and assembly' process for development of a single particular stewardship transition 
proposal and that all actual content comes from the individual communities)

The act of participating in publication of an IANA registry, regardless of the operator,
seems to imply a minimal level of coordination with other IANA registry operators.  In
the (suboptimal) case of multiple IANA operators for protocols/names/numbers, they
are most certainly going to have to coordinate, since the IP address, ASN, and root
zone spaces are each ultimately single Internet identifier spaces with individual 
spans managed by distinct communities.  Coordination is inherent to maintaining 
the core principal of uniqueness; necessary for successful functioning of the IANA 
registries and ultimately the success of IETF protocols in making the Internet work 

The IANAplan ICG RFP response (on behalf of the IETF community) states that the 
IETF community "will continue to coordinate with ICANN, the RIRs, and other parties 
that are mutually invested in the continued smooth operation of the Internet registries”; 
presumably this includes directing any protocol parameter IANA operator to coordinate 
on their use of the IANA domain and marks.

The CRISP team ICG RFP response (on behalf of the Numbers community) states 
that its agreement with the IANA Numbering Services Operator "should also require 
the IANA Numbering Services Operator to appropriately coordinate with any other 
operator of IANA services.”; presumably this includes directing any protocol parameter 
IANA operator to coordinate on their use of the IANA domain and marks.

If there were to ever be multiple IANA registry operators, would the requirement (from 
their respective communities) for each of them coordinate with one another be sufficient 
to result in any necessary procedures being established?  I would think that the IETF’s 
IANA operator would administer the <> domain as part of the RFC 2860 MOU 
(per 'online publication' task 4.4) and that the IETF would want any delegated registries
to also be available at the same consistent publication point, but it probably would be 
worth making IETF’s expectations (whatever they may be) explicit should the <> 
domain be held by the IETF Trust. 


Disclaimer:  My views alone.  Use, abuse, or discard as desired.