Subject: Re: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld

From: Roy Arends <[email-masked]>
Date: Sun, 1 Aug 2021 22:45:23 +0100

> On 30 Jul 2021, at 23:03, Rob Wilton (rwilton) <[email-masked]> wrote:
> 
> Hi Roy, WG,

Hi Rob,

> Roy, just for clarity, am I right to presume that the status of the document that you propose would purely be informational?

Correct.

> It is, of course, up to the WG to decide what to do with this document, but I would like to make a couple of comments that may help the WG.
> 
> I would like to somewhat echo a point that was made in DNSOP yesterday when this draft was being discussed, in that I don't believe that IETF should publish a document that either directly or indirectly undermines ISO TC46's ownership or authority over the ISO3166 code points.  I believe that this concern is likely shared by other ADs.

That was never the intent. When you read the document, it actually underwrites ISO TC46’s ownership or authority over the ISO3166 code points. Especially the part that the User Assigned code points are assigned to the user of the standard…. 

> Hence, if the WG decides to progress this document with the proposed structure below, then I'm not convinced that just documenting that these code points exist and that some people use them would be sufficient.

Even though these code points exist and folks are (rightly, IMHO) using, for instance, .QY and the likes.

>  Given the informal liaison feedback that was received,

I think the liaison feedback is not on par with the questions asked by the chairs of the IETF and IAB. IMHO it has actively undermined it.

> I think that the IETF would likely need to adopt stronger wording that proactively recommends that these country codes are not used for private networks, and highlights the potential problems with doing so.

How is that not asserting ownership or authority over the ISO code points? 

Roy

> 
> Regards,
> Rob
> // Ops AD
> 
> 
> 
> -----Original Message-----
> From: DNSOP <[email-masked]> On Behalf Of Roy Arends
> Sent: 30 July 2021 19:21
> To: dnsop <[email-masked]>
> Subject: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld
> 
> Dear WG
> 
> About 40 years ago, give or take, when Jon Postel planned to use the ISO3166 two character code elements as top level domains representing country names, ISO's TC46 secretariat was contacted (as was requested to users of the ISO3166 standard at the time) and he was told that the standard should not be used for DNS, as the future was in X.500. (Postel wasn’t swayed by the argument, and did what we now refer to as permission-less innovation).
> 
> Recently, the ISO was contacted again, and subsequently the WG was again told that the standard wasn’t to be used in this way. It seems that a handful of folks are swayed by the argument and want to use this as guidance for the future of draft-ietf-dnsop-private-tld.
> 
> Early on, Joe Abley proposed a way forward that I held off initially: Recognise that User Assigned 3166 code elements are used in various ways, including private networks, that these elements have not been delegated and are known to be used to anchor private namespaces. Do not recommend, promote or reserve anything, no registries. Document potential future pitfalls for using these codes for private namespaces and empower readers to make their own decisions.
> 
> I now see that with the current status quo, this might a way forward that both sides of the argument might come together on. Essentially, instead of making the pond safe, we’ll have a warning sign that using the pond is at their own risk.
> 
> I hope the WG can come together on this as a way forward. 
> 
> Warmly,
> 
> Roy
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Roy Arends <[email-masked]>
Date: Sun, 1 Aug 2021 22:50:57 +0100

> On 30 Jul 2021, at 23:34, Wes Hardaker <[email-masked]> wrote:
> 
> Roy Arends <[email-masked]> writes:
> 
>> Essentially, instead of making the pond safe, we’ll have a warning
>> sign that using the pond is at their own risk.
> 
> The wording of said warning sign is the critical element, IMHO.
> Certainly my support of the document greatly depends on said wording.

Sure.

> In the end, there should be a goal behind why we want to publish
> something.  If that goal is "know people do this.  don't do this.
> please stop", then that may be a reasonable goal.  If we're just going
> to document history, without recommendations (to stop), then I think it
> may bring more harm than good.

IMHO, we should document that people do this, and that there are risks when people do this, and document what these risks are.

Warmly

Roy

---

From: Michael StJohns <[email-masked]>
Date: Sun, 1 Aug 2021 18:03:51 -0400

Actually, maybe there should be a general document "DNS Squatting 
Considered Harmful"?   I personally don't see any real difference 
between squatting on "onion" vs squatting on "zz" except that we ended 
up with a ex post facto approval of .onion.   And that AIRC was a near 
thing.

So maybe:

1) The IETF and/or ICANN will not allocate any of the 2 letter country 
codes as TLDs unless and until that code is allocated to a country by ISO.
2) Any one squatting on unassigned codes should not expect remediation 
from either the IETF or ICANN if that code is later allocated to a country.
3) As a general matter TLDs of any form unassigned by ICANN should not 
be used for private use.  Please pursue a special assignment via the 
IETF asking for concurrence from ICANN. Other language about how the 
assignment might not occur, might occur, but not for the purpose 
requested, etc.

