Re: [DNSOP] moving forward on special use names

Edward Lewis <> Mon, 19 September 2016 11:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B86D612B37F for <>; Mon, 19 Sep 2016 04:43:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.517
X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LKU-pyRqXSey for <>; Mon, 19 Sep 2016 04:43:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B877D12B37E for <>; Mon, 19 Sep 2016 04:41:15 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 19 Sep 2016 04:41:13 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1178.000; Mon, 19 Sep 2016 04:41:13 -0700
From: Edward Lewis <>
To: dnsop <>
Thread-Topic: [DNSOP] moving forward on special use names
Thread-Index: AQHSEmq5PLOOIQC0fkupKpc2s4bT6w==
Date: Mon, 19 Sep 2016 11:41:13 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3557115672_272868876"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [DNSOP] moving forward on special use names
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, 19 Sep 2016 11:43:18 -0000

So as not to incur the wrath of Tim (again),

(He knows what I mean.)

On 9/12/16, 16:19, "DNSOP on behalf of Suzanne Woolf" < on behalf of> wrote:

>As we discussed in Berlin, we need to move forward with adopting a problem statement draft for further work on special use domain names. 

>The drafts are:

I've read both, the -03 of the former and -06 of the latter.

Grading them strictly on providing a concise problem statement regarding issues with the Special Use Domain Name registry, "draft-adpkja-" stays more on topic than "draft-tldr".

I had been holding off on replying for a number of reasons.  There's been more than enough words spilled over this already and over a fairly long duration - without much milestone-hitting progress.

Still, as esoteric as this topic has become, I believe that having a Special Use Domain Name registry is important.  I don't want to see it wither away because no one wants to fix it.  It is important to have a means to document the uses of domain names that are not DNS compatible, specifically referring to the difference between the zone administrators of the DNS as described in STD 13 documents and the administrative models implemented via distributed hash tables.

The IETF needs a stronger registry for these names.  The "draft-adpkja-" is more helpful in this regard as it focuses on the registry today and addresses specific shortcomings (even if I'd edit them some - but that's what a WG document is for).  "draft-tldr-" covers a far wider net, covering far ranging issues, winnowing them down to an actionable set would require more time.

For example, "draft-tldr" describes this: "enforce ... authority over any third party who wants to just start using a subset of the namespace".  For a while I was concerned about this use case too, but it is simply something that cannot be treated in documents.  In my notes on the document, I kept repeating - it's not about control or authority but about maximizing interoperability.  I say this as an example of places where "draft-tldr" is trying to describe a problem much more expansive than what "needs solvin'" (at this moment, at least).

Aside - I had other comments on "draft-tldr", including whether it was wise to introduce new terminology in a problems statement document.  In a solutions document, perhaps, but in a problems statement the new terms cause more confusion.  When I came to section 4.2 my note was "what was SUTLIN again?"  This might fall in to the layer of nits but structurally, creating a new vocabulary seems to indicate a solution path is already in mind.