Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review

"Schanzenbach, Martin" <mschanzenbach@posteo.de> Mon, 22 August 2022 10:47 UTC

Return-Path: <mschanzenbach@posteo.de>
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 B768BC14CE2A for <dnsop@ietfa.amsl.com>; Mon, 22 Aug 2022 03:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=posteo.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvUIEYH_v636 for <dnsop@ietfa.amsl.com>; Mon, 22 Aug 2022 03:47:44 -0700 (PDT)
Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A8DC14F74C for <dnsop@ietf.org>; Mon, 22 Aug 2022 03:47:43 -0700 (PDT)
Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id B343F24002C for <dnsop@ietf.org>; Mon, 22 Aug 2022 12:47:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1661165260; bh=2hu4VjjsodR6mAI8jiRj195cc2jAt7GoYNwB1mS/Mr8=; h=Subject:From:Date:Cc:To:From; b=H1oce+SpErkiCRZv1Di4IOziDHSJG9F3NtliTQ0ZkGuHaiofcVUozrym7y6vglCsn Mb1SVnP6Urb10jPyUON1pSZ6iIW/plxPNZNr7GLQEpYK98xFfX3d3XCtpBDLtLu+Zs t6ZYnT4GGExzCRKjtWKsmzkbTg/ZoKUekpYITQjRazEmytdre7RRAhv7SjmENkElpL iwk0dcEtStmQb3UZBut3Z5rcsmH6yN1ML7+Y6XXCMzsV/03WAJo9kuAQwr/uhfpY+G 8+qse64FK9LP5Oh/D9uO/aszJIa8eFj0nw0867RcsJMBVpDPY/+vVJDyJtLagavVOC Z02xeAzMFczZA==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MB8Fj5GsSz9rxK; Mon, 22 Aug 2022 12:47:37 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_2DBA252E-FD2D-4E53-A572-8E0AFB043ED1"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: "Schanzenbach, Martin" <mschanzenbach@posteo.de>
In-Reply-To: <644E3529-3AE0-4F50-B5AD-99AB2520F95F@depht.com>
Date: Mon, 22 Aug 2022 10:47:36 +0000
Cc: Warren Kumari <warren@kumari.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Paul Wouters <paul@nohats.ca>, Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>
Message-Id: <17322A52-F27C-4269-A267-B51565A42B17@posteo.de>
References: <8E78BAD2-59BA-49F0-B37A-B2B63E040C24@icann.org> <6c8f9df4-d3f-9b70-521-817ce4eb693e@nohats.ca> <CAHw9_iJDkWvxtXZ0vSB-FQQy3kV8SkQCNp+rcKaSG7S5WcpTGw@mail.gmail.com> <2d7aabce-743b-ff60-cbb5-243c72bcab95@cs.tcd.ie> <CAHw9_iKkHr=8hy+_71ffP5gUn6o5c004MZfzpapiq5U+658+0g@mail.gmail.com> <644E3529-3AE0-4F50-B5AD-99AB2520F95F@depht.com>
To: Andrew McConachie <andrew@depht.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SK_MUsP1V04RqO8Z-8T01evJHbc>
Subject: Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 22 Aug 2022 10:47:48 -0000


> On 22. Aug 2022, at 11:41, Andrew McConachie <andrew@depht.com> wrote:
> 
> 
> 
> On 20 Aug 2022, at 2:55, Warren Kumari wrote:
> 
>> On Fri, Aug 19, 2022 at 5:46 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
>> wrote:
>> 
>>> Hiya,
>>> 
>>> On 19/08/2022 20:43, Warren Kumari wrote:
>>> 
>>> So, it is perfectly acceptable (in my view) for it to have:
>>> 
>>> Reference Name
>>> ---------------------------------
>>> a-cool-document foo.alt
>>> another-document foo.alt
>>> yet-another-doc bar.alt
>>> 
>>> I agree that such duplicate names are acceptable in this registry.
>>> 
>>> I scanned the draft quickly and think it's good. (I'll try do a closer
>>> read in a few days.)
>>> 
>>> Only thing with which I'd argue for now is that I think RFC required is a
>>> much simpler rule for the registry.
>>> 
> 
> The draft doesn’t specify if this registry is restricted to ASCII LDH or not. Can I write an RFC and get #&^%&^%)(}{.alt?
> 
> How about ..alt? Or .alt? (My proposed string is NULL)
> 
> Why not allow unicode or at least some subset of it? If we want people to use this registry for their hip new naming system I think we should encourage developers to move away from ASCII LDH.

My interpretation is that there are no restrictions at all after ".alt". (I assume ".alt" should be in a format that DNS resolvers / servers understand).
I can see the pros and cons of this approach.
Implementing any kind of restrictions will open pandora's box wrt registration policy / reviewer considerations.
Not having any kind of restrictions will leave the registry open to strange requests like the ones you highlight.
I think you have pick one of those evils.

Also:
Given that it is unknown what encoding a protocol may use, it may be reasonable to consider that instead of Unicode, a byte string is provided with an optional encoding hint?
For GNS, Unicode/UTF-8 would work fine, however.

BR

> 
> —Andrew
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop