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

From: [email-masked]
Date: Wed, 29 Apr 2015 11:13:41 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : DNS Terminology
        Authors         : Paul Hoffman
                          Andrew Sullivan
                          Kazunori Fujiwara
	Filename        : draft-ietf-dnsop-dns-terminology-01.txt
	Pages           : 21
	Date            : 2015-04-29

Abstract:
   The DNS is defined in literally dozens of different RFCs.  The
   terminology used in by implementers and developers of DNS protocols,
   and by operators of DNS systems, has sometimes changed in the decades
   since the DNS was first defined.  This document gives current
   definitions for many of the terms used in the DNS in a single
   document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-terminology/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-dns-terminology-01

A diff from the previous version is available at:
https:https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-terminology-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Apr 2015 11:19:17 -0700

Greetings. We got a lot of good feedback near the beginning of the WG Last Call, and wanted the WG to see the current state so we can get more comments. As you can see from the diffs (https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-terminology-01), we have made significant changes to "public suffix", "authoritative server", "secondary server" / "primary server", "forwarding" / "forwarder", "policy-implementing resolver", and "passive DNS".

Please continue to comment on these, or any other part of the draft. Thanks!

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Wed, 29 Apr 2015 19:28:21 +0000

Somewhere I saw "domaine" in the doc - can't find it now - and that
started me trying to mark this up.  (I hadn't read the document in full
before, so this is a first review for me.)

> This draft is a work item of the Domain Name System Operations Working

Comments in-line

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

#gTLD -- A "generic" TLD is a TLD that is not a ccTLD, and is not one
#of the small number of historical TLDs such as .int and .arpa.  There
#is no precise definition for which TLDs that are not ccTLDs are
#gTLDs.

Might as well also list sTLD for sponsored.  Technically there is no
difference, it's all in the way the registry has been instituted.

#Public suffix -- A domain under which subdomains can be registered,
#and on which HTTP cookies ([RFC6265]) should not be set.  There is no
#indication in a domaine name whether or not it is a public suffix;
#that can only be determined by outside means.  The IETF DBOUND
#Working Group [DBOUND] deals with issues with public suffixes.

I wouldn't mention DBOUND as WGs come and go but RFCs are forever.

#3.  DNS Header and Response Codes

#NODATA - This is not an actual response code, but is a particular
#type of response from a server that indicates that the queried domain
#name exists for the given class, but the resource record type being
#queried for does not exist.  A NODATA response is a combination of an
#RCODE of 0 (NOERROR) and an Answer section that is empty.  In
#addition, NODATA responses from authoritative servers have the
#authoritative answer (AA bit) set to 1 and include an SOA record.
#Section 1 of [RFC2308] defines NODATA as "a pseudo RCODE which
#indicates that the name is valid, for the given class, but are no
#records of the given type".  The term "NXRRSET" is becoming more
#common as a synonym for NODATA.

I never thought NODATA meant NOERROR, just simply an empty answer section.
 I have never seen the term outside of "NOERROR/NODATA" either, so is
might see NODATA implies RCODE=0.  Just my personal viewpoint.

#Negative response -- A response whose RCODE indicates that a
#particular RRset does not exist in the DNS or a failure of a
#nameserver.  Sections 2 and 7 of [RFC2308] describes the types of
#negative responses in detail.

More simply (and not the same as the above) a failure to find requested
records.  I.e., not a name server failure.  Perhaps my interpretation
differs because it's never been stated what is a "final" response or an
"intermediary" response - i.e., what is sent to a stub upon its request as
opposed to a referral.

# 4.  Resource Records

#EDNS -- Also commonly called "EDNS0", this is the extension
#mechanisms for DNS.  The extension mechanism, defined in [RFC6891],
#allows DNS clients and servers to specify message sizes larger than
#the original 512 octet limit, to expand the response code space, and
#to potentially carry additional options that affect the handling of a
#DNS query.

Often misspelled as ENDS. ;)

# 5.  DNS Servers

#[[ There is a request to "first describe the iterative and recursive
#resolution processes, and mention the expected values of the RD,RA,AA
#bits.  Then you can describe the distinctions between recursive and
#iterative clients, and between recursive and authoritative servers,
#in terms of the roles they play in the different resolution
#processes."  This would require the section to be quite different
#than the other sections in the document. ]]

The fact that this request has been made is an indication that needed RFCs
haven't been written.  This document isn't the place to do that, IMHO.  A
lot of "things" just have never been documented.

#to those "outside" that network.  Views are not a standardized part
#of the DNS, but they are widely implemented in server software.

"not a standardized part...but...widely implemented"  From this, we need
to do more writing.

#Child-centric resolver -- A DNS resolver that, instead of serving the
#NS RRset and glue records that it obtained from the parent of a zone,
#serves data from the authoritative servers for that zone.  The term
#"child-centric" is meant as the opposite of "parent-centric", which
#means a resolver that simply serves the NS RRset and glue records for
#a zone that it obtained from the zone's parent, without checking the
#authoritative servers for that zone.

Count me as wondering why this term is included here.  Perhaps the
terminology document, especially for terms outside the RFCs, should cite
where the terms are in use.  I'm not disagreeing with the text above, I
just don't know why this term is even being considered.

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

#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.  Vice versa, once the parent removes
the NS set, the delegation is removed regardless of what the child
"thinks."

#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.  The
practice was never defined as a part of the DNS protocol.  When it became
the subject of abusive traffic, implementers agreed to stop issuing
"referrals to the root" to indicate lame servers.

#Fast flux DNS -- A mechanism where a large number of hosts rapidly
#update the address records of a zone, often to deliver malware.
#Because the addresses change so rapidly, it is difficult to
#definitively find all the hosts.

Really would help to have references.  The definition is good but if this
were wikipedia...

# 7.  Registration Model

#Registry -- The administrative operation of a zone that allows
#registration of names within that zone.

A registry is the database (in the virtual sense) used by a DNS
administration to know what information to include in a zone.  The
database may be in one's head, in a text file, in Oracle, etc.  The
database schema may have contact information for each domain name.
Essential to the DNS is that there is a record of what data sets are in
the zone (A, AAAA, NS, etc.).  Registries may range from the back of one's
head to full-time, high capacity operations. (This is off the top of my
head. I'd never thought to define a registry in the DNS protocol sense
before.)

Since you are "going there" - define the "Shared Registry Model".  Web
searching for this includes this:
http://www.difo.dk/en/internet_governance/sole_vs_shared_registry_model/

But I don't know if you really want to open this document to get into
registration of data and how that impacts the DNS.  To me, registration !=
DNS operation, despite appearances otherwise.

#8.  General DNSSEC

#Most DNSSEC terms are defined in [RFC4033], [RFC4034], and [RFC4035].

(To get this response off sooner, I'll skip the DNSSEC stuff as it seems
to be tied to documents.  If there's a need to make DNSSEC less confusing
[cough, cough]...that'll take more work.)

---

From: Warren Kumari <[email-masked]>
Date: Wed, 29 Apr 2015 15:54:43 -0400

First off - thanks for writing this. I personally *hate* writing
terminology sections in drafts; that someone is willing to write an
entire terminology draft, especially one on DNS fills me with awe...

Anyway, Section 3:
"Some of response codes that are defined in [RFC1035] have gotten
   their own shorthand names.  Some common response code names that
   appear without reference to the numeric value are "FORMERR",
   "SERVFAIL", and "NXDOMAIN".  All of the RCODEs are listed at
   http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml,
   although that site uses mixed-case capitalization, while most
   documents use all-caps."

This is all true, but I'm not sure it says enough. I've used the term
NXDOMAIN in a few documents, and folk have pointed out that the are
not actually defined (or that it is an implementation specific term
(because of case?!)) , so we end up with things like:
"... MUST return a DNS response with the RCODE set to 3 (also commonly
known as an 'NXDOMAIN')".

I realize that this is a terminology draft, and not a definition doc,
but if it had something like:

NXDOMAIN -- A colloquial expression for RCODE 3, also commonly written
as 'NXDomain' or 'Non-Existent Domain'
or something similar we could write cleaner documents....

W

On Wed, Apr 29, 2015 at 2:13 PM,  <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Apr 2015 13:02:04 -0700

Thanks for the comments.

> before, so this is a first review for me.)

<sigh> Found it. Fixed.

> to open a rathole, just point this out.

"Country" is a term of art in politics. There are definitions that most people agree to, at least when it suits them.

> difference, it's all in the way the registry has been instituted.

I think "sTLD" is a term used in ICANN, not in the DNS, whereas gTLD has definitely slipped into DNS language.

> I wouldn't mention DBOUND as WGs come and go but RFCs are forever.

*Many* RFCs mention WGs in various ways. Note that, even though WGs come and go, even closed WGs are listed on the IETF web site.

> might see NODATA implies RCODE=0.  Just my personal viewpoint.

This confuses me, given the definition in RFC 2308. Are you saying that a NODATA response might have an RCODE that is not 0? If so, what are the allowed values for RCODE in a NODATA response?

> records.  I.e., not a name server failure.  

That definition is at odds with RFC 2308, which says:

7 - Other Negative Responses
. . .
7.1 Server Failure (OPTIONAL)

> Perhaps my interpretation

I'm not seeing any use of those terms in RFCs, but I might have missed them.

> Often misspelled as ENDS. ;)

Appendix A. Common Misspellings of DNS Trems

> lot of "things" just have never been documented.

That's what I feel as well, but we wanted to leave the comment in for the WG LC in case someone wants to tackle the rewrite.

> "not a standardized part...but...widely implemented"  From this, we need

...but not here.

> just don't know why this term is even being considered.

There were a few requests from the WG earlier. I'm happy to take it out, given that it doesn't appear in any RFC.

> numbers) very close to DNS.

I agree with you about "delegated" being a better word, but if we're going to quote from RFCs, particularly recent ones that were vetted in this WG, we shouldn't be changing the words.

> the NS set, the delegation is removed regardless of what the child

That seems rational. Do others agree that we should remove "and a corresponding zone apex is created at the child origin" because that step is not necessary for a delegation to take place?

> "referrals to the root" to indicate lame servers.

...and thus the practice has declined. We could add text about why it has declined, but it doesn't help the definition.

> Really would help to have references.  The definition is good but if this

Fully agree, but I failed to find anything. There was enough interest in the WG to add the term; I would rather not remove it just because we can't give a definitive pointer to a definition.

> head. I'd never thought to define a registry in the DNS protocol sense

Do others here want to go into that level of detail? It might be useful for some readers, or it might be "too much".

> DNS operation, despite appearances otherwise.

Also, that term seems to be barely used.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Apr 2015 13:09:46 -0700

> or something similar we could write cleaner documents....

We had a definition for NXDOMAIN in an earlier version of the draft, but were asked to take it out. I'm with Warren on this (it should be in there), so maybe the WG wants to talk about this more...

--Paul Hoffman

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 29 Apr 2015 22:26:11 +0200

> "Country" is a term of art in politics. There are definitions that most people agree to, at least when it suits them.

RFC 1591 purposely does not define what a country is.  ISO 3166-1
contains a definition what constitutes a country.

	jaap

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Apr 2015 13:36:02 -0700

> contains a definition what constitutes a country.

Exactly. Note that even though 1591 doesn't define "country", Jon used "country TLDs" and "country domains" and "country code" throughout.

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Wed, 29 Apr 2015 23:56:56 +0000

>This confuses me, given the definition in RFC 2308. Are you saying that a
>NODATA response might have an RCODE that is not 0? If so, what are the
>allowed values for RCODE in a NODATA response?

>...

>given that it doesn't appear in any RFC.

The above responses give me a confused idea of what the guidelines of the
draft is following.

I'll start with an observation that does not directly relate to the draft
which does put me in an awkward position.  The language used in the RFCs
is not exactly the language used in operations.  Yes, most words are the
same but not all.

If the draft is going to "firm up" RFC terminology, it should do so
consistently.  If the term is not in any RFC, leave it out.  If the draft
is going to "firm up" the language used to describe the DNS, then it
should capture more operational jargon and note when some RFC language has
fallen by the wayside.

E.g., NODATA - I've never heard that outside of "NOERROR/NODATA".  From
that I would have never associated NODATA with any meaning of the RCODE.
As for gTLD - that is as much an ICANN term as sTLD.

I'm not arguing the point of any of the definitions, it's just that from
the responses I don't see consistency.

Clarifying the words in RFCs is fine and that can be done by a document
search.  Clarifying the words used in operations ought to include a survey
of operators (outside of the IETF), which may expose conflicting uses of
terminology because in-house operations don't always communicate
externally.  For example, on one environment where I worked "the resolver"
was an authoritative server.  The name came that way because it was
"resolving" the query from a database backend.  This caused a lot of
confusion amongst young recruits who tried to learn from RFCs.

>I agree with you about "delegated" being a better word, but if we're
>going to quote from RFCs, particularly recent ones that were vetted in
>this WG, we shouldn't be changing the words.

>Fully agree, but I failed to find anything. There was enough interest in
>the WG to add the term; I would rather not remove it just because we
>can't give a definitive pointer to a definition.

This puzzles me ... if the term isn't described anywhere, why define it?
For "fastflux" this was a term that seemed to have jumped the shark, it
has more historical meaning that current use.

My sympathies with all this.  I'm just registering that to help, I'd need
a clearer idea of where you want to take this.  Or the WG want to take
this.

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 30 Apr 2015 01:24:08 +0100

> Exactly. Note that even though 1591 doesn't define "country", Jon used "country TLDs" and "country domains" and "country code" throughout.

To which I reply:
 Yup, but at the point RFC1951 came out no-one .ps was still to be approved.

This is a rat-hole, but I'd be more comfortable if it said "country/territory".
[also, .je, .im, and so on]
Oddly enough, the Wiki page for ccTLDs looks OK-ish at first blush, to these reumy eyes at least.

IMHO, [though NOT for all those cute videos] Sponsored TLDs are worth putting in if you're going to put in gTLD and ccTLD.

all the best,
 Lawrence

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Apr 2015 17:36:42 -0700

> The above responses give me a confused idea of what the guidelines of the

Yep. We have some guidelines at the front of the document, and we generally try to follow them. However, this is now an WG consensus document, not an individual submission from Andrew/Kazunori/Paul. Given that, if the WG wants something added that doesn't exactly follow the guidelines, the answer should usually be "yes".

> is not exactly the language used in operations.  Yes, most words are the

Fully agree. If the DNSEXT WG still existed now, this document would have been in that WG, not here. However, that's not the reality we are given.

> consistently.

That was never a goal of the document. There has been some value in giving definitions from RFCs more explanation, but we never intended to limit to only terms defined in RFCs.

> If the term is not in any RFC, leave it out.  If the draft

That's more what we want.

> As for gTLD - that is as much an ICANN term as sTLD.

RFC 2308, a standards-track document, uses the term as "NODATA" by itself. So does RFC 3971, 5617, and 7129. RFCs 4956 and 6840 use NOERROR/NODATA.

> the responses I don't see consistency.

Fully agree.

> confusion amongst young recruits who tried to learn from RFCs.

Proposing that we stop work on this document until someone does such a survey is fine. Clearly, I don't favor that approach, but others might.

> This puzzles me ... if the term isn't described anywhere, why define it?

Because it is wide use in the press, and because the WG asked us to.

> has more historical meaning that current use.

I still hear it in use.

> a clearer idea of where you want to take this.  Or the WG want to take

If I could give you a clearer idea, I would. The best I can say is "this is a WG consensus document, and the authors try to read the consensus; if we do that wrong, we assume the chairs will correct us".

--Paul Hoffman

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 29 Apr 2015 21:12:26 -0400

> should capture more operational jargon and note when some RFC language has

Speaking only for myself as a chair, I'd like to mention that the 
decision was made to "document" existing terminology, not try to 
redefine or even "firm up" RFC terminology.  That I feel would be a 
Standards Track document and those terminology should stand alone by 
itself.

tim

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 30 Apr 2015 15:35:31 +0100

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

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

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

> "corresponding" stuff mentioned here.

Hmm, this is an interesting point.

> Vice versa, once the parent removes

Well, effectively maybe not.  If a resolver "sticks" on the child,
then the delegation won't move regardless.

> Not declined - seen as a vulnerability and removed from code.

That's one kind of decline, isn't it?

A

-- 
Andrew Sullivan
[email-masked]

---

From: George Michaelson <[email-masked]>
Date: Thu, 30 Apr 2015 16:40:45 +0200

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Apr 2015 08:07:54 -0700

> standard [ISO3166]," would that address your concern?

