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

Andrew McConachie <andrew@depht.com> Fri, 09 October 2020 09:38 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 D76B63A0E17 for <dnsop@ietfa.amsl.com>; Fri, 9 Oct 2020 02:38:09 -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=unavailable 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 HjeqCQUYsxjo for <dnsop@ietfa.amsl.com>; Fri, 9 Oct 2020 02:38:08 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450: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 1E6073A0E18 for <dnsop@ietf.org>; Fri, 9 Oct 2020 02:38:08 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id o18so8699387edq.4 for <dnsop@ietf.org>; Fri, 09 Oct 2020 02:38:07 -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=yz3Czp5w91Iyat5VGpX/4nHwlAPqSx5MLLi34ZrnZHQ=; b=TqGz3L7/iIv+5JkX8mmW/2frJUtmP4uSjb/C25i54l6uq/NYXSvYxHFRbjYs1+3OhU O3eaHzNj0tJbF4JBT2OL65vNm4L9ku38XsnF8m71al1nTAtMNeabW5vF0UnZFCkbVBum zjkUSwxu/93hryt11bnfLhYD4MKEJ/yEgUymd+tCRgUQmktECVYeLK9XyoqtOKkcx5a2 Vl/H+jtnTrk+gik36nrulYNteKbuxzKHLjxsq1BwLL24Ky00bdRWfsBCb2hCj7vLMAKs F3WfBUmg1UFa+NcTwWv9YJLLj/3jpwd4NJN/2WbWgwNtGZgGfN2q9v5LnI27GLfX3THM hOdw==
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=yz3Czp5w91Iyat5VGpX/4nHwlAPqSx5MLLi34ZrnZHQ=; b=FVbE26QS6CbBeIurU2tO0vht5ZTk6emDfypPoH2cw/xlOGlitLTTtKlgmrjBy6dEhR 9fuAWVWFbalLa9tC6OVgAZGCPOHZknq/ubURK9C2mtHDmzxpGPwHQF73JP9eCevMJs9k QjBh22D3r27OgG8RoYB9dcjnw2rQaQrkdRIGfA23Lup3tzpJtD0fXPudeTno8jP2VpIr j/5ZwYPpZSSpyCs1TMxpWyJnB9Jhpu12DlHeWz8QClsAvIidrAeQDynFKQd8x9qkKdNw AvRsNBvjFOYfXzrP5vMpcLb5MfCioSVHmQFPZj5SQf6aAFoUlU5Pr9pVsWjiung7xm3b PAag==
X-Gm-Message-State: AOAM530mN5Szavn6Ak82ez6LVuwls5IExsqJsDvJckTkMjzmvMQy+t8O 5qFjXMVrO0U7S4MqUhoIcKv8H0W1aH02yw==
X-Google-Smtp-Source: ABdhPJx+VQH2NC0T6a5SGtZQ8ZkBLkxCQp91r3VjNQerrAvSCW0u2q+ZJAWyGMsei/unc8ZKnvmu/A==
X-Received: by 2002:a05:6402:1012:: with SMTP id c18mr13327215edu.77.1602236286205; Fri, 09 Oct 2020 02:38:06 -0700 (PDT)
Received: from [192.168.1.155] ([2a02:a212:9285:29f0:d487:2d84:6e4b:9ed5]) by smtp.gmail.com with ESMTPSA id r24sm5785347edm.95.2020.10.09.02.38.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 02:38:05 -0700 (PDT)
From: Andrew McConachie <andrew@depht.com>
To: dnsop@ietf.org
Cc: i-d-announce@ietf.org
Date: Fri, 09 Oct 2020 11:38:04 +0200
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <7E3AFDBD-4748-4C50-9950-5C8445C96B24@depht.com>
In-Reply-To: <160215087457.31977.4784904737314236890@ietfa.amsl.com>
References: <160215087457.31977.4784904737314236890@ietfa.amsl.com>
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/nUmyU5TiIK3wqtfjGRZvPf1u0BU>
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: Fri, 09 Oct 2020 09:38:10 -0000


On 8 Oct 2020, at 11:54, internet-drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of 
> the IETF.
>
>         Title           : Top-level Domains for Private Internets
>         Authors         : Roy Arends
>                           Joe Abley
> 	Filename        : draft-ietf-dnsop-private-use-tld-00.txt
> 	Pages           : 10
> 	Date            : 2020-10-08
>
> Abstract:
>    There are no defined private-use namespaces in the Domain Name 
> System
>    (DNS).  For a domain name to be considered private-use, it needs to
>    be future-proof in that its top-level domain will never be 
> delegated
>    from the root zone.  The lack of a private-use namespace has led to
>    locally configured namespaces with a top-level domain that is not
>    future proof.
>
>    The DNS needs an equivalent of the facilities provided by BCP 5 
> (RFC
>    1918) for private internets, i.e. a range of short, semantic-free
>    top-level domains that can be used in private internets without the
>    risk of being globally delegated from the root zone.
>
>    The ISO 3166 standard is used for the definition of eligible
>    designations for country-code top-level Domains.  This standard is
>    maintained by the ISO 3166 Maintenance Agency.  The ISO 3166 
> standard
>    includes a set of user-assigned code elements that can be used by
>    those who need to add further names to their local applications.
>
>    Because of the rules set out by ISO in their standard, it is
>    extremely unlikely that these user-assigned code elements would 
> ever
>    conflict with delegations in the root zone under current practices.
>    This document explicitly reserves these code elements to be safely
>    used as top-level domains for private DNS resolution.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-private-use-tld/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-private-use-tld-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-private-use-tld-00
>
>
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
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,
Andrew