Re: [DNSOP] [internet-drafts@ietf.org: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]

Suzanne Woolf <suzworldwide@gmail.com> Thu, 12 December 2013 18:45 UTC

Return-Path: <suzworldwide@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1191AE066 for <dnsop@ietfa.amsl.com>; Thu, 12 Dec 2013 10:45:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aKcAvAOy1_I for <dnsop@ietfa.amsl.com>; Thu, 12 Dec 2013 10:45:31 -0800 (PST)
Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 870DB1ADFA4 for <dnsop@ietf.org>; Thu, 12 Dec 2013 10:45:31 -0800 (PST)
Received: by mail-qa0-f43.google.com with SMTP id ii20so7200qab.2 for <dnsop@ietf.org>; Thu, 12 Dec 2013 10:45:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1z14NMtybTWUCaIivjhhvUItfHjdFjOKyp8eyJWK+tI=; b=aTx2VAGGkIIUxggwbrOcxjYazo5ewTaCEYjqTlcVclwUjK1lKycP0deJ4Z9Sc/w/jp dwfNOL3tR1vN9KnzmWPDQVSgyaRd14jM3R3IdehQVTLyS41jpu4yPcj4e37kVEpUA/bu gGdRV/37c1yhYLAFHaRIJw00fuXULt4uj7vR75BWvAnp9r6z+1YhHRD+XnGPrWEHswyn 40YP+v49+OvuTCVQRGuA1obEia5a7AKbypHvkm1Tt7nzKnY+DCMb8kx42XixFNGrJ4He rbcaq6Rm9QFJ6ohU1kSJji6OAobcSmZCP2a9KlNYV/CZ5Fo/EdcGIyYR43NQHafyxm5K cJHA==
X-Received: by 10.229.249.66 with SMTP id mj2mr8665165qcb.4.1386873925148; Thu, 12 Dec 2013 10:45:25 -0800 (PST)
Received: from [10.0.0.5] (c-24-63-89-87.hsd1.ma.comcast.net. [24.63.89.87]) by mx.google.com with ESMTPSA id z16sm59545762qab.3.2013.12.12.10.45.23 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Dec 2013 10:45:23 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8A5D0DAE-E4F2-47EF-9A17-92F0F6E67796"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <FEC642D5-0DAA-4C2F-9D68-3B41905CAE02@nominum.com>
Date: Thu, 12 Dec 2013 13:45:22 -0500
Message-Id: <B5975690-1841-44EA-8443-D4E56126E330@gmail.com>
References: <529B75A2.10703@appelbaum.net> <529B7E4A.2070600@grothoff.org> <73387529-308B-424D-807C-D41E59B1D5E8@virtualized.org> <52A244EC.5040104@grothoff.org> <37B27FD9-C0BB-4178-84F3-FD6BA6402AFB@virtualized.org> <52A25F03.3070502@grothoff.org> <D259AC50-E055-457F-841E-E72D2D19C53C@virtualized.org> <52A5237E.8050601@grothoff.org> <FA1AB90A-7FA3-48FB-BD30-5C2D141D4104@virtualized.org> <FEC642D5-0DAA-4C2F-9D68-3B41905CAE02@nominum.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
X-Mailer: Apple Mail (2.1510)
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] [internet-drafts@ietf.org: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 18:45:35 -0000

Hi Ted,

I think this is a really helpful question, so I'll attempt to answer it constructively….

I'm also going to suggest a reframing though, because (to start at the end of your note), I think a lot of the fireworks have occurred because we're talking about two different sets of issues here: the specifics of the draft and the special-use names registry (operational and implementation implications of the request and the draft itself) and some broader, systemic issues of architecture and even (shudder!) policy.  Each can be volatile on its own, so mixing them is guaranteed to be :)

The draft itself is obviously a serious attempt at justifying the reservation requested under RFC 6761, and I commend the authors for doing that. I hope they don't take the concerns being raised as unfriendly to their participation here.

("DNS glitterati" I'm not, but I've run a few nameservers and participated in DNS protocol discussions from time to time….)

In order to your points….

On Dec 10, 2013, at 12:26 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

> Can I just point out here that the only real technical points that have been raised in this discussion thus far, at least that I can recall, are that:
> 
> (1) defining sTLDs produces a small (relatively) amount of useless traffic at the root

This is a specific operational issue. I think David Conrad nailed it; my own experience of root name server operation makes it difficult to see this as a problem, with a couple of caveats:
	* scalability comes into play at some point; I'd be fairly nervous about a special-use names registry that was significantly bigger than the "real" DNS root, for example! (see to your question 3 below). Six names is nowhere near a concern from that perspective.
	* The amount of leakage is going to be larger or smaller, and more or less predictable, depending on the clarity of the instructions to implementors on how to avoid it for the protocols using the reserved names. In turn this has scalability implications for how widely used a given name/protocol becomes as well as how many there are. I'm not familiar with those protocols in detail, so I don't know the answer to this question. But if having a reserved name associated with the protocol is expected to support expanded use, it's worth looking at how to make use of the reserved name as simple and foolproof as possible.
	
> (2) defining sTLDs may have trademark implications that the IETF is not competent to address

This is an architectural and policy issue, and isn't inherent in any specific special-use name but comes up as soon as we've admitted that one of the desirable properties of DNS-like namespaces is that they promote the use of names that have some significance to humans. 

Names are controversial. Scope of names doesn’t always travel with them; one of the problems with using things that look like DNS names is that in certain policy realms, people think of DNS names as global, particularly DNS names that look like TLDs. Not all of the controversies about what names are OK in the DNS root are likely to come along with RFC 6761 names, but some will, and the RFC 6761 assertion that such names are “protocol” and therefore strictly “technical” does not end the argument that will ensue.

After some years of experience with DNS protocol and namespace issues, including a front-row seat to the controversies ICANN has been involved in, I understand completely that no one— not ICANN, not vendors like my current employer, not even the IETF— can tell people what to do or what to name things inside their own networks. I understand that there’s no way to force people to use the special use names registry, and no way that reserving or refusing to reserve a name can be relied upon to change anybody’s behavior in the real world, so complaining that an RFC 6761 name reservation encourages or blesses behavior someone doesn’t like is going to be dubious at best. But I’m not the person you need to be concerned about here.

I’m also not arguing that these issues can’t be overcome. I *am* arguing that there’s more to handling them than asserting "these names are for ‘technical' use and only look like DNS names, so none of the issues around ‘real' TLDs apply.” Some don’t (e.g. registry policy, DNSSEC). Some do (“you can’t have $foo in the DNS because it would collide with a reserved name.” “But it’s incredibly valuable as a DNS name and I have the right to use it!”— see the name collision problem we’ve already got, with the accompanying problem of proving something *isn’t* already in use.)

In terms of scalability, it's worth noting that whatever problems we might be "borrowing" from ICANN-space become more likely roughly in proportion to how many names we're talking about and how widely used/visible they're going to be.

> (3) supporting sTLDs in stub resolvers requires changes to stub resolvers

This appears to be the case and is another operations/implementation issue. The expectation appears to be that the stub the application uses will know that a given protocol requires/expects not only that certain names aren't really DNS names, but what special handling to apply instead (five of the six discussed in the draft are supposed to get NXDOMAIN, the sixth appears to require something more complex). 

This expectation is more realistic for an application-specific stub than for a system-specific one. Which architecture it makes more sense to expect an implementor to be trying to build is a judgment for people who know lots more about application  behavior than I do. 

Part of the answer here also goes to scalability. A system-based or general-purpose stub is going to get harder to write, configure, and debug as the list of special names gets longer and the list of special behaviors that have to be coded into it expands. Overall, the complexity of administering namespaces and resolving names grows with the number of special names. Since DNS resolvers and DNS-like namespaces can be pretty complex already, it's again a question of how many of these things do we want or need? in addition to the utility of any given one. 

I suspect there are lots of protocols people are working on now, or will work on in the future, where "Hey, a special-use DNS-like name would help here, let's get one….or several…." will sound like a good idea. Having lots of them may not be such a good idea regardless of the merits of any one in particular.

How useful is useful enough, then? 6761 provides some guidance on this, but leaves lots of room for judgment, which is why we're having this conversation.

> (4) it would be nice to have stable specifications for the proposed sTLDs

I'd go further than "it would be nice," because I happen to think for the reasons above that it shouldn't be too easy to get a special-use  name and it shouldn't be too difficult for the implementor to tell how they should be treated when they do appear-- "it's not a DNS name, so don't worry about it" won't cut it.

Having not reviewed the underlying protocol specifications associated with this draft, I'm not comfortable judging whether they are strong enough.
> 
> I assume that there is some reason for the strong negative reaction some DNS glitterati have expressed towards this proposal, but whatever that reason is has not yet been expressed.   If you have an inkling of what that reason might be, and it is not simply a strong feeling based on history, a feeling of dislike for one of the proposed name resolution protocols, or a concern about how someone might react to the IESG taking action on this, I would greatly appreciate it if you could express that reason.

My reasons:
	* I'm not convinced the current draft is clear enough on the operational specifics of how an implementor should treat the requested names, or how the overall DNS system will manifest leakage or other mishandling of these names. This is operational and probably fixable.
	* I'm not convinced we've thought through how to manage "technical"/infrastructure DNS-like names in a world where those have policy implications we may not like but can't reasonably ignore. This is a matter of architecture and policy and can really only be resolved by discussion and judgment.

Hope this helps,
Suzanne