Mike

---

From: Warren Kumari <[email-masked]>
Date: Sun, 1 Aug 2021 21:00:14 -0400

On Sun, Aug 1, 2021 at 6:04 PM Michael StJohns <[email-masked]>
wrote:

> Considered Harmful"?

I think that we (well, mainly ICANN) already have a large amount that says
things along these lines. See below..

> I personally don't see any real difference

There are already a number of documents which do things along these lines,
including:

Jon's RFC1591 (https://www.ietf.org/rfc/rfc1591.txt) which says:
2) Country Codes
    The IANA is not in the business of deciding what is and what is
    not a country.
    The selection of the ISO 3166 list as a basis for country code
    top-level domain names was made with the knowledge that ISO has a
    procedure for determining which entities should be and should not
    be on that list.

and IANA already says much of this in "Eligible categories of top-level
domains" (https://www.iana.org/help/eligible-tlds)

Also RFC3071 - "Reflections on the DNS, RFC 1591, and Categories of
Domains" says:
These categories are clearly orthogonal to the association between
   the use of the IS 3166-1 registered code list [2] and two-letter
   "country" domain names.  If that relationship is to be maintained
   (and I believe it is desirable), the only inherent requirement is
   that no two-letter TLDs be created except from that list (in order to
   avoid future conflicts).  ICANN should control the allocation and
   delegation of TLDs using these, and other, criteria, but only
   registered 3166-1 two letter codes should be used as two-letter TLDs.

In "ICANN and the International Organization for Standardization (ISO) - A
Common Interest in ISO Standard 3166 --
https://www.icann.org/resources/pages/icann-iso-3166-2012-05-09-en", ICANN
says:
"In 2000, the ICANN Board of Directors recognized the ISO 3166 Maintenance
Agency as the authoritative entity for country code designations and
officially adopted the use of ISO 3166-1 and the 3166-MA exceptional
reserved list as the set of eligible designations for ccTLD assignment
(September 2000)."
and
"ISO 3166 is also used to determine the eligibility for an IDN ccTLD string
under the IDN ccTLD Fast Track process. "

Also:
https://archive.icann.org/en/cctlds/gac-statements-concerning-cctlds-16dec01.htm
has:
Principles for Delegation and Administration of ccTLDs Presented by
Governmental Advisory Committee -
https://archive.icann.org/en/committees/gac/gac-cctldprinciples-23feb00.htm
which says:
3.3 ‘Country code top level domain' or ‘ccTLD' means a domain in the top
level of the global domain name system assigned according to the two-letter
codes in the ISO 3166-1 standard, ‘Codes for the Representation of Names of
Countries and Their Subdivisions.'

In addition, RFC920 - Domain Requirements (
https://datatracker.ietf.org/doc/html/rfc920 ) says:
"The initial top level domain names are:
[...]
Countries
     The English two letter code (alpha-2) identifying a country
      according the the ISO Standard for "Codes for the
      Representation of Names of Countries" [5].

We also have "RFC2240 - A Legal Basis for Domain Name Allocation":
"The TLDs are functionally split up into 'generic' top-level domains
   (gTLDs) and two-letter ISO 3166 country domains for every country in
   which Internet connectivity is provided."

> assignment might not occur, might occur, but not for the purpose

Some existing work along these lines:
RFC8244 - Special-Use Domain Names Problem Statement -
https://datatracker.ietf.org/doc/html/rfc8244

RFC8023 - Report from the Workshop and Prize of Root Causes and Mitigation
of Name Collisions - https://datatracker.ietf.org/doc/html/rfc8023

RFC7034 - A Method for Mitigating Namespace Collisions -
https://datatracker.ietf.org/doc/html/rfc7304

SAC062 SSAC Advisory Concerning the Mitigation of Name Collision Risk -
https://www.icann.org/en/system/files/files/sac-062-en.pdf

SAC066 SSAC Comment Concerning JAS Phase One Report on Mitigating the Risk
of DNS Namespace Collisions -
https://www.icann.org/en/system/files/files/sac-066-en.pdf

Name Collision Resources & Information -
https://www.icann.org/resources/pages/name-collision-2013-12-06-en

Name Collision in the DNS
"A study of the likelihood and potential consequences of collision between new
public gTLD labels and existing private uses of the same strings"
 --
https://www.icann.org/en/system/files/files/name-collision-02aug13-en.pdf

ICANN "Addressing the Consequences of Name Collisions" -
https://www.icann.org/en/announcements/details/addressing-the-consequences-of-name-collisions-5-8-2013-en

"Additional Reserved Top Level Domains -
draft-chapin-additional-reserved-tlds-02
 -
https://datatracker.ietf.org/doc/html/draft-chapin-additional-reserved-tlds-02

ICANN Board Resolution "Addressing the New gTLD Program Applications for
.CORP, .HOME, and .MAIL"
-
https://features.icann.org/addressing-new-gtld-program-applications-corp-home-and-mail

If we write anything, I think that it is important that the WG and authors
are familiar with the existing work related to the topic.

W

> > IMHO, we should document that people do this, and that there are risks
> when people do this, and document what these risks are.
> >
> > Warmly
> >
> > Roy

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Michael StJohns <[email-masked]>
Date: Sun, 1 Aug 2021 22:17:27 -0400

Hi Warren -

I knew of most of these and am impressed you were able to grab all of 
them in summary form so quickly.  But - that's a lot of documents to say 
something so simple as "don't squat".    I agree that, collectively, the 
documents say "don't squat", I wonder if they say it succinctly enough 
given that we keep finding ourselves back in discussions about various 
TLD like items.

I don't have any strong feelings either way, but ask me again in two 
years when we have this discussion yet again.

Mike

On 8/1/2021 9:00 PM, Warren Kumari wrote:
>
>
> On Sun, Aug 1, 2021 at 6:04 PM Michael StJohns <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> I think that we (well, mainly ICANN) already have a large amount that 
> says things along these lines. See below..
>
> There are already a number of documents which do things along these 
> lines, including:
>
> Jon's RFC1591 (https://www.ietf.org/rfc/rfc1591.txt 
> <https://www.ietf.org/rfc/rfc1591.txt>) which says:
> 2) Country Codes
> and IANA already says much of this in "Eligible categories of 
> top-level domains" ()
>
> In "ICANN and the International Organization for Standardization (ISO) 
> - A Common Interest in ISO Standard 3166 -- 
> https://www.icann.org/resources/pages/icann-iso-3166-2012-05-09-en 
> <https://www.icann.org/resources/pages/icann-iso-3166-2012-05-09-en>", 
> ICANN says:
> "In 2000, the ICANN Board of Directors recognized the ISO 3166 
> Maintenance Agency as the authoritative entity for country code 
> designations and officially adopted the use of ISO 3166-1 and the 
> 3166-MA exceptional reserved list as the set of eligible designations 
> for ccTLD assignment (September 2000)."
> and
> "ISO 3166 is also used to determine the eligibility for an IDN ccTLD 
> string under the IDN ccTLD Fast Track process. "
>
> Also: 
> <https://archive.icann.org/en/cctlds/gac-statements-concerning-cctlds-16dec01.htm>
> has:
> <https://archive.icann.org/en/committees/gac/gac-cctldprinciples-23feb00.htm>
> which says:
> 3.3 ‘Country code top level domain' or ‘ccTLD' means a domain in the 
> top level of the global domain name system assigned according to the 
> two-letter codes in the ISO 3166-1 standard, ‘Codes for the 
> Representation of Names of Countries and Their Subdivisions.'
>
> https://datatracker.ietf.org/doc/html/rfc920 
> <https://datatracker.ietf.org/doc/html/rfc920> ) says:
> Some existing workalong these lines:
> <https://datatracker.ietf.org/doc/html/rfc8244>
>
> RFC8023 - Report from the Workshop and Prize of Root Causes and 
> Mitigation of Name Collisions - 
> https://datatracker.ietf.org/doc/html/rfc8023 
> <https://datatracker.ietf.org/doc/html/rfc8023>
>
> <https://datatracker.ietf.org/doc/html/rfc7304>
>
> SAC062 SSAC Advisory Concerning the Mitigation of Name Collision Risk 
> - https://www.icann.org/en/system/files/files/sac-062-en.pdf 
> <https://www.icann.org/en/system/files/files/sac-062-en.pdf>
>
> SAC066 SSAC Comment Concerning JAS Phase One Report on Mitigating the 
> Risk of DNS Namespace Collisions - 
> <https://www.icann.org/en/system/files/files/sac-066-en.pdf>
>
> <https://www.icann.org/resources/pages/name-collision-2013-12-06-en>
>
> "A study of the likelihood and potential consequences of collision 
> betweennew public gTLD labels and existing private uses of the same 
> strings"
>  -- 
> <https://www.icann.org/en/system/files/files/name-collision-02aug13-en.pdf>
>
> <https://www.icann.org/en/announcements/details/addressing-the-consequences-of-name-collisions-5-8-2013-en>
>
> <https://datatracker.ietf.org/doc/html/draft-chapin-additional-reserved-tlds-02>
>
> ICANN Board Resolution "Addressing the New gTLD Program Applications 
> for .CORP, .HOME, and .MAIL"
> - 
> <https://features.icann.org/addressing-new-gtld-program-applications-corp-home-and-mail>
>
>
> If we write anything, I think that it is important that the WG and 
> authors are familiar with the existing work related to the topic.
>
> W
>
>