Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

Martin Schanzenbach <mschanzenbach@posteo.de> Tue, 02 August 2022 20:10 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 913A9C14CF08 for <dnsop@ietfa.amsl.com>; Tue, 2 Aug 2022 13:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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 tHMhUv4hJ39G for <dnsop@ietfa.amsl.com>; Tue, 2 Aug 2022 13:10:01 -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 4528FC14CF02 for <dnsop@ietf.org>; Tue, 2 Aug 2022 13:10:00 -0700 (PDT)
Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 81C48240026 for <dnsop@ietf.org>; Tue, 2 Aug 2022 22:09:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1659470997; bh=pRHhGcxrKYEGBccaJ0YAkUw7wnVmj9v5gixd/veAsmg=; h=From:To:Subject:Date:From; b=DCbPUJT8F9BaWv+wlbRipmI2NextCz5lO7G/v9DwyrGXR2sivX2NalyzyrOoie3UY vRePBk2w2krt1fN82cZtdL5p2G3SKxPtH9xWHf6bA28Js2u+Gfen+7qyud55uE/2lJ QxEo/kkttju/jw7iscZiDqzcKjs3zek4c7LXSXWVZIlvIwHKVS3Ut+tZClcFSTORBo bPU1MHpnzCOqXg2OJmEgMKohDgCa8SarC2HMHqec4BOLrMEMm7PG2uQ4ih13PypHMW E+OHA6SrveMvkbeNt9LzrKRs3LC2tLgCeygFyT0tyrBxdRAQ3GJiGeIh+x9mQO6IDc 7kRM2f5wOQwdQ==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Ly5gm2WT5z9rxR for <dnsop@ietf.org>; Tue, 2 Aug 2022 22:09:55 +0200 (CEST)
From: Martin Schanzenbach <mschanzenbach@posteo.de>
To: dnsop <dnsop@ietf.org>
In-reply-to: <20220802193440.2btqhcys6f3cqpwz@crankycanuck.ca>
References: <91abb9ac-9d3b-87bf-5639-174581d625fd@rfc-editor.org> <5D598E6D-932F-4855-8D5F-C2DEDD20738C@icann.org> <20220802193440.2btqhcys6f3cqpwz@crankycanuck.ca>
Date: Tue, 02 Aug 2022 20:09:55 +0000
Message-Id: <1659470522-sup-5316@werkbank>
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="=-1659470995-439018-170943-8684-8-="
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0arjA-_TRIGq3PtOuS7MZre8Wko>
Subject: Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld
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: Tue, 02 Aug 2022 20:10:05 -0000

I just read it and on page 5 it specifically excludes .onion and .gnu as
those do not use the DNS protocol (citing also the alt draft here).
So this is equivalent to the .alt draft only if the private-use TLD is
not limited to private-use DNS queries as investigated in the document.
I find this to be quite odd as I thought this is what .arpa was for
(RFC8375)!
.home is even listed in the table of the SAC document and one of the
motivations.

So, we would have to see what the actual proposed *use* of this private
TLD would be. If it is limited to DNS, then it is of no use for
alternative name systems and we would still need .alt.

Excerpts from Andrew Sullivan's message of 2022-08-02 15:34:40 -0400:
> Disclaimer: I work for the Internet Society but I am not speaking for them.
> 
> On Tue, Aug 02, 2022 at 07:11:38PM +0000, Paul Hoffman wrote:
> >
> >recommends that the ICANN board to pick a string that will never be put into the DNS root, and thus is usable for systems like GNS.
> 
> This was, of course, the whole point of the .alt draft in the first place, at least when I was involved in preparing it.  I don't think any of us involved then cared whether it was alt or one of thousands of other strings that it could have been.  The main point was to come up with something that would not pad total length too much and that could be a clear "protocol switch".  The registration in the IANA sutld registry was suppossed to ensure the same outcome as what is going through SSAC, but it makes no difference to me what the characters are.  Note that because of the old-timey restriction, I suspect the characters must all be alphabetic, though perhaps that rule has been superseded by IDNA.
> 
> A
>