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

Ted Lemon <> Wed, 21 September 2016 23:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D62D12BBF2 for <>; Wed, 21 Sep 2016 16:57:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.346
X-Spam-Status: No, score=-1.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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 Z-Sz8J2UtJ9y for <>; Wed, 21 Sep 2016 16:57:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC7A112BD65 for <>; Wed, 21 Sep 2016 16:57:49 -0700 (PDT)
Received: by with SMTP id y6so54934273lff.1 for <>; Wed, 21 Sep 2016 16:57:49 -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=TLYMM2sMuJ34Zr8wTqt6B9D3CEtEHEGpIYH9ciRdsN0=; b=K5kYV6TT5/DXoTlYlqiksXnK739SO9pFB12klTQ2dr/9AyjHdsiXy9ewaJroOt3EoH 4kxwjgi/FQ7QtUZ37U0gDhnxUErHI2789Ui4WzzuuV6IAAu/nQUzq5/N8Kn/q33xCxs6 DJx6y+6/yEdbHGWpbDDr3+xGZRnO7xPxNLLEVFI28oeCJCkcIVu+V4NT4/OIFjQwILop yQbJRUaG23CL/uiuwz7XgiAqRUV6iJ3u2VRksaxJ6R6+vqYAEsdeYm2ccQAYaXGW7W9K lJevexeZo648ckDl987AkBmphORR0YdEvSzD7fX0NTz08aqO0InlRkUyiXkabDZRtZT8 8OEg==
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=TLYMM2sMuJ34Zr8wTqt6B9D3CEtEHEGpIYH9ciRdsN0=; b=Eeh01Z3Kg10n5NTkbhqyog8z9zuO4U1hZ9UmKg7m9lYrvfev20fEFYpqC+u2tM3bsM 8OwVXIBzCCg5iLlMbhhwGGwE9Rcs6uaBF4hZCobQ+Wu4sFUfpQ9ZOD9gX0LuOe1T9Aph z68b2DSkGtohiL/gZ+maoGqa03YVx4rznoejNHBmCZkeIWT5nKJ/GIPQp16PhoLBAOg8 9BMgrEg825zhjKkx3zFKtNwpL1WvRheFA4E4GzgSSHsMgY4couRQgnz49Tp1+fEQ8yaS IkhHS0Xfsyg6ZqmetGh+SV97cim4nZuXExIpcjdqxkAyqUSA1U0L6FVyTiMF2qat3in8 EJpQ==
X-Gm-Message-State: AE9vXwPIC+c/6hMWTn+tK2m/mCzwlIiLDlFTKPZgaEnYBkMWnbzrluw2pnX4ps0GA9R/KBOUraVjs/6dFfnc7g==
X-Received: by with SMTP id 35mr13072001lfy.176.1474502267657; Wed, 21 Sep 2016 16:57:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 21 Sep 2016 16:57:06 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Ted Lemon <>
Date: Wed, 21 Sep 2016 19:57:06 -0400
Message-ID: <>
To: George Michaelson <>
Content-Type: multipart/alternative; boundary=001a11411574e2777e053d0d4f2d
Archived-At: <>
Cc: hellekin <>, 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:57:55 -0000

The problem with this kind of certainty is that it's not conducive to
reaching consensus.   The reality is that there are a broad set of people
with interest in this question, and they have different beliefs and
different motivations.

That's why it's important to go through the exercise of having those people
say "this is what I see myself losing if (for example) RFC 6761 is
deprecated with no replacement."   And then we see who those people are,
what they will do if they don't get what they want, and so on.

The problem with the way you are coming at it is that you are just one of
those people, and what you lose with your proposed way forward is nothing
you care about, and what you gain is something you care about a great deal.
  There are many people in the exact same situation in this discussion, but
with different things that they lose and gain.   So we have to all try to
understand each others' perspectives in order to come up with a way forward
that can gain consensus.   We can't just start arguing over which way
forward to choose without doing that groundwork first.

On Wed, Sep 21, 2016 at 7:30 PM, George Michaelson <> wrote:

> 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 <> 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
> > 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 mailing list