Re: [DNSOP] on private use TLDS

Ted Lemon <mellon@fugue.com> Thu, 28 November 2019 12:15 UTC

Return-Path: <mellon@fugue.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 844CA120842 for <dnsop@ietfa.amsl.com>; Thu, 28 Nov 2019 04:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=fugue-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 LTZcHqWaFRQ1 for <dnsop@ietfa.amsl.com>; Thu, 28 Nov 2019 04:15:26 -0800 (PST)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 31190120841 for <dnsop@ietf.org>; Thu, 28 Nov 2019 04:15:26 -0800 (PST)
Received: by mail-qk1-x730.google.com with SMTP id v23so14716147qkg.2 for <dnsop@ietf.org>; Thu, 28 Nov 2019 04:15:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=VpZ7o1gKZWrEPDzTfE3Nin1N0d74w0COfbiZPUE/qUA=; b=dW3RmwWxl1mRt2yJLoE9Y15716YqeRT7FZZz2Ag7fnryFTjoZpLUDWSnyWs4U0RmEv gxcpZg1Ih1BuhpJVnYHafQUrNnlbNFfTsT64C5CJq/BNtqhZhIwnvQDXjmmb1ljo9lEt VuxEl3uN48R+rgCoyUrAOWSEXwwqKwMzMjE7/8anpOjKaMVqPuHQv6qOmmi5WFJbwsZe TI6uS2dw6qdzn1M6oGrfB1Ic7MOBS8ayZp4iv2YyJ1KgYJREtgXZ88qZApqy4A9yKVyG ojEHkaWRzNSBdZEDAdfFiSVmcC29kTgPbumw4Vckq/qnHgvhJlaNbZl81+36PGnl4UBF Zh+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=VpZ7o1gKZWrEPDzTfE3Nin1N0d74w0COfbiZPUE/qUA=; b=DWBHpwbx+2zhf9hvk29BCudYa3ZhAjkP3fpHmx8aeh6s42ojHRczSGUq/jjZ0h/wwQ P5PteySCcrhTrLabb5/3i5I70zgcRCuu7uC+x6cutJPymXnuPqx7q2U1EhTqEAl3Do6X qdUKXYhViljL3XpUQPel+j34iD/bLX4Ny2fpA/Sr9wBViN+usfRp33pVrKWQHTi4mwgr QB92/5pdaifzX19Xn6JKFi/J+nPVAsZBR/Sai8XS0IzorUs6A/39mgpmcvgAOR7Or8tR hFtl2WJmw5wxJiJRS214N8wZ60uY5v+1OmEMFvXyzn8MOgEy5nBIRjcR8T9tqepfnTbh rSdQ==
X-Gm-Message-State: APjAAAVR8Luao5DXZM1aD6m+e7gEPeUb2+94ne6Rb/1BAFs/SABCVrBR t9SuVDh5lMBHSHJiqCfYh7d/I1YYVywyoA==
X-Google-Smtp-Source: APXvYqymYQBoUx2AFKyHGqWbENxEK1vSacrfSfw4taMcIH4YXSQs6pTTV7EyctmWJpSiGE9NhC+cMw==
X-Received: by 2002:a37:7b83:: with SMTP id w125mr9265204qkc.343.1574943324882; Thu, 28 Nov 2019 04:15:24 -0800 (PST)
Received: from [192.168.4.64] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id t15sm2036921qkg.49.2019.11.28.04.15.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Nov 2019 04:15:24 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 28 Nov 2019 07:15:23 -0500
Message-Id: <E536A699-37A9-41D8-8ED1-10E116E18E4C@fugue.com>
References: <71ad677a-8c88-8916-fe02-7d0d8ae930b9@dougbarton.us>
Cc: dnsop@ietf.org
In-Reply-To: <71ad677a-8c88-8916-fe02-7d0d8ae930b9@dougbarton.us>
To: Doug Barton <dougb@dougbarton.us>
X-Mailer: iPhone Mail (17E180a)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0kdU_ES3lr26XBsgsjtlNYGRRQw>
Subject: Re: [DNSOP] on private use TLDS
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: Thu, 28 Nov 2019 12:15:29 -0000

So let me get this straight: you want us to stay out of ISO’s sandbox by jumping right in to ICANN’s? ICANN has not promised never to delegate those domains, whereas ISO effectively has, so your reasoning doesn’t make sense. 

> On Nov 27, 2019, at 23:39, Doug Barton <dougb@dougbarton.us> wrote:
> 
> On 11/26/19 9:16 AM, Matthew Pounsett wrote:
>> On Tue, 26 Nov 2019 at 05:19, Roy Arends <roy@dnss.ec <mailto:roy@dnss.ec>> wrote:
>>    “ZZ” was used in my presentation as an example. Since this
>>    bikeshedding is siphoning attention from the important part of the
>>    discussion, I’ll try to re-focus on the question here:
>>    "Is it safe to use ISO3166-1 Alpha-2 code elements from the User
>>    Assigned range as top level domains for my own private use?"
>> Thanks for the context, Roy.  Speaking as someone who was not at the IETF meeting this week, I found the earlier thread confusing.  But, it looks like the assumed context of bringing up "what can we use this for" as "can we assign this string in an RFC?" was correct.
>> It seems like reassignment of anything in the User Assigned range is unlikely, however that is the purview of the iSO 3166 maintenance agency, and not the IETF.  However unlikely it is, we cannot be absolutely certain they will never reassign those, and so we should not include them in any standard (note the lower-case) published by the IETF.  Even if the IETF is just cut & pasting their current advice, I think it's unwise.
>> I'm also persuaded by Bill's argument that the IETF has already stated that ISO 3166 has control over that bit of the namespace, and trying to take back part of it is confusing, bad form, and risky.
>> Even though they're not specifically proposed, only mentioned in passing, I'd also like to point out that the referenced potential uses of things like XH instead of home.arpa. is even more risky, because that fixes that string for a specific use, even if it's private.  Using XH as an example, if that had been chosen it would run the risk of colliding with some legitimate use of XH already being used by a User... if that user then also needed to interoperate with Homenet technologies they'd be hosed.
>> I think, instead of an RFC, what you really want is a Best Current Practices document, outside of the IETF, that is simply a redirect to the current ISO 3166 document.  Instead of DNSOP, I'd suggest you have a chat with one or more  of the BCOP efforts at the NOGs.
> 
> I agree with Matt, Bill Woodcock, Steve Crocker, and others that have expressed that we should stay out of ISO's sandbox. Whatever the rules are today, they can change, and poaching their stuff for our purposes is bad form (and yes, I feel that poaching is what is being proposed, in spite of the arguments to the contrary).
> 
> ICANN has already said that it's not going to ever delegate CORP, HOME, or MAIL. (https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf Section 3.2) IMO it would be useful for the IETF, with ICANN's cooperation, to codify that (if it hasn't been done already). I also think INTERNAL as a private-use TLD is a good idea, and should be included in the same doc. It's also useful to mention the distinction between using something temporarily for testing, and building infrastructure around it. If someone wants to put together a document like that I would be happy to offer support, review, and/or contributions if so desired.
> 
> So what's the harm? Aside from the PR issues related to poaching ISO 3166 stuff, I have personally been involved a few times in unwinding the giant mess created when clients decided that they were going to use a string as an internal TLD, and then subsequently it got delegated publicly. This creates serious problems, is difficult to debug, and expensive to fix. The advice we've given folks for decades is, "Don't take it upon yourself to grab something that doesn't belong to you and build your network on it." In my view, that's what is being recommended here; and having seen the damage it causes first hand, I cannot support the proposal.
> 
> Doug
> 
> -- 
> Since I haven't been involved in the group for a while here is a mini-resume for those that don't know me, offered with no small amount of embarrassment:
> DNS and domain name work for 25 years, 20+ of doing it for a living
> Formerly a regular IETF participant
> Former GM of the IANA
> Former consultant in the DNS/DHCP/IPAM and domain name spaces
> Currently managing the domain name portfolio for a Fortune 100 corporation
> 
> That said, all views are my own, and are worth exactly what you paid for them.  :)
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop