[arin-ppml] Updates to 2012-6

[ebw at abenaki.wabanaki.net]

Rodney suggests that allocations be made to TLD registry contract holders,
observing, reasonably, as a registry backend service provider employee[1],
that allocations made to registry backend service providers complicate the
possible future selection of providers by the TLD registry contract holder.

This revisits the well-known non-portability of provider-aggregatable address
space.

However, before attempting to reason about delegations and the set of assets
minimally advisable to delegees who may, from time to time, be operators of
one or more delegations, we should consider the properties of the proposed
allocation.

There are economic constraints on the number of allocations that may be made
to IX points -- there are sub-four-figures of IX points globally and nothing
suggests a change of scale.

There are economic constraints on the number of allocations that may be made
to other types of "Critical Infrastructure" such as ISPs and data centers.
The same sacling observation applies.

We are confronted by a label allocation policy that may be simplified without
loss of meaning to "three per day" or "one thousand per year". The rate of
label allocation is, according to the label allocator (ICANN), its contracting
rate. In its 2000 and 2004 allocations its contracting rate was on the order
of one per month, or two orders of magnitude less than its current rate of
allocation. To round to the nearest power of two, it is 1024 /xx per year.

It is speculation to assume this is bursty behavior, and the long-term average
rate of allocation substantially different. It is also speculation to assume
that ICANN will not increase the  rate of its contracting process, which
now preferences a single uniform contract.

I suggest first that the proposed rate of allocation is a concern where the
allocated resource is known to be finite. For simplicity, I offer that the
addition of distinct resources to existing iso3166-1 code points delegees to
present only linear scaling, bounded above by a low integer multiple of the
current allocation, perhaps as small as two, and that the addition of
distinct resources to allow iso639 code points, jointly and severally with
iso3166 code point allocations, is similarly limited, and that the addition
of distinct resources to allow iso3166-2 code points and urban areas[2] is
similarly limited. Roughly, these possible allocations in their aggregate
amount to a very low multiple of the current label allocation when fully
exhausted, however, the allocation regime characterized as 1024-per-year is
unbounded over time. 

Second, I want to point out that .museum began on a very, very, limited 
set of address assets, and that while a significant amount of resources
have been expended creating functional and service level requirements not
in ICANN's current contracts, and so not applicable to the operator of 
the .com, .net, .name, and other registries, as well as all other TLD
registry operators, which may have the effect of raising the entry cost
of registry operations, that no rational for this increase in entry cost
arises from address space or ASN allocation. Uniform allocations such as
a /24 to all registries, whether to the contract holders or to platform
operators (see "provider aggreable", supra), overlooks the year to year
projected operational requirements of the candidate allocatees, and in
many cases (see iso3166-1 "IDN", iso639, and iso3166-2 plus other, supra)
may be satisfied by allocations as small as /27, even /28 in their first
five years of operation.

Third, I want to point out that not all infrastructure is equally critical.
In 2010 it was possible to show that the registrations in .cat were not
secondary to registrations in .com, nor in .es, and therefore that .cat
did not subset the locaii of registrant, registrar, and resolution of the
.com or .es zones. It is currently possible to show that registrations in
.xxx are secondary to registrations in .com, and therefore that .xxx is a
subset of the locii of registrant, registrar, and resolution of the .com
zone. Should .xxx fail, for any reason, the "criticality" of it as core
infrastructure is limited to its operator. While this may not be generally
known, some business plans of the 2004 round gTLD label allocatees, and
for many of the 2012 round gTLD label applicants, are predicated on the
replication of the locii of registrant, registrar, and resolution already
present in the .com zone.

Examples of this are the applications for transliterations of "com" in a
dozen non-Latin scripts. Each such transliterated-into-X registry has the
potential to have significant shared locii of registrant, registrar, and
resolution of the .com zone, a potential preferenced by the existing IPR
policies of ICANN, WIPO, and the registration policy of the applicant.

While one could claim that "com" in any script other than Latin is, by its
non-Latin-ness, "critical" [3], no such claim can be offered for business
plans that simply seek to replicate the locii of registrant, registrar, and 
resolution of the .com zone, whether for the purpose of defensive registration
revenue, or for pay-per-click monitization registration revenue capture, or
both. For simplicity I refer to this as ".copy".

I suggest that means testing, both for necessity (see the .museum observation,
supra) and utility (see .copy, supra) is preferable over uniform allocation,
independent of whether the allocation is to the contract holder, independently,
or to the platform operator, aggregable. We proform means testing for ISP
allocations, so this isn't new territory.

In support of the probable absence of necessity, or utility, of allocations
larger than /28 to some applications of the DNS, many applications ICANN has
solicited propose to provide no significant public function beyond resolution
of zero or some small number of resources other than the base label. However,
if permitted [4], the existing set of credible applicants is several orders
of magnitude greater than the current label-associated set of "critical
infrastructure" resources, and unbounded over time as new brands are created
and the cost to "taste" the DNS for top-level value is only the ICANN fee and
modest operational cost using no-cost-to-applicant address space assets.

So finally to Rodney's point, allocate (according to necessity and utility,
if any) to the ICANN contractor, or to the registry services provider.

When I first asked for v4 assets to be held in reserve for new TLDs about
two years ago the common assumption was that there would only be a quarter
of the number of applications to ICANN there in fact are, and that the
corresponding ratio of "facilities-based" to "virtual" registry operators
would be far higher. The facts at hand are that almost all of this class
of would-be "critical infrastructure" is located in the ARIN region, and
that of these, most applicants are made by, or through, a small number of
registry backend service providers.

I suggest that a way, one I'm now convinced has the least waste, from the
point of view of a scarce, and persistent address allocator, and reasonable
given the external circumstances, is to only allocate to facilities-based
registry operators, and only along the ISP usage guideline, attempting to
rationally forecast use and allocation (and de-allocation). If the external
circumstances were facilities-based applications, not sharing the locii of
registrant, registrar, and resolution fates of the .com registry, I would
hold my original view, one which Rodny has articulated.

Eric

[1] In 2001 and 2002 I was employed by NeuStar, a registry backend service
provider, and from 2008 to 2010 I consulted to CORE, also a registry backend
service provider.

[2] No normative standard, but see Table 8, "Population of Capital Cities and
Cities of 100 000 or More Inhabitants", published in the United Nations
Demographic Yearbook7, or Thomas Brinkhoff's list of the 493 agglomerations
of the world with a population of 1 million inhabitants, published at
http://www.citypopulation.de/, as two reasonable informational choices.

[3] See the recent declaration of incomming ICANN CEO Fadi Chehadi that
Verisign's applications for "com" in scripts other than Latin will be
approved before almost all other applications.

[4] No ICANN Policy Development Process record exists to support ".brand"
types of registries with significant contractual variation from "open", 
"sponsored" or "community-based" registrations.