Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

Joe Abley <jabley@hopcount.ca> Tue, 16 June 2020 00:58 UTC

Return-Path: <jabley@hopcount.ca>
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 681F43A0F31 for <dnsop@ietfa.amsl.com>; Mon, 15 Jun 2020 17:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=hopcount.ca
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 JwUFN-TavaxM for <dnsop@ietfa.amsl.com>; Mon, 15 Jun 2020 17:58:24 -0700 (PDT)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 3EBF13A0F2F for <dnsop@ietf.org>; Mon, 15 Jun 2020 17:58:24 -0700 (PDT)
Received: by mail-pg1-x533.google.com with SMTP id h10so4697014pgq.10 for <dnsop@ietf.org>; Mon, 15 Jun 2020 17:58:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=eDS3ZcsFhOizsCdRLfUhTRI2Mehw8YB/VSZwn2ULFA8=; b=bfMbKYy4nK5JVzAnmRC3WJQuUa1vOAusKpdmYUUmVHEgDJ7s1oGn2nhNbSJazZ3QD7 mLMAphvTKv4qyGKZcm8efkO6wIyKQR5uSOCPteNq9ES9pZ0iXffH9PqqbIb83pyxESsl 6L0I8q3j6K6mQnYICTw0xZHT4wFWmPhUyJS/Q=
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=eDS3ZcsFhOizsCdRLfUhTRI2Mehw8YB/VSZwn2ULFA8=; b=X/lLj3vN+X/zADn3HNedARpA3ACv28DmAIHHOzjVLKJ/S+6HeINjtKjI+J9SUw7reT qvaAV+5k2p7uZyOVVzJTrEq5caYTPfXnyJw2k4Cw7rqfSW2Pdw1ytQdDglBakgIAwiMo 38bA2xAPMLSqClTVigrI/oq+C2t0aFD1FmfKfLlnkKiGFRWzW1xDx8kQk4v/FgVDfbUt YqzhXSjkKcbW9UZh31acXiGd/fj7EHwGH0uSuZQU744+mr9wvlqJVQUSCI41oFPtp6dl JZlsFk1Xzd1FW5kv1tquv3GPwP+uO+ZOlfS2TGqvhDdOxURYtdAleuwpSMfasAQ4lfgI DdKg==
X-Gm-Message-State: AOAM531vonCslA8yhk8pycFQC2JuMZoOYp1Zk8yN3jYHA3sRpjuBzcGq V7UCmRLT89u+FL6uFEtluZnzhA==
X-Google-Smtp-Source: ABdhPJwQjTGTpBs5IigijNzQwKSpOZe0OrvGBEpegvUFvjnNJRfktqy1Wzf6VJi0Jr11RARa6qAgrw==
X-Received: by 2002:a62:380a:: with SMTP id f10mr267806pfa.85.1592269103490; Mon, 15 Jun 2020 17:58:23 -0700 (PDT)
Received: from [172.19.248.43] ([205.220.128.194]) by smtp.gmail.com with ESMTPSA id 130sm14594246pfw.176.2020.06.15.17.58.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2020 17:58:22 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
Date: Mon, 15 Jun 2020 20:58:13 -0400
Message-Id: <804FF334-349C-427F-84CF-C1D91CCB4314@hopcount.ca>
References: <alpine.DEB.2.20.2006152320360.28941@grey.csi.cam.ac.uk>
Cc: Paul Vixie <paul@redbarn.org>, Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>, John Levine <johnl@taugh.com>, Brian Dickson <brian.peter.dickson@gmail.com>
In-Reply-To: <alpine.DEB.2.20.2006152320360.28941@grey.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
X-Mailer: iPad Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/x25YQm2QBTREwepD76e6o67CiNc>
Subject: Re: [DNSOP] Call for Adoption: draft-arends-private-use-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: Tue, 16 Jun 2020 00:58:25 -0000

On Jun 15, 2020, at 18:46, Tony Finch <dot@dotat.at> wrote:

> The intro to this draft talks about things like x- which has been
> deprecated since RFC 6648. It mentions some situationw where .test or
> ..invalid would seem to be the right things to use, but it doesn't say why
> not. It lists a bunch of TLDs that are being squatted by devices that
> ought to move to home.arpa instead, but doesn't say why we have given up
> on that idea after only a couple of years, or why we should expect them to
> move to ISO 3166 reserved codes when they haven't moved to home.arpa.

I don't remember any text in the document that talked about people changing what they are doing. I thought the point of it was to provide some guidance for people who have decided (for whatever reason) that they have a use for a private namespace anchored by a TLD but who haven't decided what to use yet.

Personally, I think the right advice for most people is that if you must use private namespace you should anchor it at a domain name in the global namespace that you control, so that your namespace is both private and unique. Someone should write that document. I'll help, if someone is interested.

But draft-arends-pitchfork-pitchfork-burn-the-witch doesn't provide that kind of general advice; it provides specific advice for the case where people have decided that a TLD is definitely needed by pointing out that the 3166 people have already reserved a label for them to use and that current ICANN policy is that such label will never clash with a real (non-private) TLD.

Note that without this document, the above will still be true. The two-character codes mentioned in this document will still be available for use for whatever purpose people can dream up, and will still not be delegated by ICANN. This document just writes it down so that people don't have to do the consderable homework to reach that conclusion themselves.

I continue to think that using policy that already exists to solve a problem that apparently some poeple have without asking anybody to change anything at all is a thing of great and enduring beauty, and I'm quite surprised that so many people are trying to hard to turn it into something more difficult to agree with.

Perhaps we've all been deprived of mic lines for long enough that we have some pent-up need to make things complicated.


Joe