Re: [DNSOP] I-D Action: draft-ietf-dnsop-private-use-tld-00.txt

Andrew McConachie <andrew@depht.com> Wed, 14 October 2020 09:50 UTC

Return-Path: <andrew@depht.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 F16083A143A for <dnsop@ietfa.amsl.com>; Wed, 14 Oct 2020 02:50:29 -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, 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=depht-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 ai2jDEMKdXt0 for <dnsop@ietfa.amsl.com>; Wed, 14 Oct 2020 02:50:27 -0700 (PDT)
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 C33853A1438 for <dnsop@ietf.org>; Wed, 14 Oct 2020 02:50:27 -0700 (PDT)
Received: by mail-il1-x12f.google.com with SMTP id j13so4395485ilc.4 for <dnsop@ietf.org>; Wed, 14 Oct 2020 02:50:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=depht-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ycXRj7J7IaxKHblodkmLUkw8bLPMQD2l3nCZLaVE9cs=; b=A7CcazMrwEkDxYZXvA4eb5cAkqgkNN6CLYX1+ObGISrUabk7o3SPvOY6jtzCGHAyJH Q6EJpJzB7xiLd1P9+az7CRMaSBDXif9HQR1SN2NONhFV7WHOON2krGSqVnnCD7c9MTiJ 09+T7U/XmJ0SR4jAI1pDol6Q/KSIWTzm2VlPKR2mqZdXLPjadMiJvGKuj7qwDifUU3E/ 2r81kXQAAO+n+8vkbWX7dWYltoW3BJ1VexDGIGSqicMftzFhNX7yVOlmPU3N1/KxUq3u V0TEYrXD8/0n/HhT2SbLUNHhKFKEm6r67gO/aNwCvwbWWshG3mwNXa9ItS3cRzM9AvCs jfIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ycXRj7J7IaxKHblodkmLUkw8bLPMQD2l3nCZLaVE9cs=; b=pc2KjntV/qCZ4e8VHyypnKok5HfqJOf3/eN/vZXZ5dvYRFYU01P28yRMV1odknBJFN lCWC8J/HyldUonnc0LKZelyzzgQ5eRrvrQDzkBGvqWiklC9dEBbQ8D8KE2P2f8ome3tC P870FdQH0Lx69KulCQru3x9Tc0q/JQWhmxOfeqOgAiybW6SqBs7zibVYHQqE+/9KkSh3 dPM1DZc5KjweaerwBxbuAAmCgdoObpLJykyB81ecMaUnPX2lYo6fCv5F6v0seXDzAJIo vcvaGEYoeoxHiSZy1Ko/oPFCVAkOUMpgpbZ3c1m61DZ4Nhq0xy6Y3R+SeOK/CFJiGUHU 9EAA==
X-Gm-Message-State: AOAM533836WdHvWYmAXEkd2zM3mDGl5PDjYzNs9XksQvQ6v2woUlHLSj kYOqsvgvbpW20SW7BuHGficisurESV9/fQ==
X-Google-Smtp-Source: ABdhPJzFrOTRFm7bdHBp5BqVg6/r1T1eJHGfCzKt48rHMnhOubLRdYWPkatpty8nH1xjuc9Ptd3rFg==
X-Received: by 2002:a92:b742:: with SMTP id c2mr568379ilm.170.1602669026739; Wed, 14 Oct 2020 02:50:26 -0700 (PDT)
Received: from [10.47.61.39] ([2a02:a212:9285:29f0:618d:18dc:4f8a:622e]) by smtp.gmail.com with ESMTPSA id c8sm2416805ils.50.2020.10.14.02.50.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 02:50:26 -0700 (PDT)
From: Andrew McConachie <andrew@depht.com>
To: Roy Arends <roy@dnss.ec>
Cc: dnsop <dnsop@ietf.org>
Date: Wed, 14 Oct 2020 11:50:23 +0200
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <88A7A3F1-7509-4A5A-B1A4-7705FA563B92@depht.com>
In-Reply-To: <1D3FDBF5-75D5-4F39-803C-346FD1E5D906@dnss.ec>
References: <160215087457.31977.4784904737314236890@ietfa.amsl.com> <7E3AFDBD-4748-4C50-9950-5C8445C96B24@depht.com> <1D3FDBF5-75D5-4F39-803C-346FD1E5D906@dnss.ec>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bbCk32fvcEBLy3kSsjhbaFIbwPQ>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-private-use-tld-00.txt
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: Wed, 14 Oct 2020 09:50:30 -0000


On 9 Oct 2020, at 11:58, Roy Arends wrote:

> > On 9 Oct 2020, at 10:38, Andrew McConachie <andrew@depht.com> wrote:
>> Hi Roy and Joe,
>>
>> It’s not clear to me whether the document is advising to only use 
>> this facility when a sub-domain of a public domain name is 
>> unavailable, or to optionally use this facility based on the user’s 
>> preference. What I would like the document to say is that only when a 
>> sub-domain of a public domain is unavailable should this facility be 
>> considered. The reader should get the impression that they should try 
>> really really hard to not use the ISO-3166 reserved string if they 
>> can.
>>
>> This is marked as a BCP and so I would expect to see this advice 
>> prominent in the document. Since, IMO at least, that is the best 
>> current practice. Only when a user cannot use a sub-domain of a 
>> domain they control should they even consider using the ISO-3166 
>> reserved string. Ideally there could be a new section discussing this 
>> advice between the current sections 1 and 2. That way the reader will 
>> encounter the best practice before encountering the work around.
>
> Thanks for your comment Andrew,
>
> The next version will contain more text directed to this.
>
> IMHO, the mere availability of a subdomain (of an existing domain) 
> should not automatically preclude the use of a private top-level 
> domain. That is, I disagree with the notion that “they should try 
> really really hard to not use the ISO-3166 reserved string”.
>
> Note that a domain may not always be tied to the same legal entity. 
> When software or devices are shipped with a default configuration that 
> is meant to work only locally (there are a few scenarios that include 
> home use or corporate use), using a public domain is problematic. 
> Queries will leak to the authoritative servers of that public domain, 
> long after the public domain has changed hands.
>
> It is also not desirable from a legal and even operational standpoint 
> if software that is shipped with a default public domain will be 
> “phoning home” all the time.
>
> There are likely to be many different use cases, some where a public 
> domain is useful, some where a private-use domain is useful.

Hi Roy,

Thanks for the response. I think we’re basically in agreement here.

If the mere availability of a sub-domain (of an existing domain) 
precluded ever using this ISO-3166 reserved string then there would 
never be a valid use case for the ISO-3166 string. If only because one 
can always register a new domain and delegate a sub-domain. We can 
quibble over what “try really really hard” means, but it would not 
improve the document to enumerate every possible use case and proscribe 
which route the user should take for each one.

I look forward to your next version with more text on this topic.

Thanks,
Andrew