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

Michael StJohns <msj@nthpermutation.com> Mon, 02 August 2021 02:17 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F5E3A0B67 for <dnsop@ietfa.amsl.com>; Sun, 1 Aug 2021 19:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOqu3kT8-6Rt for <dnsop@ietfa.amsl.com>; Sun, 1 Aug 2021 19:17:32 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84EF3A0B60 for <dnsop@ietf.org>; Sun, 1 Aug 2021 19:17:32 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id k7so15304950qki.11 for <dnsop@ietf.org>; Sun, 01 Aug 2021 19:17:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=T7XsBlaGu9yGXRrYvd0cY5/hErub90GRN1z91wh72NA=; b=UuS/TzaLku9qsbML37MzerYd3eHDfG4R2cuMyydrajAXevlCPkGibGVVS8+ovGdoly j1JNrOg57dxYDpTkUmBmBt4pK4SLVH9m0wQreiI78qJPgm1I0FA7FzVBDiwBazWoRYXh qULJucYyqyXn5hki0Opxyu/qWl/hRZzJucAQCH2GOUlTgVYQp2VgpLXYXg8nNqYYF+NT OmQ/rocABCJG2Uv/eTPhvnu2VVf8p2yTrsg4oXv8h+DL54xEEO/lA2Ez7kU0FNsPCPso ArcJz3Pt48+kWdXcVJOMaJnqAczzMYdeB0+iXFJzwVt/77SF2dP8lLaSBdBuEJ6HvF7d 2l3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=T7XsBlaGu9yGXRrYvd0cY5/hErub90GRN1z91wh72NA=; b=rVxx4RFuR2Elgw8CgXLJ2xEmc5vSNE6dAmIQ+4AD2cgo5+j8d/ioqQDVwQEvNY7Ikr nenG8PAEAvCMcxeSX/jz0t+phs8ZHZCdc9lLx9W2xPz3alxGAwZMGeBm5zS13DZEz/ir N+1ko85DxsXW/aV6Qhehdl9oEJmr0fAUHXdwG9lqalagBaqkS7wF1AWYsTc04eGv+/ET TBy+/IZkCguYBB7A2OCIL8WJB51MaXZsGLgZb4h4crbNX0aOhM1K+GJDd+R4UtiNE1RZ WVPqmBjvzUaquY+Bv7a4w2E/Rwi/wW2kcns7h8CCCutOmSe2WjMv8IxkF+4sgDO9c/q+ I/kA==
X-Gm-Message-State: AOAM532M7ysnEvflu79oPl8cCSqzbd9G9WNzTa9Ci1apDG7/CHA8lqbd fD8tIRGp6YtAfXfUoBfHyVMPksQKfQH7BRGO
X-Google-Smtp-Source: ABdhPJzHLNaN6WNPsRqsJkCCWkdjBGEo9+4egBfenW3Ceca0O3py91a53PbGRRsDUgZGxW3otvJLaQ==
X-Received: by 2002:a05:620a:120e:: with SMTP id u14mr13301336qkj.309.1627870650204; Sun, 01 Aug 2021 19:17:30 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id l4sm5213166qkd.77.2021.08.01.19.17.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Aug 2021 19:17:29 -0700 (PDT)
To: Warren Kumari <warren@kumari.net>
Cc: dnsop <dnsop@ietf.org>
References: <E5E151E6-0BC0-44FE-BF7C-6B2ED207894F@dnss.ec> <ybleebfjurt.fsf@w7.hardakers.net> <F32FF440-D3C5-40B2-AAF0-F7671CE6DF52@dnss.ec> <5423bc8b-f99e-bcd3-834d-ed3e8cc53682@nthpermutation.com> <CAHw9_iLzEGPjwJHN0okK+BttT2og0oQVmeq63jzPXCS09ynAxw@mail.gmail.com>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <31ffa983-9c71-77f4-ba8f-a2729b1d6348@nthpermutation.com>
Date: Sun, 1 Aug 2021 22:17:27 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <CAHw9_iLzEGPjwJHN0okK+BttT2og0oQVmeq63jzPXCS09ynAxw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------5759D5428AE3ADA9F3C93D21"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LQ47VbX8SVkRhJ3glFC2Bnhyiko>
Subject: Re: [DNSOP] DNSOPMoving forward on draft-ietf-dnsop-private-tld
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Aug 2021 02:17:38 -0000

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 <msj@nthpermutation.com 
> <mailto:msj@nthpermutation.com>> 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 
> <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" ()
>
> 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 
> <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 
> <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 
> <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 
> <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 workalong these lines:
> RFC8244 - Special-Use Domain Names Problem Statement - 
> https://datatracker.ietf.org/doc/html/rfc8244 
> <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>
>
> RFC7034 - A Method for Mitigating Namespace Collisions - 
> https://datatracker.ietf.org/doc/html/rfc7304 
> <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/en/system/files/files/sac-066-en.pdf>
>
> Name Collision Resources & Information - 
> https://www.icann.org/resources/pages/name-collision-2013-12-06-en 
> <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 
> 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/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 
> <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 
> <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 
> <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
>
>