I would be fine with that wording, but it doesn't hint at what "cc" stands for. Again, Jon Postel used the word "country code" and "country this" and "country that" quite liberally in RFC 1591. I'm not convinced we need to step away from that now.

On Apr 30, 2015, at 7:40 AM, George Michaelson <[email-masked]> wrote:
> economy and economycode is a useful concept sometimes. it avoids the CN/TW issue. and encompasses HK.

ISO 3166 is based on countries, not economies. If it were the latter, "CA" would be given to "California".

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

In UN circles, both of those terms have been more loaded than "country" for at least 40 years. (And we're not just talking the Middle East, as older folks in .tw can attest.)

> iso-3166 encompasses non-state entities, AP is reserved for the african fisheries forum. 

Every SDO has assignments like this. 'Twas ever thus.

--Paul Hoffman

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 30 Apr 2015 11:52:43 -0400

> I would be fine with that wording, but it doesn't hint at what "cc" stands for. Again, Jon Postel used the word "country code" and "country this" and "country that" quite liberally in RFC 1591. I'm…

I don't think we do. How about: 

"ccTLD-- Informally, a TLD that is allocated to a country or similar geographic or economic entity, defined as a matter of policy. More formally, a TLD that is allocated…."

The reference to ISO3166 is important to explain as a matter of technical correctness, but the more colloquial usage is what people expect.

Does that help?

best,
Suzanne

---

From: Kim Davies <[email-masked]>
Date: Thu, 30 Apr 2015 16:34:15 +0000

Quoting Andrew Sullivan on Thursday April 30, 2015:
| > 
| > "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?

The ISO 3166-1 standard itself refers to its scope as "countries", and
the broader ISO 3166 standard for "countries and their subdivisions".
ICANN tends to say "countries or territories". I'd suggest trying to
avoid the politically-fraught issue if practical.

Also note that not all ccTLDs are two-letter codes pulled from the
standard. With the advent of IDN ccTLDs, the domain itself is not
derived from the ISO 3166-1 standard, only whether a particular
geographic entity has standing to have a ccTLD.

My suggestion:

  "A TLD that is allocated for use based on an entry in the ISO 3166-1
  standard [ISO 3166-1]".

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

kim

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 30 Apr 2015 17:44:05 +0100

> geographic entity has standing to have a ccTLD.

There's already text in there for this.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 30 Apr 2015 14:18:32 -0400

> I would be fine with that wording, but it doesn't hint at what "cc" stands for. Again, Jon Postel used the word "country code" and "country this" and "country that" quite liberally in RFC 1591. I'm…

The “what’s a country” issue is one that we confront constantly, as people ask us for statistics about Internet bandwidth production, traffic flows, and yes, even TLDs.  There’s just no clean answer.  Whether that be the island of Sint Maarten/Saint-Martin (half constituent country of the Kingdom of the Netherlands, half overseas collectivity of France) or Cyprus, mention of which always triggers pro-forma outrage from Turkey.

I completely agree that we should be clear that “cc” stands for Country Code, and I think we should defer to ISO for their own definition of ISO 3166: "ISO 3166 is the International Standard for country codes and codes for their subdivisions” no matter how inaccurate that actually seems.  Because it’s good enough, and this is a complex issue that we’re not going to solve, given how many other people have tried and failed.

But we can acknowledge the complexity, and use some word other than “country” to describe how the Internet uses these codes.

For instance, we could refer to domains associated with “geographic territories,” including both ccTLDs, geographic ngTLDs, and geographic IDN TLDs.

                                -Bill

---

From: Edward Lewis <[email-masked]>
Date: Thu, 30 Apr 2015 18:44:01 +0000

On 4/30/15, 14:18, "Bill Woodcock" <[email-masked]> wrote:

>But we can acknowledge the complexity, and use some word other than
>“country” to describe how the Internet uses these codes.

Agreeing with Woody, when I started the rathole, that is what I had in
mind.

I realize that some feel that this is a petty, nitpicky issue.  But I, and
others, have been witnessed situations where this is a major point of
contention.  In the sense of acknowledging the world is bigger than any
single vantage point, I believe that the DNS terminology document would be
better representative of community consensus if this was taken into
account.

Need to figure on an alternative...