Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 01 May 2015 09:31:11 +0200

On 30 Apr 2015, at 16:40, George Michaelson wrote:

> economy and economycode is a useful concept sometimes. it avoids the CN/TW
> issue. and encompasses HK.
>
> state or territory can be useful. covers some of the intermediate things.
> eg much of the CIS is a 'transitional state' according to the UN.
>
> iso-3166 encompasses non-state entities, AP is reserved for the african
> fisheries forum.
>
> EU is delegated. its not the same as INT.
>
> BTW, at some stage, its possible the economies will usurp the 3 letter
> codes and assert a right to have them in the DNS...

Also note that there are ccTLDs allocated for codes that are not registered in ISO3166 (UK, EU etc).

Suggested new text:

ccTLD -- A TLD that is allocated to distinct economies.  Historically, these were two-letter TLDs, and were allocated to economies using the two letter code for the economy taken from the ISO 3166-1 alpha-2 standard [ISO3166] although exceptions exists. In recent years, there have been allocations of TLDs that conform to IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]); these are still treated as ccTLDs for policy purposes.

   Patrik

> On Thu, Apr 30, 2015 at 4:35 PM, Andrew Sullivan <[email-masked]>
> wrote:
>
>> On Wed, Apr 29, 2015 at 07:28:21PM +0000, Edward Lewis wrote:
>>> #ccTLD -- A TLD that is allocated to a country.  Historically, these
>>> #were two-letter TLDs, and were allocated to countries using the two-
>>> #letter code from the ISO 3166-1 alpha-2 standard [ISO3166].  In
>>> #recent years, there have been allocations of TLDs that conform to
>>> #IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]);
>>> #these are still treated as ccTLDs for policy purposes.
>>>
>>> "Country" is a loaded term.  I don't have a better suggestion in mind but
>>> there are many instances where a ccTLD is a territory, etc.  I don't mean
>>> to open a rathole, just point this out.
>>
>> If we changed this to say, "A TLD that is allocated using the UN
>> country list using the the two-letter code from the ISO 3166-1 alpha-2
>> standard [ISO3166]," would that address your concern?
>>
>>> Might as well also list sTLD for sponsored.  Technically there is no
>>> difference, it's all in the way the registry has been instituted.
>>
>> ICANN's own policies don't actually seem to enforce the sTLD/gTLD
>> distinction, and nobody ever mentions sTLDs, so I'd as soon leave it
>> out.
>>
>>> I never thought NODATA meant NOERROR, just simply an empty answer
>> section.
>>
>> NODATA comes with a NOERROR header, or it's not a NODATA response.
>>
>>> # 6.  Zones
>>>
>>> #Parent -- The domain in which the Child is registered.  (Quoted from
>>> #[RFC7344], section 1.1) Earlier, "parent name server" was defined in
>>> #[RFC0882] as "the name server that has authority over the place in
>>> #the domain name space that will hold the new domain".
>>>
>>> Speaking from personal experience, I'd use "delegated" and not
>> registered.
>>> In my world, there is a distinction in what is "registered" and what is
>>> "delegated."  I don't mean to derail this into a registry vs. DNS
>>> operations discussion, just saying that the term "registered" means
>>> something different in a field (registration of domain names and internet
>>> numbers) very close to DNS.
>>
>> We want to cleave to the quoted documents, but do you wnat us to add
>> discussion about the distinction between "registration" and
>> "delegation"?  There's in fact a distinction also with "allocation",
>> but I'm not sure it belongs here.
>>
>>> #Delegation -- The process by which a separate zone is created in the
>>> #name space beneath the apex of a given domain.  Delegation happens
>>> #when an NS RRset is added in the parent zone for the child origin,
>>> #and a corresponding zone apex is created at the child origin.
>>> #Delegation inherently happens at a zone cut.
>>>
>>> I agreed up until "and a corresponding..."  Once the parent creates the
>>> zone cut, the delegation is made.  The distinction is that in the world
>> of
>>> operations, the child's servers may be unavailable (down or cut off the
>>> net).  The delegation is still there, no one can confirm the
>>> "corresponding" stuff mentioned here.
>>
>> Hmm, this is an interesting point.
>>
>>> Vice versa, once the parent removes
>>> the NS set, the delegation is removed regardless of what the child
>>> "thinks."
>>
>> Well, effectively maybe not.  If a resolver "sticks" on the child,
>> then the delegation won't move regardless.
>>
>>> #Referrals -- ...  Historically, many
>>> #authoritative servers answered with a referral to the root zone when
>>> #queried for a name for which they were not authoritative, but this
>>> #practice has declined.
>>>
>>> Not declined - seen as a vulnerability and removed from code.
>>
>> That's one kind of decline, isn't it?
>>
>> A
>>
>> --
>> Andrew Sullivan
>> [email-masked]
>>
>> _______________________________________________
>> DNSOP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 01 May 2015 09:35:26 +0200

