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

"Schanzenbach, Martin" <mschanzenbach@posteo.de> Thu, 04 August 2022 12: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 C01F7C13C514 for <dnsop@ietfa.amsl.com>; Thu, 4 Aug 2022 05:37:18 -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 d3JT70qW9r55 for <dnsop@ietfa.amsl.com>; Thu, 4 Aug 2022 05:37:15 -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 C7FC7C13CCD9 for <dnsop@ietf.org>; Thu, 4 Aug 2022 05:37:13 -0700 (PDT)
Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id B2D59240027 for <dnsop@ietf.org>; Thu, 4 Aug 2022 14:37:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1659616630; bh=BsuP9c6DxC/6esV7XI9bYVO71lv/AwpgIFB4BhehUf4=; h=Subject:From:Date:Cc:To:From; b=K/O6QNZvN/SxYd5ca4yl06x11eeT+6q66cfwn9wTtkjBc0vjryh9InlkjGZbZBQdF cYZbREEt5HNq09gtib1rNrE3dkhOg1+iOJi9XI/Bc/se2/JipUkE5ggwefE/SCklcp UZsWbCbzWewUhomT/G+h/Jvdm9ONiv9P8PzIxLI6Bimi2cEgoXsPyMSP3KrERP/QQW j1TeHYO28UXtcyVxttw7NaRByB9uA6CiI8mAK0J+oFH/+z/NWBuTyIPjSHfkNXtl9o ntJIrY9i+WCdX5MZynZq8YLJFVOUI7O1c2yJfyLGdvm/JNjnXS75EuRRYq/UMNftIT IO0jbW+3xgPRw==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Lz7XN3wCbz6tnq; Thu, 4 Aug 2022 14:37:08 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_E284777B-BB09-4C27-84B7-8C385109EAAF"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: "Schanzenbach, Martin" <mschanzenbach@posteo.de>
X-Priority: 3
In-Reply-To: <39865554.5880.1659614798712@appsuite-gw2.open-xchange.com>
Date: Thu, 04 Aug 2022 12:37:07 +0000
Cc: Independent Submissions Editor <rfc-ise@rfc-editor.org>, dnsop <dnsop@ietf.org>
Message-Id: <DEE9FECE-2647-4B8B-A64A-6D6E0E25F3FE@posteo.de>
References: <91abb9ac-9d3b-87bf-5639-174581d625fd@rfc-editor.org> <YufxYmxz9L8zG9hS@nic.fr> <1659368624-sup-8402@werkbank> <CAH1iCirbMBqSkE_+bTtWisEm_LxXj-3n2d1F1qL67_X+U7v7Jg@mail.gmail.com> <1659591584-sup-6027@werkbank> <39865554.5880.1659614798712@appsuite-gw2.open-xchange.com>
To: Vittorio Bertola <vittorio.bertola@open-xchange.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eCQU1_nFP0zyHXUIqjkcYuoJa70>
Subject: Re: [DNSOP] 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: Thu, 04 Aug 2022 12:37:18 -0000


> On 4. Aug 2022, at 14:06, Vittorio Bertola <vittorio.bertola@open-xchange.com> wrote:
> 
> 
> 
>> Il 04/08/2022 08:40 CEST Martin Schanzenbach <mschanzenbach@posteo.de> ha scritto:
>> 
>> Anyway, going to ICANN in order to collect a TLD is not a reasonable process for
>> publishing our draft.
>> We would not even know what the process would be (after the RFC? before
>> writing it? While writing it? What if ICANN denies a request? All the
>> work is moot?)
>> Similarly using "www.example.com!gns" et al. is not a reasonable change.
>> As that impairs usability and is incompatible with applications that
>> expect domain names.
> 
> The problem is that your entire project is conceptually and politically flawed.
> 
> If you want to establish an alternative namespace to the DNS, then you should not use DNS-compatible names.
> 

There are a lot of "DNS compatible" names that are not names in DNS. And namespaces. I hope you do not want me to start a list.

> ... and you should be damned.
> 

Oh great.

> If you want to establish a different way to resolve actual DNS names, then you should come here and propose a revision of the DNS protocol, or an entire new protocol to replace it, and have it standardized by the IETF, or rejected if the community disagrees with you.
> 

We went through the proper channels and procedures of the IETF regarding deconflicting before going the IS route.

> Also, if you think that your project requires a valid TLD in the existing DNS namespace, then you should get one following the same procedures as everybody else, which means either applying for a string to ICANN, or getting an IETF Standards Action specification as required by RFC 6761 section 4.

We did. Just to refresh everybody's memory: https://datatracker.ietf.org/doc/html/draft-grothoff-iesg-special-use-p2p-names-04
IETF decided to not follow their own procedures.

> An independent RFC would not meet these requirements, and I do not see why the ISE should ever publish it, except to create more confusion and more arguments.

Why did .onion meet those requirements? In fact, what requirements? .onion does not even have a specification for the name system it provides published.

> 
> More generally speaking, the DNS today is both a several billion dollars industry and a fundamental, regulated instrument for the political and socioeconomical stability of the entire world, way more than it is an IETF protocol. People are free to introduce politically motivated attempts to disrupt the current balance, but they should not expect cooperation, not any well-behaved global institution should provide any. Even if some of us may individually like the idea, as an institution the IETF is part of a bigger arrangement that it cannot unilaterally challenge without losing its face.

And IESG is able to identify a conflict right at this moment as part of the conflict review and prevent publication.
It is our goal to trigger discussions and show how an alternative protocol to resolve domain names could work and possibly how they can be experimentally integrated into the Internet infrastructure.
If that has no place in the RFC series (we are not even talking IETF/Standards Track here), then so be it. Are you the authority to decide?
I think it is still a matter of discussion if there is a conflict at all. And this discussion is currently held here.
You are trying to kill it using, what, political arguments?
Is the DNS namespace and its billion dollar industry so fragile that it cannot handle experimental alternative domain name resolution mechanisms that may be used for resolve "DNS-compatible" names as well?
And if the IETF is, as you insinuate, some kind of guardian of that industry that relies on the existing infrastructure, what chances would any proposal have going through the respective processes in the future?

BR

> 
> --
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bertola@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy