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

Ted Lemon <ted.lemon@nominum.com> Mon, 02 December 2013 18:13 UTC

Return-Path: <Ted.Lemon@nominum.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 AAA151AD9AB for <dnsop@ietfa.amsl.com>; Mon, 2 Dec 2013 10:13:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 ePil1W2gUPaj for <dnsop@ietfa.amsl.com>; Mon, 2 Dec 2013 10:13:08 -0800 (PST)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id F374D1AD959 for <dnsop@ietf.org>; Mon, 2 Dec 2013 10:13:07 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUpzNsQFxRLNdRmjlLuRZlV5FHKsP6d0b@postini.com; Mon, 02 Dec 2013 10:13:06 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A5C111B82C5 for <dnsop@ietf.org>; Mon, 2 Dec 2013 10:13:05 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 9C474190043; Mon, 2 Dec 2013 10:13:05 -0800 (PST)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 10:13:05 -0800
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <05150DF858624B94BA70932453320462@hopcount.ca>
Date: Mon, 02 Dec 2013 13:13:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <838B95A5-A545-4E3E-A3D1-FCC5E58B6F51@nominum.com>
References: <20131201164841.GB12135@sources.org> <BF87877A-8989-4AA4-9ED1-52C82E1BC538@nominum.com> <alpine.LFD.2.10.1312011206480.12923@bofh.nohats.ca> <20131202151651.GD16808@mx1.yitter.info> <D5954219-E22D-44C4-9DE9-3DCA77545264@nominum.com> <E1954338A5D3418BBA8594A8330C7BCD@hopcount.ca> <1132353B-91FC-4133-9B0B-F4A00A8A2A66@nominum.com> <05150DF858624B94BA70932453320462@hopcount.ca>
To: Joe Abley <jabley@hopcount.ca>
X-Mailer: Apple Mail (2.1822)
X-Originating-IP: [192.168.1.10]
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: Mon, 02 Dec 2013 18:13:10 -0000

On Dec 2, 2013, at 12:58 PM, Joe Abley <jabley@hopcount.ca> wrote:
>> This seems like a non-sequitur, since RFC 5855 refers to a function that RFC 3172 specifically mentions.
> 
> I was perhaps being a little opaque; RFC 5855 specifies names under .ARPA for hosts (A.IN-ADDR-SERVERS.ARPA, etc.) This seems to be in contradiction to the text you quoted.

Hm, okay, but that seems more like infrastructure than it does like a name.   Every domain name is a name in that sense.

>>> I think you're sharing personal opinion rather than citing fact ("make sense"). The .local convention happened to be adopted by Apple for use in a DNS-like protocol, and was documented (and the IN-class top-level label reserved) later. They could equally well have adopted .local.arpa or .local.apple.com (http://local.apple.com).
>> 
>> So, in what sense is MDNS "internet infrastrucure?"
> 
> It's a protocol that is used on the Internet. It's a protocol that is used to locate and obtain addresses for hosts connected to the Internet. I appreciate that it has a restricted scope, but in practical terms so does everything.

Right, but a protocol is not infrastructure.   The name servers that serve IN-ADDR.ARPA are infrastructure.   IN-ADDR.ARPA is infrastructure.   MDNS is a protocol for discovering hosts on the local wire.   It isn't "internet" and it isn't "infrastructure"—it exists to deal with a lack of infrastructure.

>>>> The other proposed special uses are similar. Putting them under .arpa might be _expedient_, because it avoids the whole change control question, but that's pretty much the only way I can think of that it makes sense.
>>> 
>>> It doesn't avoid the whole change control question -- it just reduces the change control to one with a single, uncontentious decision point (the IAB). By contrast, the business of identifying reserved strings (and enforcing their non-delegation for other purposes) in the root zone is fraught with administrative ambiguity.
>> 
>> It's not at all clear to me that this is an issue, and if it is, we should figure that out.
> 
> I don't disagree. It's not clear to me either; I'm just conscious of the fact that perspectives can vary depending on whether you're used to looking at things from an IETF perspective or an ICANN perspective. I have been somewhat familiar with both, and I'm confused. :-)

Whereas I know almost nothing of the ICANN perspective, so I feel like I am navigating a maze in the dark!

>> I would like to think that ICANN understands that there is a change control conflict here, and is willing to work with us to make sure that we don't step on each other's toes. Clearly it's incumbent upon the IETF not to be frivolous in the use of RFC 6761. But I have not heard from anyone that the IETF should not ever use RFC 6761, and that seems to be the position you are advocating at the moment.
> 
> I can see how I might have given that impression, but it wasn't intentional. 
> 
> I have some personal dissatisfaction with the approach taken in 6761 (I think there was an opportunity to unify a range of technical policy and collapse a number of registries that give the appearance of doing the same thing in different places, and I think its a shame that the opportunity was not taken) but I have no objection in principle to the idea that some right-most labels could/should be reserved for use by the IETF.
> 
> The reason my knee is jerking is that I think in general it's a mistake to assume that a unique top-level label is the only practical recourse for protocol designers looking for stable, dedicated namespaces. There are lots of other options, several of which mentioned in this thread, and one size does not fit all.

I think that's a valid point.  However, the proposal has been made to register some existing uses of special-use TLDs, so it's not the case that we are dealing with a blank sheet of paper here.   The number of special-use domains being discussed is fairly small, and they are names that likely would not see heavy conflict with proposed ICANN uses of TLDs.

So given that RFC 6761 does in fact represent IETF consensus at the moment, I think it's reasonable to consider allocating these names.   If ICANN comes back and says "we really don't think you should do this because of X," I think we ought to take that seriously.

But we are not there now, and I don't know that we will get there.   So I don't think it's a particularly useful point to raise in terms of _the IETF's_ consideration of this proposal.