Re: [DNSOP] Last Call: <draft-ietf-dnsop-sutld-ps-05.txt> (Special-Use Domain Names Problem Statement) to Informational RFC

Ted Lemon <> Mon, 12 June 2017 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2347129526 for <>; Mon, 12 Jun 2017 07:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eg_l5k74NeN5 for <>; Mon, 12 Jun 2017 07:42:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7206412706D for <>; Mon, 12 Jun 2017 07:42:33 -0700 (PDT)
Received: by with SMTP id c10so128125550qtd.1 for <>; Mon, 12 Jun 2017 07:42:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iI2EgHe2vxd3I6Q7t3vjWXpCdMS0MUG0+jUTZj9M3JQ=; b=aM0Zkzlz4L3ZuCRxJBqUNcttj8yts7WeUGAu+H76THImdJgxljyRXKHWpJheEaI765 irhNiDftvBJY8hLsrnQy2XhvGTVgVQvliJ0mOfL9eEL8lMDSHUBjkOucI6spm/max0ve 5NUoQzDayrGEgTd97kZuXhcBb3upfx5gXT4A65CXATkKqlfTaN8WyPcxMxW4h+dMREk9 lf+c6JLsFeGbtgm9vciCEAutf9rCYXLQtVY/g739yRMN0CzRgp3+TDFcwc7MydKoxTAr rLQY2ZKiYNW7ikPcXgKR2KSvKsJisf82ZJhr70K4ih3b4mVd5FWMooCREWCJGJ4Tmv8Y QJOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iI2EgHe2vxd3I6Q7t3vjWXpCdMS0MUG0+jUTZj9M3JQ=; b=cyQnuQidk5bQO9M6x4SOeH/UDsAGeUdY5bq0ZtpKcpYMTDKWq574212ki7hKSx6W0H U+umfQ5W/O7TsA2eo0qnRjpelS+IDE4oFvCUVU2GOw3qTQvguPtSV26i3Mhhcx2vBxK0 tALwfyJrzvIVCE9xnskc6P9fPNLl85JXQbaDpnaSm6F/m8hhQv/W0C9GNWVfU2dOhKh1 RMtOPLU9b3h3UrDNWHBhXl1Ucfi0iJFZQrZwNK8xaeJwo77eEFACFz6XMm/YOoZBX7ed OCx5jMw8dSKh46H4xijI9L5lOnSdj6RUpK3WXdO6+xNu+Dsv1u4qjv7XwZxS24mcpoNa rVHw==
X-Gm-Message-State: AODbwcCtXW4RzTb1fCiqLGMg5mmHgU7jdfIqiUBAQObPXc0B/y/VIMfn CG0Qds27+iBLdA2B
X-Received: by with SMTP id l36mr52736358qtd.44.1497278552543; Mon, 12 Jun 2017 07:42:32 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id x78sm6731154qkb.44.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 07:42:31 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ted Lemon <>
In-Reply-To: <>
Date: Mon, 12 Jun 2017 10:42:30 -0400
Cc: ietf <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Stephane Bortzmeyer <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-sutld-ps-05.txt> (Special-Use Domain Names Problem Statement) to Informational RFC
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Jun 2017 14:42:37 -0000

On Jun 12, 2017, at 9:52 AM, Stephane Bortzmeyer <> wrote:
> Biggest point: the IESG decided to freeze the RFC 6761 process
> <> I regret this decision (RFC
> 6761 is still in force, it has not been deprecated or updated) and,
> unfortunately, registration of new Special-Use Domain Names is now
> impossible (pending an action on RFC 6761 that will probably never
> come). So, de facto, a regular process has been shut down, leaving the
> IETF without a possibility to register these domain names.

The point of publishing this document is to get a step closer to fixing this problem.

> Now, on the draft:
> * Section 3 says "No formal coordination process exists between the
> IETF and ICANN" This is not true, there is a formal liaison
> <> and it is even mentioned
> laster, in section 4.1.4. This issue was mentioned during the WGLC
> <>

What is meant here is not that the IETF and ICANN don't communicate, but rather that the IETF doesn't have a formal process for saying to ICANN, specifically, "don't use this name."   It's all informal.   It is done through the liaison, it's true, but there's no set of instructions to follow which, having been followed, we can point to and say "we followed the process."

We could replace the first sentence as follows: "Although the IETF and ICANN do have a liaison relationship through which special-use allocations can be discussed, there exists no formal process for coordinating these allocations."

Would that work?

> * Section 3 says "Use of the registry is inconsistent -- some
> Special-Use Domain Name RFCs specify registry entries, some don't;
> some specify delegation, some don't." There is no inconsistency
> here. RFC 6761 says (in its section 5) that the reservation of a
> Special-Use Domain Name is free to choose the rules regarding
> resolution, as long as they are properly explained.

The point here is not that every name should be treated the same, but that every RFC that does a 6761 allocation should specify how/whether the name is delegated every 6761 allocation should be added to the special-use names registry.

How about the following change:

   o  Use of the registry is inconsistent -- some Special-Use Domain
      Name RFCs specifically add registry entries, some don't; some specify
      how and whether special-use name delegations should be done, 
      some don't.

> * Section 4.2.2 says "the fact of its unilateral use by The Tor
> Project without following the RFC 6761 process" The onion TLD was in
> use in Tor since 2004, nine years before the publication of RFC
> 6761. It is grossly unfair to reproach not following an unpublished
> RFC. It was mentioned a long time ago
> <>

This was not intended as a reproach, but I see why you read it that way.   How about this:

      The situation was somewhat forced, both by the fact of its
      unilateral use by The Tor Project before the RFC 6761
      process became available,

> * Section 4.2.3 says "But it shares the problem that such names cannot
> be assumed either to be unique or to be functional in all contexts for
> all Internet-connected hosts." Unfortunately, because of the wide use
> of censorship through lying DNS resolvers, this problem is now part of
> our daily life. It would be nice if a name had the same global
> signification, but it is no longer true.

Andrew McConachie brought up the same issue.   Unfortunately I think this is out of scope for this document, but several people have expressed interest in formally documenting this issue—I think Andrew Sullivan expressed a similar sentiment at the mic in Chicago.   You might want to discuss this with them and see if there's work to do.