Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

hellekin <hellekin@gnu.org> Wed, 21 September 2016 23:22 UTC

Return-Path: <hellekin@gnu.org>
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 874D512D0DD for <dnsop@ietfa.amsl.com>; Wed, 21 Sep 2016 16:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.243
X-Spam-Level:
X-Spam-Status: No, score=-8.243 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOfviYybvvmM for <dnsop@ietfa.amsl.com>; Wed, 21 Sep 2016 16:22:08 -0700 (PDT)
Received: from eggs.gnu.org (eggs.gnu.org [208.118.235.92]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2309A12B5FC for <dnsop@ietf.org>; Wed, 21 Sep 2016 16:20:15 -0700 (PDT)
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <hellekin@gnu.org>) id 1bmqnu-0003KH-Bw for dnsop@ietf.org; Wed, 21 Sep 2016 19:19:53 -0400
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hellekin@gnu.org>) id 1bmqnu-0003K9-80 for dnsop@ietf.org; Wed, 21 Sep 2016 19:19:50 -0400
Received: from politkovskaja.torservers.net ([77.247.181.165]:56835 helo=[0.0.0.0]) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <hellekin@gnu.org>) id 1bmqnt-0000pL-Fs for dnsop@ietf.org; Wed, 21 Sep 2016 19:19:49 -0400
To: dnsop@ietf.org
References: <CAHw9_i+UVH78URWzk+4x=j9BZiKfX3C+UeFU9vz1OfZ3tPeN1Q@mail.gmail.com> <20160920133357.hbvtkrg5uwgzu4wh@nic.fr>
From: hellekin <hellekin@gnu.org>
X-Enigmail-Draft-Status: N1110
Organization: https://gnu.org/consensus
Message-ID: <bdc67224-ec80-0732-d338-1d8e0376e7a9@gnu.org>
Date: Wed, 21 Sep 2016 23:15:42 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160920133357.hbvtkrg5uwgzu4wh@nic.fr>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9t1bmuHBS2TnkPM2tt4gNL9zh7c>
Subject: Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Sep 2016 23:22:11 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 09/20/2016 01:33 PM, Stephane Bortzmeyer wrote:
>
> And I'm still not convinced there is a problem to solve
> (unless the real issue is "how to prevent the registration of .gnu and
> .bit?")
> 

Even if I supported the SUDN of P2P systems draft mentioning both .gnu
and .bit, I see a great deal of difference between them. .gnu (and
.zkey, .exit, .i2p, .onion) all require (and request) an unique NXDOMAIN
response from DNS, and use their respective protocols to resolve from
the "stub resolver" (as mentioned in draft-tldr-sutld-ps-04.) .bit is a
special case in our I-D because it proposes an alternate way of DNS
resolution, not using a delegated tree, but a blockchain.  With regard
to DNS, .bit is different from the other five, besides the political
effects of its specific approach (which I think should be able to exist
anyway, for the sake of Internet End-to-End principle if nothing else.)

None of the problem statement drafts took reference of the Special-Use
Domain Names of P2P Systems which initiated this years long discussion
that ended up with: should we revise or replace RFC6761.  In my position
of editor of this draft, I don't really care what happens to RFC6761,
but I'm very much interested in .gnu & .zkey, .i2p, .onion & .exit, and
.bit.  I don't think any of the proposed problem statement drafts
mention the perspective of actual P2P networks sharing their experience
and their existence, and coming to the table with the idea of abiding to
the IAB rule of a globally unique namespace.

We say: hey, look, we exist, and we want to say that these are not
transactional names: they bear cultural value.  They came from usage and
the history of the Internet.  The DNS should know about them, so that
people won't ever get into trouble trying to resolve non-existing names,
or trying to resolve eventually delegated names that will collide with
existing networks if they keep being ignored by DNS.

I had the time to appreciate the nuances that IETF members can find in
this seemingly simple approach, and try to generalize the issue: "what
if others come and do the same? Who's responsible? How to judge of the
legitimacy of those claims?" Etc.

But what's been going on, from my point of view of volunteer who only
has one life (that at least we share) and doesn't get paid for this
work, is choking-by-bureaucracy.  People whose profession is to sit on
IETF WGs can spend their time not solving issues, they still get food on
the table.  And so production of norms is an endless process, and if not
this one, another.

As I see it, the problem we're trying to address is whether these P2P
systems warrant some recognition from the Internet Community, is that
something we want to encourage, or is that something that belongs to
"the Deep Web", and we'd better leave that out of the picture?  I'm not
talking about .mail, .corp, and .home, that belong to another category
(I like "toxic waste"), or "people trying to circumvent IANA processes",
or "don't want to pay", or "don't want to follow process".  We did
follow process, once we realized there was one.  And suddenly, after a
decade, everybody realizes there's an RFC6761 that really shouldn't have
become an RFC in the first place, and this process is flawed, and we
don't know how to handle this.  But when the Browser Forum comes with a
deadline, consensus is easily achieved in no time, despite the draft is
flawed with idiotic requirements such as "Users are expected to...".

My take is that none of the proposed statement drafts took care of
situating the debate in its (recent) historical context.  The fear of
frictions between IANA and IETF have had more to do with how things
went, than actual ponder of the technical arguments put forth by the
various RFC6761-based drafts.  Case by case is not necessarily evil: not
everything can nor should be automated.

I believe that in the case of the 6 TLDs we asked for, there's little
doubt they make sense technically, historically, and culturally.  That
others may take it as 'a way in' and flood the IETF with stupid drafts
'just in case' seems to me the core of the problem, that was mentioned a
few times over the years, but didn't make it through the recent drafts.

> The rest of this email is about
> draft-adpkja-dnsop-special-names-problem-06. Executive summary: no, no
> and no.
>

This is a great summary, thank you!

==
hk

-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJX4xScXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg95ckP/0/Ub0IPt7VQWBbjH914gbAP
v1fKjQhuMSUiuYa+KJ7AyYTvTjqH6+NgEx5T/1a5F+tcTlD7rEQ6C4UDYqUTqUBS
fa+H0i3sGkJT7it6vV5sjB9LTLb2Dmxff6uZkeBVtUbrun2Xl9uzBq9+rBloBQN0
5WDr2ykEbnTIBIM2bbBlhJSpHO6jhLgXhYQkWiFK+7c1zI2X3qNp6dlCnwJ9Gy7d
KNQNUMmBllAepF6kF0kXv07I8cEPjx9bRc6LY5wIW08Sa3j3R0UEtzBoUODFr/oJ
RbIq0bJgK8COZfEzEv6oJ1iDT64JXi2FxlPflBdqgFHiPQSX1Ermm1UtJU1Wrrcb
S/Y6890dyJOa+014KUBdroGeH/MfZLHwKJELi6bs2wENkGp8ye6LwIOeJBOfJ47/
6Tt7ow+j9y05Xjh9lM1pOlQdlsusLmOHiBQ7cfWb1uo3XYCr5e86cUQ6S/3iBg17
y0WfX1mFjWTvBnrLqMQrXTThiItMT+WN5JzkEcwfMv00oF62DQYh89WPzQ1SVSqQ
vCQbCi5a25JfLtbS/LgJo4diXlnayMhJ5RtQIdBEbej2kO971eoYLxwma8jDB3gv
mV8cJcjg4juj8Rpp0+eYsSNnOSlHcuZoaJBrpgd7XQNejuLZdR5/E3NmY1T+0Kif
vVimJR3aa0C5SQQVFDxM
=1b0u
-----END PGP SIGNATURE-----