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

Martin Schanzenbach <mschanzenbach@posteo.de> Wed, 14 December 2022 10:37 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 573B3C152702 for <dnsop@ietfa.amsl.com>; Wed, 14 Dec 2022 02:37:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_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 Tm81hXnkAghS for <dnsop@ietfa.amsl.com>; Wed, 14 Dec 2022 02:37:20 -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)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E404C14F731 for <dnsop@ietf.org>; Wed, 14 Dec 2022 02:37:19 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 09131240027 for <dnsop@ietf.org>; Wed, 14 Dec 2022 11:37:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1671014236; bh=/ZP0ZE5RTNsi+d66v73S6I0No9cKxG9VHNXeOq7pxEk=; h=Date:From:To:Cc:Subject:From; b=mVhNGB0FHMHVjBhyHp8R2MmsA+nhf6zOPiBxwGvTjmLmo3sPkudAWl1Wa2DP3bNES 47ifZatwV41dvih3tbQBjVVToj2Fj48r7p3eqETOvtca6UAv8mVpPw4UitMjcl2cxu Jz5NApiu9M3dXb4REl+QTAY5/GnZxdwl1LVzKRkHTDbzW9Hehov0EXEz8BmSHPfIZP /4oCq0nWpLsYCHPcZsY7pgUvxn1HeIDXNSiCyiZlz6AUEcOu/HI7UB44AgQvVTR3JA 9E2Bfndv+t8T8MGdDka/alhrjVqASHEHczhYBRBu/M5k2tiTad3XP2Wg4y+LfJ6syh O7m0bUrUcBhEg==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NXBd61K87z6tmB; Wed, 14 Dec 2022 11:37:13 +0100 (CET)
Date: Wed, 14 Dec 2022 10:37:10 +0000
From: Martin Schanzenbach <mschanzenbach@posteo.de>
To: Joe Abley <jabley@hopcount.ca>
Cc: Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>
Message-ID: <20221214103710.zm6t5oshhnfwsm4g@werkbank>
References: <B76AEB6C-9C0F-4DB1-A1E9-39E325D9E5A7@icann.org> <20221214100817.qsuejhcom24hqoxl@werkbank> <2k3m5sj59-6nJQroDIS5yJivZtAMa_b-_7s7wVeCeb1Dy1GHJMT5EsnsI5YN9AJYtmhCzbq-TbAlS1lUxlpQd1LfE3kxyRaCbbz4mnTPfG4=@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <2k3m5sj59-6nJQroDIS5yJivZtAMa_b-_7s7wVeCeb1Dy1GHJMT5EsnsI5YN9AJYtmhCzbq-TbAlS1lUxlpQd1LfE3kxyRaCbbz4mnTPfG4=@hopcount.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xIflvSyb0UmM7DoXZ6vBJ1aPZ20>
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:37:24 -0000

On 14.12.22 10:19, Joe Abley wrote:
> Hi Martin,
> 
> On Wed, Dec 14, 2022 at 10:08, Martin Schanzenbach <mschanzenbach@posteo.de> wrote:
> 
> > "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.
> 
> I don't understand why you say this is impossible when it is what happens today and what has always happened.
> 
> But perhaps I don't understand something about how "developers" is intended to be interpreted. I agree it would be nice to clarify this sentence if it is to remain.
> 

I think my main issue is the word "wholly".
The developer cannot be "wholly" responsible.
I can choose a label (e.g. "foo.alt") that is not already taken right
now.
But I cannot really do anything if somebody else comes along and uses
the same label. It is not my responsibility to mitigate the emerging
collisions. Or how is it expected that I do that? Change my design?
Bribe the other group?
"bob.foo.alt" still squarely falls into "my" namespace, so I cannot
write a single line of code to mitigate the collision.
Not only is it not really possible for me as a developer to do that, it
is also unlikely that I even notice this issue as a user.
Is the developer of a DNS server/resolver in any way responsible if
"alice.eth" collides with ENS? Or what do you mean by "this happens
today"?

BR
Martin

> Joe
> 
> >