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

hellekin <> Sun, 02 October 2016 09:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 141B212B065 for <>; Sun, 2 Oct 2016 02:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.903
X-Spam-Status: No, score=-8.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id poXsajS_f7nk for <>; Sun, 2 Oct 2016 02:41:32 -0700 (PDT)
Received: from ( [IPv6:2001:4830:134:3::10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 975CC12B058 for <>; Sun, 2 Oct 2016 02:41:31 -0700 (PDT)
Received: from Debian-exim by with spam-scanned (Exim 4.71) (envelope-from <>) id 1bqdGw-0000b6-7l for; Sun, 02 Oct 2016 05:41:29 -0400
Received: from ([2001:4830:134:3::e]:44334) by with esmtp (Exim 4.71) (envelope-from <>) id 1bqdGw-0000ax-4I for; Sun, 02 Oct 2016 05:41:26 -0400
Received: from ([]:33448 helo=[]) by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <>) id 1bqdGu-0002CF-2P for; Sun, 02 Oct 2016 05:41:24 -0400
References: <alpine.OSX.2.11.1609292041280.86752@ary.qy> <> <> <> <> <> <> <> <> <>
From: hellekin <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Sun, 2 Oct 2016 09:37:12 +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: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
Archived-At: <>
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: Sun, 02 Oct 2016 09:41:35 -0000

On 10/01/2016 07:12 PM, Paul Wouters wrote:
> the IETF doesn't have the money for lawyers in that arena.
> [snip]
> I do not think the IETF should create "Special Names" that conflict
> with the naming process which has been delegated to ICANN.
> [snip]
> The IETF giving them .onion in itself has been a very risky decision. It
> was based on no Big Corporation having an interest in the string. With
> .gnu people did not feel as sure about that. I think that's part of the
> reason .gnu was not also going to make it like .onion. These decisions
> are quicksand.

Thank you for verbalizing that.  Had it been done earlier, I'd have
joined a commercial letter of interest of the GNU corporation who sells
snowboards to the RFC as an appendix, in order to make a precedent that
a technical document can be vested or vetoed by private interests based
on legal risk and self-censorship.

Given the recurrence on this list of the term "squatting" to refer to
real use of a non-ICANN-sanctioned TLDs, and the assumption that people
should be aware of IETF and ICANN processes and avoid using such names
in the first place, that transpired in many negative comments of P2P
Names, why not consider that corporations, being 'people', fall into the
same bag as ourselves, and should be aware that there have been such a
process going on for 3 years already, and they didn't claim anything
about thoses requested TLDs, which shows *no prior interest* in doing
so.  I wonder what kind of court would accept a post-delegation lawsuit
in these conditions.

Nevertheless, I take note that finally, someone put that on the table
clearly and honestly.

I'd like to finish on the note that nothing in RFC 6761 *tells* ICANN to
reserve a name.  Instead it reaffirms that

   The IETF has responsibility for specifying
   how the DNS protocol works, and ICANN is responsible for allocating
   the names made possible by that DNS protocol.

In RFC 2606, IANA considerations say:

   IANA has agreed to the four top level domain name reservations
   specified in this document and will reserve them for the uses

So, even if the IETF reserves a name, it is more like a suggestion for
ICANN to ponder.  Maybe this should be clearly stated within the problem
statement and following materials to avoid IETF self-censorship to avoid
a legal threat.  As a person, I'm not too keen on the idea that someone
could sue something just because they can.  That's a very late-20th
century U.S.American notion that is not particularly welcome in the rest
of the world, and secret corporate courts suing government or other
institutions in the name of 'free trade' sound like neo-colonialism.  So
for good measure, *at least* one step to solve 'the problem' would be to
make it clear that the legal responsibility goes to the big guy in the
room, in our case, as for precedents in relevant RFCs, IANA.  If this
legal risk argument is the main show-stopper, I suggest it's vaporscare
and *not technical*.

## Reminder

The introduction of RFC 6761 gives its scope:

   However, "Reserved Top Level DNS Names" [RFC2606] does
   not state whether implementations are expected to treat such names
   differently, and if so, in what way.

   This document specifies under what circumstances special treatment is
   appropriate, and in what ways.