Re: [DNSOP] new version submitted for draft-arends-private-use-tld

Patrick Mevzek <mevzek@uniregistry.com> Thu, 07 May 2020 18:40 UTC

Return-Path: <mevzek@uniregistry.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 AB7173A087E for <dnsop@ietfa.amsl.com>; Thu, 7 May 2020 11:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_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=uniregistry.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 I5HWtDwQNOkm for <dnsop@ietfa.amsl.com>; Thu, 7 May 2020 11:40:46 -0700 (PDT)
Received: from a-mx.uniregistry.com (a-mx.uniregistry.com [64.96.177.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8669E3A0877 for <dnsop@ietf.org>; Thu, 7 May 2020 11:40:45 -0700 (PDT)
Abuse: Forward to abuse@uniregistry.com with full headers
X-Virus-Scanned: Content filter at a-mx.uniregistry.com
Powered-By: https://www.uniregistry.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniregistry.com; s=bravo; t=1588876844; bh=i7JuztzkDEGQDXhRCGgammlTtGWnpxBV3A51J3r3jOQ=; h=Subject:To:References:From:Date:In-Reply-To; b=ICG+4FsS+KkDIZ+IUpNTze5qw9WOCn22KwI/mWuPGuRhkoSKyzcBDrh8Y0QuaiKJL EIo3h1Giterz3NfK3p9hPib+46aF+ffZYiw0g6RkdDJ7O4vkJVfJtrKPokFzArOloi gjj58B0WXjF3YzmlIkPO708qoXhX1b6CD7ld9mWek0peib+lfxnJ17X3DVRs5jmNca jGEuvRYRJf2NiHI7Lp0SmoGopVhNRc5AEcxjpA6xJUz7VDCq+nw7mYxbvtzPauDuAC MxJjX7+Jk8N8ghMAbZTThePPPlcbSMDds7oh0n1pCsuqCWv62AUdO37gdWFceCfV1u y/7+1ZkknD/IA==
Received: from EPPguy.local (b01.uniregistrar.net [52.204.70.64]) (authenticated bits=0) by a-mx.uniregistry.com (8.15.2/8.15.2/Debian-8) with ESMTPSA id 047IehxP037971 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 7 May 2020 18:40:44 GMT
To: dnsop@ietf.org
References: <91A33B60-7B70-4231-8ED8-662CFBB70445@icann.org>
From: Patrick Mevzek <mevzek@uniregistry.com>
Organization: Uniregistry
Message-ID: <7df431dd-1f07-3817-dd40-27985a3d03fc@uniregistry.com>
Date: Thu, 07 May 2020 13:40:42 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <91A33B60-7B70-4231-8ED8-662CFBB70445@icann.org>
Content-Type: text/plain; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/D-eKjeNPEUZ1Jz_aIG89fyb_hCI>
Subject: Re: [DNSOP] new version submitted for 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: Thu, 07 May 2020 18:40:48 -0000

On 02/05/2020 09:09, Roy Arends wrote:
> Hi,
> 
> Ed and I just submitted a new version of our private-use TLD draft. 
> 
> https://www.ietf.org/id/draft-arends-private-use-tld-01.txt

While I do not have hard facts but just a gut feeling, I would feel
safer if "xn" is excluded from the possible list of private labels to be
used in the DNS, as it is used for prefix of IDNs.

Some, probably buggy, software could match on "xn" instead of "xn--" as
prefix to search for IDNs, and hence having "example.xn" could lead to
problems.

> This draft has substantial more information than the first draft. It explains that a private-use namespace does not exist, why it is needed, and how a namespace aligned with the user-assigned alpha-2 code elements in the ISO-3166-1 standard can be used as private-use namespace.
> 
> It contains plenty of examples of how user-assigned code elements are used in the field, including other ISO standards, the UN, UNICODE, CAB/forum, and the IETF itself.
> 
> This new version came about after fruitful discussions with peers inside and outside the IETF. Most discussions were productive. This has lead to the removal of the advice/example to use ZZ, as it was distracting from the point of the draft: these two-letter top level domains are available for private-use. 

Thanks for the new draft version, the new content is useful indeed.

-- 
Patrick Mevzek