Re: About ccTLDs and gTLDs

[John C Klensin <[e-mail]>]

--On Friday, June 30, 2017 09:59 -0400 Andrew Sullivan
<[e-mail]> wrote:

> On Fri, Jun 30, 2017 at 07:31:58AM +0200, Olivier MJ
> Crépin-Leblond wrote:
>> Hello all,
>> 
>> I am reading RFC1591 and RFC3071 and have a couple of simple
>> questions: 1. Is a ccTLD defined as restricted to 2-letter
>> country codes (ISO3166 alpha 2), or could that include
>> 3-letter country codes in the ISO3166 list (ISO3166 alpha 3)?

>...(I believe that the traditional resistance to adding
> _any_ 2-letter TLD, even if it's not on the 3166 list, comes
> from the possibility that a new country will happen that could
> collide with such a 2-letter TLD.  The ISO list isn't static,
> and simply reserving everything in the space seems prudent.

Exactly.  Even using codes that 3166-1 designates as "private
use" is dangerous because there is not reason why some future
version to the standard might not press those codes into use if
the available code space becomes limited (more likely since the
p9licy as to how long 3166/MA needed to wait before reallocating
a code that was no longer used was expanded from five years to
some really long period).

It is worth being explicit about something Andrew implies.  If
XX were to be delegated to some non-country entity and then a
country comes along and is assigned that code by 3166/MA, there
is an immediate and nasty crisis because there is no model for
allocating any other code to the country and whatever entity had
been delegated XX would certainly object to having it taken away
and presumably having all of its registrations cancelled.   Many
pre-ICANN IANA policies were designed around avoiding, rather
than encouraging, such problems.

> will not comment on the wisdom of adding "country codes" that
> are not on the 3166 2-letter list, except to note the text in
> 1591, "The IANA is not in the business of deciding what is and
> what is not a country."

While there was another reason for that statement, yes.  3166
was chosen both because it provided an explicit list of entities
that could request/ register ccTLDs and because it avoid
arguments about what the country code/ label should be, with
neither decision requiring IANA involvement.  I've mentioned
several times in various discussions that IANA resisted sending
even an observer to 3166/MA until well after the transition to
ICANN because Jon didn't want anyone to be able to try to demand
that he propose adding a country-entity and code to 3166 in
other that a TDL could then be registered.

>> 2. RFC1591 appears to point at 2-letter, but many other parts
>> of this RFC are obsolete - so does this RFC remain valid?
> 
> I am not sure what you mean by "parts of this RFC are
> obsolete". There does not appear to be any RFC that obsletes
> or even updates RFC 1591.
> 
> What of course is true is that there is a community that has
> taken over the policy role for the root zone, and it might be
> that that community regards some of the text as obsolete.  As
> I pointed out repeatedly to colleagues around ICANN during the
> preparation for the IANA transition, 1591 is not holy writ.
> People could update or obsolete it at any time by using the
> normal processes for obsoleting or updating an RFC.  There is
> the small problem of who has change control over RFC 1591,
> since it is not obviously a product of the IETF and looks like
> it might have been a product of IANA.

yes.  If definitely was.  I assume the IAB could have objected
had they wanted to, but that not only would have set of some
sort of constitutional crisis but, at least based on what I was
told at the time (much earlier than 1591), part of the reason
for establishing IANA as an entity was to keep IAB members
insulated from allocation decisions in order to avoid all sorts
of potential conflict of interest and antitrust problems.

>   More likely, since
> ICANN is in the business of making policies for the root zone
> anyway, ICANN could simply issue a new document that it says
> it will follow, and publish a statement that for its policy
> purposes RFC 1591 has been superseded by $document(s).

Of course, ICANN did issue a document that more or less
explicitly updates 1591 in the form of the May 1999 ICP-1.  Of
course, rather than obsoleting 1591, it references it and
essentially reaffirms it.  It even includes the "trustee for the
domain" and "obligation to serve the community" language. 

> I got the impression, however, during those conversations, that
> several people prefer the current ambiguity because it allows
> for divergent opinions, with each opinion holder able to cite
> some document.  Whether this is because there is an unresolved
> difference of opinion that is hidden behind such appeals, or
> whether some people just like to have something to argue about
> so they can go to meetings, I cannot say.

No comment.

best,
   john

p.s. In case it is relevant, I was very actively involved in the
development and text of 1591 and some other IANA policies during
that period.