Re: [DNSOP] draft-ietf-dnsop-alt-tld-19

Martin Schanzenbach <mschanzenbach@posteo.de> Wed, 14 December 2022 10:08 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 33043C1524CD for <dnsop@ietfa.amsl.com>; Wed, 14 Dec 2022 02:08:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.396
X-Spam-Level:
X-Spam-Status: No, score=-4.396 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_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 J2O3bDnMg9RM for <dnsop@ietfa.amsl.com>; Wed, 14 Dec 2022 02:08:27 -0800 (PST)
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 1B9D6C1516F7 for <dnsop@ietf.org>; Wed, 14 Dec 2022 02:08:25 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 8E4CC240029 for <dnsop@ietf.org>; Wed, 14 Dec 2022 11:08:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1671012502; bh=UcPo/9LNIVUJ91Yxfj5grf17aDs6orEpDGUQ59Z/A2o=; h=Date:From:To:Cc:Subject:From; b=kRmViuSAm8hSgLpYTemO1epIQaXG1aRYOjQ7wcNB/jKub6aUFszXBEV8i2Jd0YYu+ jFLvgM0X5H9p6BZPSDL42rycZnQg2CY9b6GX8H96N+0wZSWEsBaF32vSa+lSEUcvZC A0zDpXcBDSVkaElYhbDqcDBFoTFXLNnrZ/5gWOMQqVT3k0a49/7z5q2Sw0WLiSmpNN 36MHf9STRhZ8/hAjTo+oVVz95nLr1PiJMMMcr3sFFMAma1DN6zriKWKLYt5f3/Onm8 Ir3qg5LBEbO+a0rw4gZtFElNiosi0+XiKJSBX/lkGOMNp2weD/fmO42SFZJmwGPYib ZdYITZj6arZ4A==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NX9zm6lKSz6tmG; Wed, 14 Dec 2022 11:08:20 +0100 (CET)
Date: Wed, 14 Dec 2022 10:08:17 +0000
From: Martin Schanzenbach <mschanzenbach@posteo.de>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: dnsop <dnsop@ietf.org>
Message-ID: <20221214100817.qsuejhcom24hqoxl@werkbank>
References: <B76AEB6C-9C0F-4DB1-A1E9-39E325D9E5A7@icann.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="jizl7oaepjxniowk"
Content-Disposition: inline
In-Reply-To: <B76AEB6C-9C0F-4DB1-A1E9-39E325D9E5A7@icann.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nkHqAhV0NTvnwqjikP3p-fNolnE>
Subject: Re: [DNSOP] draft-ietf-dnsop-alt-tld-19
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: Wed, 14 Dec 2022 10:08:31 -0000

Hi Paul,

the draft lgtm. But, the passage regarding collisions because of
the missing registry now contains a regression IMO:

"Developers are wholly responsible for dealing with any collisions"

I think this is an impossible task and as a developer that is addressed
here I have to say that we cannot do that unilaterally for our
implementation/design because collisions occur when _others_ do
something.
Maybe you are talking about "groups" (as used in this paragraph) or the
"alternative name system community" here, which would make more sense?
This paragraph also uses both "groups" and "developers", and the
difference (to me) is not clear.

Maybe simply strike this sentence again?
Instead or in addition maybe a full acknowledment of this issue in the
security considerations, along the lines of

"
This draft does not define a registry or governance model for the .alt
namespace and as such developers/groups as well as users and applications cannot
expect unambiguous mappings from names with a ".alt"-TLD to a specific
alternative name space / name resolution mechanism.
This issue can be mitigated, for example, through the creation and use of a
registry by the alternative name system developer community.
"

Best
Martin

On 13.12.22 20:20, Paul Hoffman wrote:
> Greetings again. As you can see, Warren and I just updated the draft to reflect the WG discussion at IETF 115 and on the list after that. At IETF 115, the WG chairs said that they might move this to a second WG Last Call soon.
> 
> In the discussion, there was lots of active disagreement about reducing traffic to the root servers, particularly around what it would mean for recursive resolvers filtering for .alt. One such proposal that came up was scrapping this draft and moving to AS112, but there was little interest and some strong pushback.
> 
> Thus, we did not include any proposed way to do this in the new draft, although we did make a strong push towards methods resolvers could use that would reduce root queries for names ending not only in .alt, but all other non-existent TLDs.
> 
> --Paul Hoffman
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop