Re: [DNSOP] followup and proposed actions: RFC 6761 interim and next steps
Mark Andrews <marka@isc.org> Tue, 26 May 2015 23:55 UTC
Return-Path: <marka@isc.org>
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 CE95F1B332B for <dnsop@ietfa.amsl.com>; Tue, 26 May 2015 16:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.711
X-Spam-Level:
X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 aEzvt4Bsylid for <dnsop@ietfa.amsl.com>; Tue, 26 May 2015 16:55:45 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9C11A9235 for <dnsop@ietf.org>; Tue, 26 May 2015 16:55:43 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 110A5349514; Tue, 26 May 2015 23:55:40 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9A08D160050; Tue, 26 May 2015 23:56:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6777F16008A; Tue, 26 May 2015 23:56:05 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0mv9xAN6nKrb; Tue, 26 May 2015 23:56:05 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id BE258160050; Tue, 26 May 2015 23:56:04 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6EB212F57FC3; Wed, 27 May 2015 09:55:36 +1000 (EST)
To: Francisco Obispo <fobispo@uniregistry.com>
From: Mark Andrews <marka@isc.org>
References: <20150526200703.15413.qmail@ary.lan> <3B05F60A-8865-45B8-A36C-042E0F5CC92C@uniregistry.com>
In-reply-to: Your message of "Tue, 26 May 2015 14:19:33 -0700." <3B05F60A-8865-45B8-A36C-042E0F5CC92C@uniregistry.com>
Date: Wed, 27 May 2015 09:55:35 +1000
Message-Id: <20150526235536.6EB212F57FC3@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/s7SU1FdAoDks35BvQ3ovG0wMCX8>
Cc: dnsop@ietf.org, John Levine <johnl@taugh.com>
Subject: Re: [DNSOP] followup and proposed actions: RFC 6761 interim and next steps
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: Tue, 26 May 2015 23:55:48 -0000
In message <3B05F60A-8865-45B8-A36C-042E0F5CC92C@uniregistry.com>, Francisco O bispo writes: > > On May 26, 2015, at 1:07 PM, John Levine <johnl@taugh.com> wrote: > > > >> I believe the delegation of HOME/CORP/MAIL provides with more benefit > >> than risks, there > >> will be more companies/homes and mail users happy because their names > >> resolve from > >> everywhere, they can validate with DNSSEC, they can opt who can > >> connect to their > >> networks and no longer require domain hacks to get their users to go > >> to the right > >> places. > > > > There are probably tens of thousands of people who have a device with > > the local name PRINTER.HOME. I must be dim, because I cannnot imagine > > any way that any possible set of DNS records in the root or a TLD > > would allow that name to "resolve from everywhere" in a way other than > > perhaps one that sent an enormous amount of people's printouts to one > > printer somewhere. > > > > Could you clarify how it's supposed to work? > > > > I would certainly like to have: obispo.home, be a real FQDN, so I can > name my home devices, printer.obispo.home, etc. In reality it would be printer.obispo72.home or something like that 99.999% of registrants after a year or so. Only those that jump at the very begining would get their family name. .home wouldn't be like .com where you are choosing a name for a business and part of that process is finding something that is unique and that you like in the DNS. You already have a name. And Australia actually has a model for how to link individuals / families / homes into the dns. name.<othername>.id.au id is for individual. <othername> is a meaningless label designed to deal with human name collisions. andrews.wattle.id.au (the master is currently broken) is just as easy for me to remember as andrews.home and has the advantage that lots of other andrewses can get a andrews.something.id.au name and be on a equal footing. wattle.id.au is also a free registry run on a volunteer basis. Basically .home is too high in the heirarchy for this sort of individual / family use. There are too many collisions of names. .home.ctld is also too high which is why a third level was added. Mark > If I go to a hotel around the world and I need to print in my printer at > home, I should be able to do it, I shouldnât be âhackingâ my way around > that. In a v6 world, this is going to be common practice, the fact that > we have limitations on how we use our home networks today does not mean > that those same restrictions will exist in the future. > > Perhaps the approach is (if identified as a problem), to have > printer.home be on a controlled interruption list for a while, so people > can identify and fix their setups. I donât know, but the approach where > we ban the whole TLD from ever existing because of few that misconfigured > their naming, doesnât seem reasonable to me. (few compared to the rest of > the world who will be connected in the future). > > Should we also add a .BELKIN TLD?, there are tons of devices that use it > (to name a few), what if in 10 years someone decides to create .FOOBARBAZ > are we going to add it to the list later?, > > We need a better view/picture of the whole DNS ecosystem, we should not > be making assertions based on a 24 hour sample of 1 day of root server > traffic, let put more effort into strategy for the long term and not be > so tactical about these specific use cases. > > Regards, > > > Francisco Obispo > CTO - Registry Operations > ____________________________ > > <http://www.uniregistry.com/> > 2161 San Joaquin Hills Road > Newport Beach, CA 92660 > > Office +1 949 706 2300 x4202 > fobispo@uniregistry.link -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- [DNSOP] followup and proposed actions: RFC 6761 i… Suzanne Woolf
- Re: [DNSOP] followup and proposed actions: RFC 67… Tom Ritter
- Re: [DNSOP] followup and proposed actions: RFC 67… Warren Kumari
- Re: [DNSOP] followup and proposed actions: RFC 67… Daniel Kahn Gillmor
- Re: [DNSOP] followup and proposed actions: RFC 67… John Levine
- Re: [DNSOP] followup and proposed actions: RFC 67… Tom Ritter
- Re: [DNSOP] followup and proposed actions: RFC 67… John Levine
- Re: [DNSOP] followup and proposed actions: RFC 67… Lyman Chapin
- Re: [DNSOP] followup and proposed actions: RFC 67… Francisco Obispo
- Re: [DNSOP] followup and proposed actions: RFC 67… John Levine
- Re: [DNSOP] followup and proposed actions: RFC 67… Rubens Kuhl
- Re: [DNSOP] followup and proposed actions: RFC 67… John Levine
- Re: [DNSOP] followup and proposed actions: RFC 67… Francisco Obispo
- Re: [DNSOP] followup and proposed actions: RFC 67… Rubens Kuhl
- Re: [DNSOP] followup and proposed actions: RFC 67… John R Levine
- Re: [DNSOP] followup and proposed actions: RFC 67… Francisco Obispo
- Re: [DNSOP] followup and proposed actions: RFC 67… John R Levine
- Re: [DNSOP] followup and proposed actions: RFC 67… John R Levine
- Re: [DNSOP] followup and proposed actions: RFC 67… Francisco Obispo
- Re: [DNSOP] followup and proposed actions: RFC 67… Paul Vixie
- Re: [DNSOP] followup and proposed actions: RFC 67… Paul Vixie
- Re: [DNSOP] followup and proposed actions: RFC 67… Paul Wouters
- Re: [DNSOP] followup and proposed actions: RFC 67… Paul Vixie
- Re: [DNSOP] followup and proposed actions: RFC 67… Francisco Obispo
- Re: [DNSOP] followup and proposed actions: RFC 67… Mark Andrews
- Re: [DNSOP] followup and proposed actions: RFC 67… Paul Wouters
- [DNSOP] dotless names (was Re: followup and propo… David Conrad
- Re: [DNSOP] followup and proposed actions: RFC 67… Paul Vixie
- Re: [DNSOP] followup and proposed actions: RFC 67… Paul Vixie
- Re: [DNSOP] dotless names (was Re: followup and p… Paul Vixie
- Re: [DNSOP] dotless names (was Re: followup and p… John Levine
- Re: [DNSOP] followup and proposed actions: RFC 67… Lyman Chapin
- Re: [DNSOP] followup and proposed actions: RFC 67… Jim Reid
- Re: [DNSOP] dotless names (was Re: followup and p… Mark Andrews
- Re: [DNSOP] followup and proposed actions: RFC 67… Patrik Fältström
- Re: [DNSOP] followup and proposed actions: RFC 67… Suzanne Woolf
- Re: [DNSOP] followup and proposed actions: RFC 67… Bob Harold
- Re: [DNSOP] followup and proposed actions: RFC 67… John Levine
- Re: [DNSOP] followup and proposed actions: RFC 67… Mark Andrews
- Re: [DNSOP] followup and proposed actions: RFC 67… Lyman Chapin
- Re: [DNSOP] followup and proposed actions: RFC 67… Rubens Kuhl
- Re: [DNSOP] followup and proposed actions: RFC 67… Andrew Sullivan