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

[Warren Kumari <[e-mail]>]

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

> Actually, maybe there should be a general document "DNS Squatting
> 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
> 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.
>


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



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

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




>
> Mike
>
>
>
> On 8/1/2021 5:50 PM, Roy Arends wrote:
> >> On 30 Jul 2021, at 23:34, Wes Hardaker <[e-mail]> wrote:
> >>
> >> Roy Arends <[e-mail]> 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
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnsop
>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>


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