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

George Michaelson <> Wed, 21 September 2016 23:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B05B212BE69 for <>; Wed, 21 Sep 2016 16:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.607
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5reUSiNmnu2L for <>; Wed, 21 Sep 2016 16:30:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6D0B12B75D for <>; Wed, 21 Sep 2016 16:30:12 -0700 (PDT)
Received: by with SMTP id 192so3464377vkl.0 for <>; Wed, 21 Sep 2016 16:30:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id b20mr524807vke.111.1474500611784; Wed, 21 Sep 2016 16:30:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 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: <>
References: <> <> <>
From: George Michaelson <>
Date: Thu, 22 Sep 2016 09:30:11 +1000
Message-ID: <>
To: hellekin <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: dnsop WG <>
Subject: Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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


On Thu, Sep 22, 2016 at 9:15 AM, hellekin <> wrote:
> 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
> iQJ8BAEBCgBmBQJX4xScXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> 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
> _______________________________________________
> DNSOP mailing list