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

Suzanne Woolf <suzworldwide@gmail.com> Wed, 18 December 2013 15:58 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 E11BC1AE412 for <dnsop@ietfa.amsl.com>; Wed, 18 Dec 2013 07:58:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 5yksImPklZAo for <dnsop@ietfa.amsl.com>; Wed, 18 Dec 2013 07:58:19 -0800 (PST)
Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8639C1ADFFC for <dnsop@ietf.org>; Wed, 18 Dec 2013 07:58:19 -0800 (PST)
Received: by mail-qe0-f41.google.com with SMTP id gh4so6659547qeb.14 for <dnsop@ietf.org>; Wed, 18 Dec 2013 07:58:17 -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 :content-transfer-encoding:message-id:references:to; bh=FyKQAfzHM6srjuHcTlC7TcGR+lAOYi2x374fq466ViA=; b=xtwjs4evWusMCfdtxRHlJT9cQJDau9kh5ci1ePGEv9c7iFyaQhSzAhb/XKDwteQvww fj4FMhw5LRk5VFOf6m5WDvbt2W+m62XqJYzzBMjuKZCN2kc+hvT0SwBho8wgsijlDC8o o+X8fcBAnYnSoXYUi2fJInXfprzae9LxsyzZw5WFtZYeJ1N56zL3KTU8wxGdLjISzdCN VQd27RZfJKpa770sSGFXsV4oYVrmtKzwZq0IIgpRB7qhdl41Z9gHelcDuV8ZoKvzkaE1 JffsFcUSX1ULSc/ZFb0NNPLfuUDxZmTk5FlPWZES6FL80NJW49FD50bhVA/Ppsz/4kLk xtLg==
X-Received: by 10.49.26.129 with SMTP id l1mr54409993qeg.37.1387382297899; Wed, 18 Dec 2013 07:58:17 -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 lc1sm1318432qeb.5.2013.12.18.07.58.15 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Dec 2013 07:58:15 -0800 (PST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <26E611D3-9BC2-4EF0-B15E-E964523968D7@nominum.com>
Date: Wed, 18 Dec 2013 10:58:16 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <99586F73-961C-4FF4-8C9F-51A958B93545@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> <B5975690-1841-44EA-8443-D4E56126E330@gmail.com> <26E611D3-9BC2-4EF0-B15E-E964523968D7@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: Wed, 18 Dec 2013 15:58:22 -0000

Hi Ted,

Thanks for this, a couple of clarifications inline….

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

> Thanks—this is a very helpful response.   So if I were to condense your response down, I would pull out the following (I'm doing this not to put words in your mouth, but because I'm trying to make sure I don't misrepresent what you've said):
> 
> 1. Although the current proposal doesn't create a clearly bad amount of stress on root servers, a policy of allocating tons of sTLDs might eventually have a substantial impact on the root, simply because of the large number of unanswerable queries that would be emitted from brokenware and not caught by intermediate caches.   So we should be figuring out what, if anything, we can do about that eventuality, should it arise.

Sadly I think this is true….we have to engineer not only to the DNS when it works and people are operating everything properly, but to the DNS when it doesn't and they aren't, at least as far as foreseeing the problems we're buying. As a minor point-- this sounds like a fairly far-fetched hypothetical in your formulation, and I don't regard it as particularly far-fetched.

> 2. You seem to be agreeing with the statement that's been made by a number of folks that if the particular proposed allocations are to happen, the discussion ought to include ICANN, because they have thought about this issue a lot (you didn't actually say this, but it's what I take from your response to my point 2).   And this has the same scaling problems you mentioned in point 1, this time with respect to the thought process about trademarks.

I do think that some discussion with ICANN is called for, although both 6761 and the IAB's MoU with ICANN are silent on the course such a discussion should take. There's an IAB liaison to ICANN's Board which should get involved-- I think I saw a reference in another discussion (the dns-dir message archive) to doing that already, which seems right to me.

The concern over potential controversy takes two forms: 
	* intellectual property and related politics; not just trademark-- see for example the controversy among government and commercial players over .amazon or .wine.
	* we don't know if or when ICANN has additional plans to expand the namespace significantly again. If there are none, many of these risks go away. But otherwise it would be nice to have some idea how the IETF process for picking future special names could limit the risk of a problem over a particular name, and to be sure ICANN was equally intent on avoiding a problem with the special use registry.

Experience in both realms convinces me that everyone is interested in avoiding a problem. But we may need some additional consideration of how exactly to do that.

> 3. Adding a lot of sTLDs really will have a significant impact on stub resolvers (you gave some good examples).

It adds complication. As an operator, this is my primary concern-- not what the names are, but how they're supposed to work.

> 4. Not having clear specifications will exacerbate the problem mentioned in 3, and you don't know whether the current specifications are clear enough (my own experience of them from having gone and looked is that there is probably a lot of the right information, but it's not straightforward to find it, and it's not clear that it's stable in any useful sense).

I've looked briefly at a couple of the underlying documents since I wrote last, agreed on this.

> To respond to your final points:
> 
>> 	* 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.
> 
> Yup.   I think we need to have a better answer than we currently have, and to a point drc made a while back, probably better data than we have now on the current garbage query load on the root.

FWIW there is some good data, not only the L-root public data but the datasets various people used in their analyses of existing namespace collisions between private use names leaked to the root and the current round of new gTLD names applied for with ICANN. Other root servers make various data publicly available; for example, the RIPE NCC regularly publishes per-node data for K-root at http://k.root-servers.org on most popular TLDs queried, including non-valid ones, and on distribution of return codes sent including NXDOMAIN. 

More, and on a more common basis across servers, would be really helpful. There are folks working on this….

> 
>> 	* 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.
> 
> That's pretty much what moved me to start this conversation.   I think it's been a useful conversation, but I don't think we've really got an answer yet.

You and me both :)


best,
Suzanne