On 30 Apr 2015, at 18:34, Kim Davies wrote:

> If an allusion to the purpose is useful, then:
>
> "A TLD that is allocated for use based on an entry in the ISO 3166-1
> standard [ISO 3166-1]. The ISO 3166 standard provides codings of
> countries and their subdivisions."

A TLD that is allocated for use based on an entry in the ISO 3166-1 standard [ISO 3166-1], although exceptions do exist. The ISO 3166 standard provides codings of countries and their subdivisions.
 
   Patrik

---

From: "Niall O'Reilly" <[email-masked]>
Date: Fri, 01 May 2015 09:54:35 +0100

On Thu, 30 Apr 2015 15:35:31 +0100,
> then the delegation won't move regardless.

  ISTM that in such a case, the resolver is ignoring the
  updated/(re)moved delegation, rather than that the delegation hasn't
  moved.

  Niall O'Reilly

---

From: "Niall O'Reilly" <[email-masked]>
Date: Fri, 01 May 2015 09:56:35 +0100

Niall O'Reilly

---

From: Jim Reid <[email-masked]>
Date: Fri, 1 May 2015 11:00:39 +0100

> Also note that there are ccTLDs allocated for codes that are not registered in ISO3166 (UK, EU etc).

IIUC these two are on the 3166 list as exceptionally reserved codes.

> ccTLD -- A TLD that is allocated to distinct economies.  Historically, these were two-letter TLDs, and were allocated to economies using the two letter code for the economy taken from the ISO 3166-…

I think it is unwise to use terms like "economies". Some ccTLDs on ISO 3166 are uninhabited and/or have no economy. Mentioning allocation could raise the unwelcome issue of who/what these TLDs get allocated to.

This definition may be better:

ccTLD -- A two letter string taken from the ISO 3166-1 alpha-2 standard [ISO3166] although there are some exceptions. TLDs conforming to IDNA2008 ([RFC5890-4]) have been created for some of these ccTLD and these IDNA2008 strings are treated as ccTLDs for policy purposes.

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 01 May 2015 12:23:50 +0200

> IIUC these two are on the 3166 list as exceptionally reserved codes.

Yes, but not REGISTERED, and that difference is something that created more than just a little bit of "excitement" including ISO asking whether ICANN do not understand what a registered code is when .EU was allocated.

I.e. ISO 3166/MA had nothing against .EU be allocated. In fact, given .EU was allocated as a ccTLD there was so much more reason to have EU as an exceptionally reserved code in 3166. But not the other way around.

> I think it is unwise to use terms like "economies". Some ccTLDs on ISO 3166 are uninhabited and/or have no economy. Mentioning allocation could raise the unwelcome issue of who/what these TLDs get…

That is fine with me.

I was just after 1. trying to not use the term "country" and 2. pointing out a recognition that some ccTLDs are allocated with two character codes which are not *registered* in ISO 3166.

> ccTLD -- A two letter string taken from the ISO 3166-1 alpha-2 standard [ISO3166] although there are some exceptions. TLDs conforming to IDNA2008 ([RFC5890-4]) have been created for some of these c…

Works for me.

   Patrik

---

From: Tony Finch <[email-masked]>
Date: Fri, 1 May 2015 13:54:24 +0100

They are country-code TLDs because they use the country codes from
ISO 3166. "Country codes" is the title of part 1 of ISO 3166.
http://www.iso.org/iso/country_codes.htm

There are also the IDN ccTLDs which do not use country codes but which
are allocated based on the ISO 3166 eligibility criteria.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: In southeast, northwesterly 4 or 5. In northwest, southwesterly 5
or 6. In southeast, slight or moderate. in northwest, moderate or rough. In
southeast, fair. In northwest, occasional rain. In southeast, good. In
northwest, good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Fri, 1 May 2015 14:02:56 +0100

Warren Kumari <[email-masked]> wrote:
>
> NXDOMAIN -- A colloquial expression for RCODE 3, also commonly written
> as 'NXDomain' or 'Non-Existent Domain'

NXDOMAIN etc. are not colloquialisms, they come from the 4.3BSD resolver
API. (Spelling them in lower case is weird if not wrong.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight, Portland: Northeast veering southeast, 5 to 7. Mainly moderate.
Occasional rain. Moderate or good, occasionally poor later.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 01 May 2015 06:21:26 -0700

> API. (Spelling them in lower case is weird if not wrong.)

according to

http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

it's in mixed case.

if we don't want iana to register "NXDomain" as the "name" of this rcode, we'll have to change that registry. 

-- 
Paul Vixie

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 01 May 2015 19:15:06 +0200

Tony Finch writes:

 > They are country-code TLDs because they use the country codes from ISO
 > 3166. "Country codes" is the title of part 1 of ISO 3166.

Indeed. And trying to cram both of these different means (and with
that, years of policy discussions, exceptions, mistakes such as AC
etc.) into one definition is doomed to fail.

For the purpose of this document a definition such as Kim Daves
proposed seems to me good enough.

	jaap

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 1 May 2015 20:47:29 +0200

On Fri, May 01, 2015 at 09:31:11AM +0200,
 Patrik Fältström <[email-masked]> wrote 
 a message of 189 lines which said:

> Suggested new text:
> 
> ccTLD -- A TLD that is allocated to distinct economies.
> Historically, these were two-letter TLDs, and were allocated to
> economies using the two letter code for the economy taken from the
> ISO 3166-1 alpha-2 standard [ISO3166] although exceptions exists. In
> recent years, there have been allocations of TLDs that conform to
> IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], and
> [RFC5894]); these are still treated as ccTLDs for policy purposes.

There is a risk that the very long discussion about what is a country
distracts us from an important point I would like to be added in the
definition:

>From the point of view of the DNS, there is no difference between a
ccTLD and a gTLD. This distinction is relevant only for policies.

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 1 May 2015 14:56:06 -0400

> Le 2015-05-01 à 14:47, Stephane Bortzmeyer <[email-masked]> a écrit :
> 

right. I completly agree and I was going to write almost the same thing.

suggest to remove ccTLD/gTLD and stick with TLD.

Marc.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 May 2015 12:27:47 -0700

> suggest to remove ccTLD/gTLD and stick with TLD.

Just to be clear: you want to remove terms that are commonly used in talking about the DNS from the terminology draft? I am hesitant to do this, given that they appear in DNS-related RFCs, but if the WG wants to remove them instead of defining them in a way that gets consensus, we can do that.

--Paul Hoffman

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 1 May 2015 16:25:57 -0400

> Le 2015-05-01 à 15:27, Paul Hoffman <[email-masked]> a écrit :
> 

I understand the point. I’m saying that defining ccTLD/gTLD does not really bring anything and has Stéphane wrote, is on the policy side. If we want to be exhaustive in defining all keywords and terms, I would suggest then:

ccTLD: a TLD
gTLD: a TLD
TLD: the more exhaustive version…

that way, we can achieve the goal of being « exhaustive » while not entering into various policies and exceptions that is a rathole.

Marc.

---

From: manning <[email-masked]>
Date: Sat, 2 May 2015 17:35:10 -0700

again,  this is where the document tries to cover terminology for both the DNS protocol and the DNS policy/operations (as seen through the lens of today).
I don’t see any reason to define anything other than TLD.

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: David Conrad <[email-masked]>
Date: Sun, 3 May 2015 18:22:21 -0700

Patrik,

> Yes, but not REGISTERED, and that difference is something that created more than just a little bit of "excitement" including ISO asking whether ICANN do not understand what a registered code is whe…

Are you using a formal definition of "registered" in this context?

Also, I'm curious: was there any "excitement" and/or did ISO ask similar questions when (say) .AC was created (in 1997, as opposed to .EU, which was created in 2005, according to IANA's whois)?  That is, was Jon's (apparent) policy of allocating TLDs for "exceptionally reserved" codes (a policy continued by ICANN) a source of "excitement"/questions from ISO or others or was the eyebrow raising just because ICANN was involved in .EU?

> I was just after 1. trying to not use the term "country" and 2. pointing out a recognition that some ccTLDs are allocated with two character codes which are not *registered* in ISO 3166.

My understanding of the usage of "Exceptionally Reserved" codes is that they are codes that have been reserved for a particular use at special request of a national ISO member body, governments or international organizations and that as such, those codes cannot be used for any other "country".  That would appear to fit the definition of "registered" to me, but I'm unsure what definition of "register" you're using.

The point of this pedantism is that RFC 1591 (the basis for using 3166 for two-letter TLDs as far as I am aware) did not say that only "general purpose" codes could be used for "ccTLDs", it merely said "the two letter country codes from ISO-3166". Since ISO defines everything in "ISO-3166-1 Alpha-2" as a "country code" (even things that are clearly not countries, e.g., UM and FX), it would seem reasonable to me to simply put country in quotes (with perhaps a footnote saying the "countries" are more than just countries).

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Sun, 3 May 2015 18:28:20 -0700

Hi,

> ccTLD and a gTLD. This distinction is relevant only for policies.

Not quite true. From the perspective of the protocol, a TLD is a TLD. From the point of view of the system, a ccTLD is different than a gTLD, e.g., the operational requirements are not the same.

If the goal of the document is to clarify the protocol-specific terminology without operational considerations, then simply saying TLD is probably enough. (I don't have a strong opinion.)

Regards,
-drc

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 04 May 2015 04:53:38 +0200

> Are you using a formal definition of "registered" in this context?

Yes.

> Also, I'm curious: was there any "excitement" and/or did ISO ask similar questions when (say) .AC was created (in 1997, as opposed to .EU, which was created in 2005, according to IANA's whois)?

Not that I know of.

> That is, was Jon's (apparent) policy of allocating TLDs for "exceptionally reserved" codes (a policy continued by ICANN) a source of "excitement"/questions from ISO or others or was the eyebrow raising just because ICANN was involved in .EU?

What ISO 3166/MA said was that the _only_ difference between the two, and the reason why they reacted on .EU, was that ICANN referred to .EU being reserved as a reason for registration. More below. If ICANN had only been registered EU with reference to what EU themselves had done, that would have been different. Yes, pedantic, but if that is what 3166/MA wants I think they should get that. And at the same time allow ccTLDs to be created more freely. If you understand what I mean.

> My understanding of the usage of "Exceptionally Reserved" codes is that they are codes that have been reserved for a particular use at special request of a national ISO member body, governments or…

Registered is a special table at ISO 3166/MA uses, which are not the "reserved" or "exceptionally reserved".

> The point of this pedantism is that RFC 1591 (the basis for using 3166 for two-letter TLDs as far as I am aware) did not say that only "general purpose" codes could be used for "ccTLDs", it merely…

According to 3166/MA, _any_ code that people want to use can be used for anything. They *register* what _other_ organizations use. So the sensitivity here is in what direction the pointer is pointing.

3166/MA is specifically reserving things that other organization uses. I.e. 3166/MA want to have an exceptionally reserved code of EU just because ICANN has decided to use EU as a ccTLD. To be able to do that, they do not want ICANN to register a ccTLD of .EU with an argument that 3166/MA has reserved EU. That would end up being a circular reference.

A *registration* in 3166/MA on the other hand is something that happens because someone else (UN Statistics Division, UPU or someone) decides to use a code, and 3166/MA decides to actually register the code. That can be referenced by anyone (except the one that have done the registration).

I.e. 3166/MA is only acting based on decisions other parties have made, not the other way around.

   Patrik

---

From: David Conrad <[email-masked]>
Date: Sun, 3 May 2015 20:25:18 -0700

[This has drifted a ways off from DNS terminology, so I changed the subject]

Patrik,

Sorry, I'm a bit confused.

> What ISO 3166/MA said was that the _only_ difference between the two, and the reason why they reacted on .EU, was that ICANN referred to .EU being reserved as a reason for registration.

ICANN argued that EU should be registered because .EU was reserved?

> 3166/MA is specifically reserving things that other organization uses. I.e. 3166/MA want to have an exceptionally reserved code of EU just because ICANN has decided to use EU as a ccTLD.

I presume a "does not" is missing there, i..e, "3166/MA DOES NOT want to ..."

> To be able to do that, they do not want ICANN to register a ccTLD of .EU with an argument that 3166/MA has reserved EU. That would end up being a circular reference.

Understandable. if the EU ISO-3166 hadn't been exceptionally reserved (like AC, UK, etc), I would have presumed that ICANN would have simply rejected a request to register .EU.

> A *registration* in 3166/MA on the other hand is something that happens because someone else (UN Statistics Division, UPU or someone) decides to use a code, and 3166/MA decides to actually register…

The 2-letter code "EU" was not in use by "someone else" prior to ICANN being asked (presumably by the EU) to create it as a ccTLD?  Or is the parenthetical the issue: that the only "someone else" was the EU itself, so 3166/MA refused to register that code in their internal registration table and someone argued that ICANN's use constituted a valid "someone else"?

Sorry for the confusion.

Thanks,
-drc

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 04 May 2015 07:16:43 +0200

> [This has drifted a ways off from DNS terminology, so I changed the subject]

Thanks!

Note that if we look at the original discussion, my only point is that we should not claim ccTLDs are only allocated according to ISO 3166, but that there is freedom to create two letter codes -- and that this has happened.

Yes.

> I presume a "does not" is missing there, i..e, "3166/MA DOES NOT want to ..."

No, 3166/MA did not mind allocating a code just because of the use as a ccTLD.

> Understandable. if the EU ISO-3166 hadn't been exceptionally reserved (like AC, UK, etc), I would have presumed that ICANN would have simply rejected a request to register .EU.

In those days it was only reserved. In reality, EUR was reserved due to the use as a currency, and the two letter reserved code was EU.

My point is that what ISO 3166/MA did not like was exactly what you say. It would have been much better if ICANN would "just" have allocated EU just because EU so wanted.

> The 2-letter code "EU" was not in use by "someone else" prior to ICANN being asked (presumably by the EU) to create it as a ccTLD?

Correct.

> Or is the parenthetical the issue: that the only "someone else" was the EU itself, so 3166/MA refused to register that code in their internal registration table and someone argued that ICANN's use constituted a valid "someone else"?

