[governance] Alt Root Foundation - New TLD's

Fri Nov 30 15:34:47 EST 2012

David,

further analysis of Karl's scheme proved fatal. 

Once any alt-root would really get into significant action, a new layer of coordination, the root-of-all-roots, would emerge, whether by design or de facto. You or rather Karl would be back to square one but on a much feebler basis, retroactively trying to hammer agreements on how to run it to avoid the fatal conflicts and inconsistencies you correctly point to. 

BTW you don't have to be the master of the big-data universe to understand the problem of consistency in databases when you have multiple copies of the database that can be independently modified. Most members of this list must have two devices (maybe a computer and a mobile telephone) with their phone/email directories, and may be witnesses to the headaches and other pains even in that modest scale. 

Yours,

Alejandro Pisanty

! !! !!! !!!!
NEW PHONE NUMBER - NUEVO NÚMERO DE TELÉFONO

+52-1-5541444475 FROM ABROAD

+525541444475 DESDE MÉXICO

SMS +525541444475
     Dr. Alejandro Pisanty
UNAM, Av. Universidad 3000, 04510 Mexico DF Mexico

Blog: http://pisanty.blogspot.com
LinkedIn: http://www.linkedin.com/in/pisanty
Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614
Twitter: http://twitter.com/apisanty
---->> Unete a ISOC Mexico, http://www.isoc.org
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

________________________________________
Desde: governance-request at lists.igcaucus.org [governance-request at lists.igcaucus.org] en nombre de David Conrad [drc at virtualized.org]
Enviado el: viernes, 30 de noviembre de 2012 13:27
Hasta: governance at lists.igcaucus.org
Asunto: Re: [governance] Alt Root Foundation - New TLD's

Karl,

On Nov 28, 2012, at 12:02 PM, Karl Auerbach <karl at cavebear.com> wrote:
> But on the other hand there have been instances of well run competing
> roots.  For example there was the ORSC which was a mirror of the
> NTIA/Verisign/ICANN (NVI) root.

ORSC was an alternative root _infrastructure_.  They went out of their way to point out that the _namespace_ would be identical to the namespace provided by NVI unless NVI took actions to modify that namespace in a way that the ORSC community felt was inappropriate. What would happen at that point was left as an exercise to the reader. As far as I can tell, the Alt Root Foundation (et al.) are offering an alternative namespace (in addition to their own infrastructure) with no indication of how name collision is handled.

> One interesting thing was that ORSC had a policy that said "we will not
> withdraw a TLD".  ICANN does not have such a policy.  This was in the
> context of the ccTLD for the now defunct Soviet Union.

So you're saying that ORSC had a policy to not withdraw a TLD because IANA indicated .SU was to be transitioned out of the root? That does not correspond to my recollections of ORSC (I thought the SU stuff happened long after ORSC was established, however my memory is a bit hazy) and I find that surprising and I would've thought such a policy would be problematic since (for example) the ISO-3166 list is not fixed in stone.  I would personally think having a policy to not remove a TLD ever would be crazy (particularly in an environment where you're adding 1000 new TLDs per year), but that's probably just me. Fortunately, ORSC isn't around anymore so the discussion is academic.

With regards to .SU, since I was involved in those actions as IANA General Manager at the time I can state authoritatively that the action to remove .SU was based on the requirement that ICANN abide by RFC 1591/ICP-1. The ISO-3166 country code for SU was (at the time) designated as "transitionally reserved" which, according to the ISO-3166 Maintenance Agency is defined as "Code element deleted from ISO 3166-1; stop using ASAP" (see the definitions at http://www.iso.org/iso/iso-3166-1_decoding_table.html). As had been done with .CS, IANA staff was following that dictum. However, since that time, ISO-3166/MA has been (surprisingly, IMHO) convinced to move SU to "exceptionally reserved", similar in status to EU, UK, AC, etc. As such, I doubt SU will ever be removed from the root.  This is probably unfortunate as one of the rationales for the use of ISO-3166 is that there is (ultimately) laws of a sovereign nation that defines the legal environment in which the TLD operates. Since the Soviet Union no longer exists, that legal environment is ... ill-defined. Perhaps not coincidentally, .SU has been documented as unusually high in domains associated with malware sites (e.g., http://threatpost.com/en_us/blogs/attackers-moving-zeus-servers-former-soviet-union-tld-013012)

> But the key aspect is "consistency" - The need needs competing roots to
> be consistent with one another.  Otherwise there would be very unhappy
> users.

Very true. The DNS protocol fundamentally requires a singular namespace as the protocol has no way in which conflicting names can be resolved consistently. The simple way to administer this singular root is to have a single body oversee add/change/delete operations. The more complicated way is to create an administrative infrastructure in which conflicting add/change/delete operations made by multiple bodies cannot happen. As far as I am aware, no one has been able to figure out how to guarantee the latter.

> The definition of "consistency" is not obvious.  Some people take it to
> mean "exact equivalence".  I take a looser definition that says that it
> is not necessary that all roots contain the exact same set of TLDs, but
> that where there are TLDs in common they must have the same contents.

Unfortunately, the contents of the root zone is not (and has never been) static.  Folks who operate databases for a living long ago figured out that it is bad if you have multiple copies of data that can be independently modified -- you invariably end up with conflicts and data inconsistencies.  Since the database we're talking about is a core component of an infrastructure upon which national economies increasingly depend, I personally feel the approach you suggest would be irresponsible.

> Any reasonable root operator ought to avoid TLD names that are contested.

And how would you go about ensuring _all_ root operators are "reasonable" for all time?

Regards,
-drc

-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.igcaucus.org
To be removed from the list, visit:
     http://www.igcaucus.org/unsubscribing

For all other list information and functions, see:
     http://lists.igcaucus.org/info/governance
To edit your profile and to find the IGC's charter, see:
     http://www.igcaucus.org/

Translate this email: http://translate.google.com/translate_t