Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

Russ Housley <> Mon, 06 February 2017 19:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA3531295C1 for <>; Mon, 6 Feb 2017 11:21:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6j99NgjLDjSq for <>; Mon, 6 Feb 2017 11:21:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A6C61294C7 for <>; Mon, 6 Feb 2017 11:21:51 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB8BF300424 for <>; Mon, 6 Feb 2017 14:21:50 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id 2YEN0TOcwKNI for <>; Mon, 6 Feb 2017 14:21:49 -0500 (EST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 021A7300222; Mon, 6 Feb 2017 14:21:48 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C4A62C5B-15A4-470A-B02E-9B3B3EEF7450"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <>
In-Reply-To: <>
Date: Mon, 06 Feb 2017 14:21:46 -0500
Message-Id: <>
References: <>
To: Suzanne Woolf <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: dnsop <>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps
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: Mon, 06 Feb 2017 19:21:54 -0000

> This message opens a Working Group Last Call for:
> "Special-Use Names Problem Statement"
> Proposed status: informational
> Starts: 2 Feb. 2017
> Ends: 23 Feb. 2017 (3 weeks)
> Discussion should go to the mailing list. 
> Is this draft ready to advance for publication as an Informational RFC, and as guidance for possible updates to RFC 6761? Does it describe the relevant issues clearly, and cover all the relevant ones that should be taken into account in future work in the IETF on the special use names registry or RFC 6761?

I think the document should be published an Informational RFC once the comments are resolved.  I think it offers a good foundation for a future rfc6761bis document.

I have several comments…

I think the title should be Special-Use Domain Names Problem Statement.  The abstract talks about domain names, so the title should match.

Will I-D.lewis-domain-names be published as an Informational RFC as well?  If not, then the Introduction needs to extract highlights from that document.

These three bullets in Section 3 overlap:

   o  Both ICANN and the IETF have the authority and formal processes to
      assign names from the pool of unused names, but no formal
      coordination process exists.  The lack of coordination complicates
      the management of the root of the Domain Namespace and may lead to
      conflicts in name assignments [SDO-ICANN-SAC090].

   o  The IETF and ICANN each have administrative authority over the
      Domain Namespace.  Not all developers of protocols on the internet
      agree that this authority should reside with the IETF and ICANN.

   o  Although IETF and ICANN nominally have authority over this
      namespace, neither organization can enforce that authority over
      any third party who wants to just start using a subset of the

I think there is one main point and two observations.  The main point is that both ICANN and the IETF have the authority and formal processes to assign previously unused names.  The first observation is that ICANN and the IETF need to coordinate to avoid conflicts.  The second observation is that some think that the authority is misplaced.  The second observation needs to be expanded to state the consequence, which I assume is squatting.  If I guessed correctly, the text should explain that squatting leads to conflicts.  The third observation is that neither ICANN nor the IETF has any technical means to prevent squatting.

I think that the Section 3 bullet on .local should explain that the amount of time involved was excessive, but part of the reason was that the process for special-use assignments was being invented.  As a result, .onion took much less time.

I think that theSection 3  bullet that references should be reworded.  The information in the Ed Note probably does not belong in the Informational RFC.

I think that Section 4.2.5 should include a reference to the SSAC document.  I know it is also referenced elsewhere.

And a few Nits…

The “SUDN” and “SUTLDN” acronyms are defined, but they are not used very often.  I wonder is spelling it out in every case would be more clear.

In Section 3, there is bad formatting and duplicate informations in the bullet about ICANN Reserved Names.  I suggest:
s/(see [SDO-ICANN-DAG]Section, Reserved Names )/(seeSection [SDO-ICANN-DAG])

In Section 4.1.1:
s/TOR browser/Tor Browser [TP]/
s/connecting over TOR/connecting over the Tor network/

[TP] =

In Section 4.1.3:
s/Memorandum of Understanding[RFC2860]/Memorandum of Understanding [RFC2860]/