They could not register it as it was not in use "by someone else". Only EUR was.

If ICANN would have "just" allocated EU for use as a ccTLD, without referencing ISO 3166/MA, EU could (my guess) have become a *registered* code, and ICANN would have been just like UPU and others one of the organizations 3166/MA reference.

I.e. 3166/MA is very careful with it not being the ones that register codes. Other organizations do make the decisions. They only keep the registry (which of course in turn require careful determination and decision making -- also quite sensitive). Similar wording I have heard from....hmmm....IANA ;-)

But I do understand ICANN want to keep referencing 3166 "as much as possible". That way to get a ccTLD one need a few things to happen:

1. Someone must allocate the code for some specific use (or at least make it clear a code should be there, but it does not matter which one  it is)

2. ISO 3166/MA must recognize this [1] decision and register the code

3. ICANN detect that ISO 3166/MA has recognized the allocation in [1] and approve the ccTLD given a request is sent in that fulfils whatever other requirements there is

Now, my point is that we can simply say that what can happen is also [3] directly, and leave it open for discussions between ICANN and whoever else to just allocate a code. Why limit "ourselves" when we know exceptions will happen? Although we can say it WILL be an exception.

> Sorry for the confusion.

This IS confusing! :-)

I bet Jaap can tell you quite a number of (horror) stories....

   Patrik

P.S. When .EU was created as a ccTLD I did get quite a number of phone calls and email from ISO 3166/MA, and even if I have kept my email very very organized (I thought) there are a number of them that I unfortunately can not find anymore. Reason for me to be contacted was the various hats I did wear at the time plus the fact Swedish Standard Organization is one of the members of 3166/MA so they did reach out to me. But I see over and over again that it would be better for me to instead of relying on my memory reference actual email... :-( But I do remember one asking basically "Do ICANN know what they are doing?" to which I responded sort of "Yes, they just are not clear enough about terminology, so please relax a bit."

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 04 May 2015 08:43:43 +0200

On 4 May 2015, at 7:16, Patrik Fältström wrote:

> I.e. 3166/MA is very careful with it not being the ones that register codes.

Let me add...but they have not been so careful with what codes they reserve. Remember that in those days the list of reserved codes was not public (although IANA did have access to it as part of the coordination I try to describe).

The issue with referencing something only being reserved by ISO 3166/MA and not registered implied a much lower barrier had been passed to get a ccTLD. It would only require being on the reserved list. When in reality ISO 3166/MA rather want ICANN to decide what should be a ccTLD (part from registered codes) and then when ICANN had allocated something that was not registered, it could become registered by 3166/MA.

The reserved list was made for, as you imply make it easier for people like ICANN to do the allocation. But ICANN can not do the allocation with the argument that it is reserved. ICANN could have said "we allocate this because we a. want to, and b. because according to what we see in the material ISO 8859/MA produces, there is a very low risk of future collissions".

But instead ICANN have, and still am, referring to EU be on the reserved list (and now exceptionally reserved) as a reason to allocate as a ccTLD.

I.e. I have to try to explain this story about every year, to ICANN staff, which I feel is sad.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 May 2015 09:22:24 +0100

> Note that if we look at the original discussion, my only point is that we should not claim ccTLDs are only allocated according to ISO 3166, but that there is freedom to create two letter codes -- a…

I think that claim (which, if true, is I suspect Bad News For ICANN™,
but none of my business) is yet another reason to remove the
definitions from the document.  I still think that defining TLD is
useful, and I suspect in that definition we'd want to add the
sentence, "TLDs are often divided into ccTLDs and gTLDs; the division
is a matter of policy in the root zone, and beyond the scope of this
document." Or something like that.  Any objection?  The point of
adding this is to give people some clue about these terms when they
come across them and to indicate that it's a matter of policy and not
protocol.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 4 May 2015 09:25:03 +0100

> On May 4, 2015, at 9:22 AM, Andrew Sullivan <[email-masked]> wrote:
>  I still think that defining TLD is

This is exactly what needs to be said. I don’t think you can go further without getting lost in the weeds, and I don’t think it’s necessary— operators just need to know the distinction isn’t protocol.

Suzanne

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 04 May 2015 11:18:58 +0200

"Patrik Fältström" writes:

 > 
 > But instead ICANN have, and still am, referring to EU be on the reserved
 > list (and now exceptionally reserved) as a reason to allocate as a ccTLD.
 > 

If one read the board resolution approving EU as a (cc-)TLD, one will
notice that this is really an exception [1]
<https://community.icann.org/display/tap/2005-03-21+-+Delegation+of+.EU>.
In the second Whereass, the board takes, I think, a liberty mentioning
TLD. As far as I know, the possibility of using EU as an TLD is not
explicitly mentioned by the MA. The reason that the board could made
tte exception is the footnote in the List of exceptionally reserved
alpha-2 code elements stating that "In August 1999, extension of scope
to any application needing to represent the name European Union." [2]

But yes, EU was originally reserved for ISO 4127 to be used in valuta
code. Valuta codes consist of an alpha-2 3166 code + a single letter
saying something about the name of the money. So one has the USD, AUD,
SGD (US, Australian & Singapore Dollar) the SEK, DKK (Danish & Swedish
Krone) the INR & EUR (Indian Rupee & Euro). (Yes, that single letter
is used inconsistently).

In March 1998 the scope was extended so th code could be used by the
international securities identification numbering system (ISIN). These
guys to have asked (and received) for more codes for securities, but I
digress. Apparently in August 1999 the scope was extended again, given
fuel for the EURid get the delegation. I wasn't around at that time so
I cannot comment how and on the later extension was made and on
behalve of whom.

	jaap

[1] <https://community.icann.org/display/tap/2005-03-21+-+Delegation+of+.EU>.
For fun, see also
<http://www.iana.org/reports/2005/eu-report-05aug2005.pdf> for the public
IANA report.

[2] <http://web.archive.org/web/20030801082348/http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html>.

[3] <http://web.archive.org/web/20030810102245/http://www.iso.org/iso/en/prods-services/iso3166ma/04background-on-iso-3166/reserved-and-user-assigned-codes.html#reserved>.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 04 May 2015 11:35:54 +0200

Andrew Sullivan writes:

 > document." Or something like that.  Any objection?
 
No objection.

 > The point of

Yep. One could name sTLD (Sponsored TLD) and infrastructural TLDs as
well although it might distract again from the main point: There is a
difference between protocol and naming policy.

	jaap

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 04 May 2015 11:42:35 +0200

> This is exactly what needs to be said. I don’t think you can go further without getting lost in the weeds, and I don’t think it’s necessary— operators just need to know the distinction isn’t protoc…

Agree. I think the largest issue is:

a. Policy in general (how the TLD is approved, registry appointed/redelegated etc)

b. Eventual contractual arrangements with ICANN corp

   paf

---

From: Edward Lewis <[email-masked]>
Date: Mon, 4 May 2015 11:45:09 +0000

On 5/4/15, 4:22, "Andrew Sullivan" <[email-masked]> wrote:

>"TLDs are often divided into ccTLDs and gTLDs; the division

My one addition would be to word this such that the division is not just
ccTLD and gTLD, but those are examples.  ("into ccTLDs, gTLDs, and other
categories;")[0]

For a DNS terminology document, that is all that is needed.  Top-level
Domains, as a black box, are the same to the DNS protocol and operator.

Unless you are running DNS for one or more TLDs. ;)

[0] - Because to others, sTLDs matter, .brand TLDs matter, IDN TLDs
matter, IDN ccTLDs matter... not to DNS protocol matters itself except we
get sidetracked talking about these things.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 May 2015 12:48:34 +0100

> ccTLD and gTLD, but those are examples.  ("into ccTLDs, gTLDs, and other

I'm not opposed to the "and other categories", but the truth is that
anyone who cares about DNS never hears about those other categories.
Even around ICANN policy discussions everything that isn't a ccTLD is
treated as a subclass of gTLD.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 4 May 2015 17:34:13 +0200

On Fri, May 01, 2015 at 04:25:57PM -0400,
 Marc Blanchet <[email-masked]> wrote 
 a message of 24 lines which said:

> If we want to be exhaustive in defining all keywords and terms, I
> would suggest then:
 
I support Andrew Sullivan's version: "TLDs are often divided into
ccTLDs and gTLDs; the division is a matter of policy in the root zone,
and beyond the scope of this document."

---

From: Dan York <[email-masked]>
Date: Mon, 4 May 2015 15:54:26 +0000

Stephane,

On May 4, 2015, at 11:34 AM, Stephane Bortzmeyer <[email-masked]<mailto:[email-masked]>> wrote:

Would you support Ed Lewis’ modification of that text into this?

 "TLDs are often divided into ccTLDs, gTLDs and other categories; the division is a matter of policy in the root zone, and beyond the scope of this document.”

I agree with the comments on the list that specifying only ccTLDs and gTLDs is later going to leave it open for someone to say that “qTLDs” or whatever are special in a different way and need different treatment, etc.

The key point here is that from the DNS *protocol* level “TLDs” are what matters.  All the other distinctions of the various types of TLDs don’t (at the current time, anyway) affect how the operations really work.

My 2 cents,
Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/<http://www.internetsociety.org/deploy360/>

---

From: "John Levine" <[email-masked]>
Date: 4 May 2015 16:07:13 -0000

>>document." Or something like that.  Any objection?

I think it has to be ccTLDs, gTLDs, and legacy TLDs to include ARPA,
EDU, MIL, GOV and maybe INT.  But I entirely agree that it would not
be productive to further try to define what they are.

R's,
John

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 4 May 2015 21:02:24 +0100

Hi Dan, Stephane, Andrew, Ed, folks,
 I also prefer Ed Lewis' variant **. 
Enumerating all flavours of TLD would be excessive, but mentioning only gTLDs and ccTLDs -without a hint that there may be other variants- is a false friend, IMHO.
Hence please can we go for the version with "and other categories".
With that tweak the overall text here seems perfect to me, as it specifically excludes discussion of organisation or policy.

all the best
  Lawrence
** I'm biased as I was involved with one, so I have also heard of sTLDs.

On 4 May 2015, at 16:54, Dan York <[email-masked]> wrote:
> Stephane,
> 
>> On May 4, 2015, at 11:34 AM, Stephane Bortzmeyer <[email-masked]> wrote:
>> 
> [email-masked]   +1-802-735-1624
> Jabber: [email-masked] 
> http://www.internetsociety.org/

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 5 May 2015 09:42:46 +0200

On Mon, May 04, 2015 at 03:54:26PM +0000,
 Dan York <[email-masked]> wrote 

> Would you support Ed Lewis’ modification of that text into this?

Yes

>  "TLDs are often divided into ccTLDs, gTLDs and other categories;
>  the division is a matter of policy in the root zone, and beyond the
>  scope of this document.”

---

From: David Conrad <[email-masked]>
Date: Wed, 6 May 2015 09:06:57 -0700

I have never heard of ARPA being treated as a subclass of gTLD.

Regards,
-drc

> On May 4, 2015, at 4:48 AM, Andrew Sullivan <[email-masked]> wrote:
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 May 2015 22:59:28 +0100

Since I already said I was ok with the addition, can we just stipulate that I'm wrong and move along with it?   

A
-- 
Andrew Sullivan 
Please excuse my clumbsy thums. 

> On May 6, 2015, at 17:06, David Conrad <[email-masked]> wrote:
>