On Sun, Aug 1, 2021 at 6:04 PM Michael StJohns <[email protected]> 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 <[email protected]> wrote: > >> > >> Roy Arends <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ > DNSOP mailing list > [email protected] > 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
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
