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

Eliot Lear <lear@lear.ch> Wed, 14 December 2022 10:56 UTC

Return-Path: <lear@lear.ch>
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 3FBA5C152703 for <dnsop@ietfa.amsl.com>; Wed, 14 Dec 2022 02:56:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.888
X-Spam-Level:
X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=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=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 uM6eIUR5cnnT for <dnsop@ietfa.amsl.com>; Wed, 14 Dec 2022 02:56:32 -0800 (PST)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [IPv6:2a00:bd80:aa::2]) (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 30ABAC14F718 for <dnsop@ietf.org>; Wed, 14 Dec 2022 02:56:30 -0800 (PST)
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1671015362; bh=GJWiz3FhZ2L/f6n7hUxm6TB1cmjJTTKUArfMACBUCUs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=vlqHC+E+T49/s4s2HThuTbAjWlOZ+FVzkeO7SGC1pFoJK3NYfe+nv3HKFgFSw5T7q 6APDvJwikWuOk1yu2RMkRS7OwhxuAqIuvOdmuR9gmTAlqFanj9Rhc0ldiC3Tg5aVy5 EuvMg9+3tatWiQLNHtGhBU/dS646sBFTofyJmY8w=
Received: from [192.168.0.222] (77-58-144-232.dclient.hispeed.ch [77.58.144.232]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 2BEAu1Kf107092 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 14 Dec 2022 11:56:01 +0100
Message-ID: <3b6b7e15-6bd6-73ab-08d0-54f0397f9486@lear.ch>
Date: Wed, 14 Dec 2022 11:56:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.5.1
Content-Language: en-US
To: Martin Schanzenbach <mschanzenbach@posteo.de>, Paul Hoffman <paul.hoffman@icann.org>
Cc: dnsop <dnsop@ietf.org>
References: <B76AEB6C-9C0F-4DB1-A1E9-39E325D9E5A7@icann.org> <20221214100817.qsuejhcom24hqoxl@werkbank>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <20221214100817.qsuejhcom24hqoxl@werkbank>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------qqbABFl8YRk9rG5em2gQijZJ"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ltw76TxOZB9hO55fugfmy7ndI1Y>
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:56:36 -0000

I think the point here is that collisions within the alt name space are 
beyond the scope of this document.  Perhaps that's what should be said.

Eliot

On 14.12.22 11:08, Martin Schanzenbach wrote:
> 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
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop