ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index    

Types and their associated queues, assuming some rate of entry into the root

  • To: 3gtld-intro@xxxxxxxxx
  • Subject: Types and their associated queues, assuming some rate of entry into the root
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Sun, 22 Nov 2009 18:07:20 -0500

This is the summary section to a note which has been circulated privately.

My purpose is to make a types-as-queues representation widely available, so that the controlling issue, in terms of rate of service of applications, ignoring all causes for application failure, are visible.



Changes to the IANA root are allocated as a scarce resource. A partially ordered queue set exists, consisting of:

    a. the meta queue event, signing the zone

    b. O(N/5) change requests (ccTLD IDN FastTrack)

    c. O(2*N) change requests (ccTLD IDN PDP)

    d. O(2*N) change requests (lc+metro+geo public)

    e. O(N/10) change requests (IDN equivalents to existing gTLDs)

    f. unbounded change requests (gTLDs)

    g. unbounded change requests (single registrant TLDs)

The IANA root change service is estimated to be able to handle O(N/2) change requests per year.

If the f or g queue is serviced first, no other queue will ever be serviced.

If the b queue is serviced first, O(3N/10) service capacity is free to allocate to other queues in year 1, and O(N/2) in subsequent years.

The c queue has a wait condition, the xTLD IDN PDP.

O(N/5) entries in the d queue are known. As it happens, a majority are CORE clients, by CORE's design. Recall, CORE predates ICANN and was formed to advance a public, rather than a private agenda. The d queue appears to be filling at a rate of O(N/10) per year.

The e queue has a wait condition, the xTLD IDN PDP.

A queue service order of a, b, d, c+e, f+g appears to use the IANA root change capacity better than any other order, exhausting all finite queues in the fewest years, and capacity exists in five or fewer years to service the f queue, assuming the xTLD IDN PDPs are completed in three or fewer years.

Personally, I don't think the g queue should ever be serviced, and I can't think of a compelling reason to prioritize the f queue ahead of any queue except the g queue.

As always, in an individual capacity, though I'm employed by CORE which has an interest in the subject matter.

Eric Brunner-Williams


<<< Chronological Index >>>    <<< Thread Index    

Privacy Policy | Terms of Service | Cookies Policy