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

George Michaelson <ggm@algebras.org> Wed, 21 September 2016 23:30 UTC

Return-Path: <ggm@algebras.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 B05B212BE69 for <dnsop@ietfa.amsl.com>; Wed, 21 Sep 2016 16:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.607
X-Spam-Level:
X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com
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 5reUSiNmnu2L for <dnsop@ietfa.amsl.com>; Wed, 21 Sep 2016 16:30:13 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D0B12B75D for <dnsop@ietf.org>; Wed, 21 Sep 2016 16:30:12 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id 192so3464377vkl.0 for <dnsop@ietf.org>; Wed, 21 Sep 2016 16:30:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oMK8RyzdcNhHejsrz48Os9Y3j7Wy+iCr5fT7TpJkd4o=; b=vwFA93KhSRqqQnA3huvI3pVSUQTc9cAlYKm0IKX+tXiHFffbt+UwmSJnzrqoGJpGmp y0vXZUMapqSjwopzROxLwN9SslYR9HTdCbjHNGqZZqZ0w6X15Gb1PQI9woiGM8qim1AC zTB7yasckayu9eJZ7n5rf4cGyx1B9KovGs94hpW/i5faw/CoHRc7w/hgWsKP2UFsMfiW cddCkg1bNZoKCHKniL1XCLkQDAXuv0KpUNWb4rz+cmi8x78XOn1st9l5WTed/x3PQhAw pnsN51QPz8HULnvlQP/EJdQC4ZxLbeO8xP4OR5sARhXY2D6sRyr1ZhKPHA7Yauj56KLc hTcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oMK8RyzdcNhHejsrz48Os9Y3j7Wy+iCr5fT7TpJkd4o=; b=cYLtBo+oruiACh1Ah3k5ckacU8mhFUz5XFfyM3x04Iny/RpRAZvzPMMYlmddUJmNvE 7OxZsTpOMlY+hlyaq9vbvz9PAISiSZGakbSsssUpLuDMtyv92v6QkCk9bTg4lGQOUIjc SJ2UVnAVlFsu3i9n/7JIN0Z+vG5BCU1e7V/ITm0RunPMV7fS8xjzyPEGHEcKho5YOsK3 2iegxP9WoWl0aJR57DVUk+J9U2nmGEVkgXcdDZR5skByGw10azpETl8y64SrgdDLxmdv 2YTGynYnxl8AQPBrpwDFesCVEo/qXbDV5I1mVBLsO3mWcfzehtk7cdewUDxRw5KzZVQw btlg==
X-Gm-Message-State: AE9vXwMf7j/JA5yDt+CpN3GOkwmK1q/3/NUf4GDhY7S8HPI2BbseCKMuYJIqHCFKtTaZPqMvAxKZ3aGpUGeeeQ==
X-Received: by 10.31.153.20 with SMTP id b20mr524807vke.111.1474500611784; Wed, 21 Sep 2016 16:30:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.50.73 with HTTP; Wed, 21 Sep 2016 16:30:11 -0700 (PDT)
X-Originating-IP: [2001:dc0:a000:4:45e3:9b4a:5536:45c9]
In-Reply-To: <bdc67224-ec80-0732-d338-1d8e0376e7a9@gnu.org>
References: <CAHw9_i+UVH78URWzk+4x=j9BZiKfX3C+UeFU9vz1OfZ3tPeN1Q@mail.gmail.com> <20160920133357.hbvtkrg5uwgzu4wh@nic.fr> <bdc67224-ec80-0732-d338-1d8e0376e7a9@gnu.org>
From: George Michaelson <ggm@algebras.org>
Date: Thu, 22 Sep 2016 09:30:11 +1000
Message-ID: <CAKr6gn0Dezee9JB1g+fBKqDsg4gHjau96S-ZTC4L4xpincsOwg@mail.gmail.com>
To: hellekin <hellekin@gnu.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GSUBgmDwv6MRoLf_Yq1RnpiUtzU>
Cc: dnsop WG <dnsop@ietf.org>
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:30:16 -0000

None of these named spaces would "fail" to work as sub-spaces of .ALT
or .arpa or any other community-led IETF tech community managed label.

You haven't convinced me they innately need to exist as a TLD. The
sole entrypoint into that model, is a belief in what happens in the
browser bar and at the shell.

You are the designer of systems of world scale, I do not doubt. But
you are bringing an assumption to the table: all things of world scale
do not have to exist at the top of the worldwide name space.

I remain unconvinced. I remain of the belief, that shutting 6761 down
is wiser than racionation over the problem space, without recognizing
intractable elements to this problem because its not at root a
technology problem: its a name problem. We gave that role to somebody
else.

-G

On Thu, Sep 22, 2016 at 9:15 AM, hellekin <hellekin@gnu.org> wrote:
> -----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-----
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop