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

Warren Kumari <warren@kumari.net> Wed, 04 December 2013 21:53 UTC

Return-Path: <warren@kumari.net>
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 63E591AD948 for <dnsop@ietfa.amsl.com>; Wed, 4 Dec 2013 13:53:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no
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 EJieTjWsBLaE for <dnsop@ietfa.amsl.com>; Wed, 4 Dec 2013 13:53:12 -0800 (PST)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082AE1AD8F5 for <dnsop@ietf.org>; Wed, 4 Dec 2013 13:53:11 -0800 (PST)
Received: from [192.168.1.153] (unknown [66.84.81.107]) by vimes.kumari.net (Postfix) with ESMTPSA id 7088F1B405FA; Wed, 4 Dec 2013 16:53:08 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <1DA98CD6C61144088EA480D71E51AF3D@hopcount.ca>
Date: Wed, 04 Dec 2013 16:53:07 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <6CD1000E-CEE4-4744-B7F6-8EBBB9946EB7@kumari.net>
References: <BF87877A-8989-4AA4-9ED1-52C82E1BC538@nominum.com> <alpine.LFD.2.10.1312011206480.12923@bofh.nohats.ca> <20131202151651.GD16808@mx1.yitter.info> <A12FD3E0-58F6-4490-877F-A9C59405F717@vpnc.org> <6DBBC8339C394DBDAE4FE1F764E02A8D@hopcount.ca> <20131203170825.GA17211@nic.fr> <21D03162-81D1-494A-89A9-41BE89D28A0E@nominum.com> <BB7627E9-8D50-48E5-B809-64AE4D574271@virtualized.org> <20131203221006.GB5689@sources.org> <D3E446D0-F9ED-4671-A1C2-29A15D3DE010@virtualized.org> <20131204094449.GA5492@nic.fr> <9650BF6D-727B-4EF3-B357-7E4E2FDDE0AF@virtualized.org> <2614C613-1399-429D-856B-5E2C18DCA7A6@kumari.net> <1DA98CD6C61144088EA480D71E51AF3D@hopcount.ca>
To: Joe Abley <jabley@hopcount.ca>
X-Mailer: Apple Mail (2.1510)
Cc: dnsop WG <dnsop@ietf.org>, David Conrad <drc@virtualized.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, 04 Dec 2013 21:53:13 -0000

On Dec 4, 2013, at 2:59 PM, Joe Abley <jabley@hopcount.ca> wrote:

> 
> 
> On Wednesday 4 December 2013 at 14:40, Warren Kumari wrote:
> 
>> I really like .alt -- it makes it clear that this is an alternate namespace type thing, mirrors the usenet alt convention, etc.
>> .p2p seems less descriptive, and not all alternate things are peer to peer.
> 
> I think it's pertinent to characterise what you mean by .alt (or .whatever). Do you mean adding .alt to the reserved list so that it is not used? Or do you mean it should be delegated somewhere? If so, that can of worms will need to be opened at some point, and pandora's box of root zone management needs to be opened.

Hmm...  Good question…. <runs away>

Actually I think that "both" is the right answer here, although I understand that that is not really possible. Ideally it should be marked as "Reserved, see RFC xxx" and *also* delegated to AS112. Simply reserving it so that it is not used on the big-I internet won't actually stop queries from leaking out and hitting the root. 

I am aware of the can of worms^W snakes, and understand that opening that can / box is not to be undertaken lightly.
So, I'd be OK with .alt being "Reserved" in some RFC, and that RFC also suggesting that this be delegated to AS112. The actual action could be taken later.

Yes, I fully get the irony of me saying "Don't poke the bear without reason" and then doing so. Oh well.


>> Whatever the case, .<new label> could be delegated to AS112 -- if you don't have the special source that uses the alternate namespace this will at least
>> cut down on the excess "junk" queries hitting the root.
> 
> See above regarding the Box, but also bear in mind that we're moving AS112 towards DNAME redirection rather than delegation.
> 
> There was at least one study commissioned by ICANN on the prudence of provisioning DNAME RRs in the root zone that concluded that there was no obvious danger, but remember that any novel RRTypes in the root zone are going to need implementation time in the systems and processes involved in root zone management, and such changes have proven in the past to be neither quick nor easy.

Yup. See the "Reserve in an RFC. Delegate to AS112 later, in another draft, written by someone else" cowardly proposal above :-)

> 
> There are also many non-technical communities that have demonstrated the effectiveness of their brakes when it comes to making changes to root zone provisioning, no matter how benign the change might seem to a technical audience.

You reckon?

> 
> Note that I'm not commenting on any general or specific idea, just pointing out that there are dragons every which way you look if your proposal involves the root zone.

Yup. Dragons and monsters and big hairy things with sharp, pointy teeth…

W

> 
> 
> Joe
> 
> 

-- 
Militant Agnostic -- I don't know and you don't either...