Subject: About ccTLDs and gTLDs

From: Olivier MJ Crépin-Leblond <[email-masked]>
Date: Fri, 30 Jun 2017 07:31:58 +0200

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)?
2. RFC1591 appears to point at 2-letter, but many other parts of this
RFC are obsolete - so does this RFC remain valid?
Kindest regards,

Olivier

-- 
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Jun 2017 09:59:49 -0400

> alpha 2), or could that include 3-letter country codes in the ISO3166

RFC 1591 says, "the two letter country codes from ISO-3166," so I
don't see why the 3-letter codes would be included.  I can think of a
good reason _not_ to include 3 letter codes, and that is the potential
for collision with other 3-letter TLDs.  (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.  I 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.")

> 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.  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).

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.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Fri, 30 Jun 2017 11:50:36 -0400

--On Friday, June 30, 2017 07:31 +0200 Olivier MJ
Crépin-Leblond <[email-masked]> 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)?
> 2. RFC1591 appears to point at 2-letter, but many other parts
> of this RFC are obsolete - so does this RFC remain valid?

Olivier,

First, it is important to understand that RFC 1591 was never an
IETF document.  It was an IANA policy document, dating from a
time that IANA operated largely independent of the IETF (the
IETF could _request_ registration actions or registry creation,
but not _order_ them and so could others) and, while it
(deliberately, IIR) didn't strongly call that out, reflecting
policies and norms that had been in effect, although evolving
somewhat, long before the time it was published.

It may also be useful to recall that the practical authority of
IANA in the DNS space at that time was derived from two things.
The first is what is known (especially next week) on this side
of the pond as the "consent of the governed": just about
everyone understood that a central registration and allocation
authority was important and, with one important exception [1],
no one had something they believed was a better idea that they
were anxious to propose.  Yes, in theory the US Government could
have stepped in, but they didn't and their behavior was such as
to lead everyone to believe that they wouldn't.   The second was
that there was a general belief that, if the rules, especially
those involving principles of responsible behavior that 1591
invokes with the "trustee for the ... community" language, were
violated IANA had both the authority and the will to, e.g., make
changes in delegations to parties who would be more responsible.

There were also a number of things -- both "rules" and
explanations -- that didn't go into 1591, either because we
didn't think of them (or think they were necessary) or because
Jon saw them simply as things he wasn't going to allow.   The
now-famous "will be alphabetic" phrasing in RFC 1123 about TLD
labels was typical: Jon knew he simply was not going to allow
TLD names containing anything other than ASCII letters.

Whether the principles underlying 1591 are "obsolete" or not
depends on some complicated questions involving one's view of
the Internet and the role of the DNS (see
draft-klensin-dns-function-considerations as well as several
RFCs that followed 1591.  Certainly, when 1591 was written, we
didn't anticipate either ICANN or the rise of the domain name
business (and, arguably, its dominance in decision-making).

Now, with that background, let me try to answer your question.
First, the ccTLD naming model was strictly limited to allocated
codes in what is now called ISO 3166-1 alpha-2 [1].
Specifically, no use of the reserved list (not sure that existed
at the time either), no private-use codes, no codes allocated by
IANA rather than a body fully responsible to ISO TC 46, and,
while there are a couple of famous mistakes (history and
explanation on request if relevant) no allocations on
speculation.

One of those rules was, AFAKK, never formally published although
at least part of it was widely understood.  That was that TLD
labels came in categories that could be determined by length,
such that filters and algorithms could be based on those
categories.  The rule was 2-3.4+, i.e.,

 * All two-letter labels were country codes derived from
	3166 alpha-2.
 * All three letter labels were generic TLDs (not all of
	which were managed under IANA supervision).
 * All labels of four characters or more were either the
	specific string "ARPA" (which was originally intended to
	be temporary and transitional) or what is now known as a
	"special use name", i.e., one that is not part of the
	global DNS or that was expected to be processed using
	some non-DNS mechanism.

ICANN staff were warned about that rule in the 1999 period but
decided to allow TLD applications for gTLDs with labels longer
than three characters and to not identify the issue to
applicants.   Many of the issues that are now seen as "universal
acceptance" problems are the result of that decision.  Whether
one assumed at the time, or concludes now, that it was a
rational, consensus, decision to favor applicant choice and
consequent competition in the TLD marketplace over that
historical rule or, even the controversies about special names,
a screwup and/or show of arrogance is very much in the mind of
the beholder.

Similarly, ICANN clearly broke the 1591 rules in allocating "EU"
as a TLD label.  It is not an ISO 3166-1 alpha-2 registered
country code and it violates some territorial overlap rules that
are intrinsic to bother 3166-1 and the assumptions underlying
1591.  At a different end of the problem, IANA's rules (pointed
to but maybe not explicit enough) is that, if a country
convinced 3166/MA to change its code, there needed to be a plan
in place to remove the older TLD within a reasonably short
period before the new code would be delegated (on a "one
territory, one code" principle)).  IIR, there was such an
agreement about "SU" before "RU" was delegated, but ICANN has
never succeeded in getting rid of "SU", violating that principle.

All of this is further complicated by IDN TLDs, where new ones
associated with countries are not limited to two characters
(even in their original scripts); non-country political entities
are allowed (if one counts GOV. MIL, and maybe INT, they have
always been allowed, but those are probably a bit different(;
and the relationships between 3166 alpha-2 ccTLDs and their IDN
relatives have never really been spelled out (despite the length
of the ccTLD Fast Track Procedure.

Whether that makes 3166 partially or completely obsolete is a
matter of personal judgment.   Because it was an IANA document,
the IETF Protocol Police would never have arrested anyone for
violating it.  Unlike the IETF and its relationship to the
Protocol Police, IANA did have the ability to enforce its
provisions (and did).  ICANN has clearly demonstrated a
willingness to violate some of its provisions (explicit or
implied) and it appears that, both prior and subsequent to the
recent "IANA transition", there is no one to tell them that they
cannot do so.  My personal opinion that the Internet would be
much better off if the principles of 1591, especially the
requirement that registries be required to act in the best
interests of the global Internet community, were followed and
enforced (see draft-klensin-idna-rfc5891bis for the specific
IDNA case) are probably worth a cup of fancy coffee after a few
Euros (or equivalent) are thrown in.

best,
    john

[1] The dissenters were largely arguing for abandoning the DNS
in favor of X.500.  At least in public, that position was
justified on the basis of developing and future technology, with
the side effect of putting the top-level entities under the
control of the ISO and ITU registration processes.
Interestingly, with regard to your question, X.500 uses ISO
3166-1 alpha-2 country codes as well.

[2]  I don't think there was more than one part of ISO 3166 at
the time Jon discovered or was pointed to the Standard and can't
remember if it contained the alpha-3 codes in addition to the
alpha-2 and numeric ones.  I do know that we never considered
anything other than the alpha-2 codes for ccTLD names, if only
because Jon wanted that system to be as deterministic as
possible with no possibility about arguments about what code
should be assigned that IANA needed to referee.

---

From: John C Klensin <[email-masked]>
Date: Fri, 30 Jun 2017 12:51:18 -0400

>...(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.

> 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. 

> 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.

---

From: Daniel Karrenberg <[email-masked]>
Date: Fri, 30 Jun 2017 18:53:27 +0200

john,

your eloquently told story agrees with personal memory and my particular
version of reality ;-).

I know for a fact that ISO3166 at the time contained at least two letter
alphabetic, three letter alphabetic and numeric codes for each country
or territory recognized by the United Nations.

I also distinctly remember a number of conversations with Jon about DNS
"going international". Jon wisely saw that IANA needed an external
authority to decide what was a country. After considering several such
authorities, the United nations appeared the most widely agreed one.
>From there it was but a short step to ISO3166. The choice for two letter
alphabetic codes was also straightforward: there were no two letter TLDs
at the time and that guaranteed that there would be no clashes with
exiting TLDs. [1]

So I would argue that ASCII ccTLDs are indeed meant to be exactly two
letters. If only to avoid clashes with future changes to ISO3166 I would
consider it to be a Bad Idea to allocate two letter ASCII strings for
any other purpose. This is why I have spoken up against ".EU" until the
ISO3166 maintenance agency published it as a "reserved" code.

Conversely it would be problematic now to have three letter ASCII ccTLDs
unless there is a clear agreement with ISO that they will never allocate
a three letter code that already exists as a gTLD. Afaik there are no
clashes right now, but past results are not a guarantee for the future.
It is never a good idea to have two 'authorities' over one part of a
name space.

dfk

[1] UK appeared at different times in at least two realities that have
been recounted to me. ;-) But there was no clash in ISO3166 at the time.

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 30 Jun 2017 13:21:31 -0400

On Fri, Jun 30, 2017 at 12:53 PM, Daniel Karrenberg <[email-masked]> wrote:
> ...

COM is the three letter code for the Comoros Islands. I believe it is
also used by a few entities as their TLD :-)

> It is never a good idea to have two 'authorities' over one part of a

Thanks,
Donald