Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

<jonne.soininen@broadcom.com> Tue, 04 February 2014 01:45 UTC

Return-Path: <jonne.soininen@broadcom.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 203001A02F6 for <dnsop@ietfa.amsl.com>; Mon, 3 Feb 2014 17:45:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 lts2xtt1RDVz for <dnsop@ietfa.amsl.com>; Mon, 3 Feb 2014 17:45:14 -0800 (PST)
Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.109]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB1C1A02F3 for <dnsop@ietf.org>; Mon, 3 Feb 2014 17:45:14 -0800 (PST)
Received: from [193.109.254.147:28996] by server-5.bemta-14.messagelabs.com id FE/B4-16688-92640F25; Tue, 04 Feb 2014 01:45:13 +0000
X-Env-Sender: jonne.soininen@broadcom.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1391478312!1773254!1
X-Originating-IP: [213.174.82.10]
X-StarScan-Received:
X-StarScan-Version: 6.9.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10553 invoked from network); 4 Feb 2014 01:45:13 -0000
Received: from renexfe01.roe2.renesasmobile.com (HELO renexfe01.roe2.renesasmobile.com) (213.174.82.10) by server-10.tower-27.messagelabs.com with AES128-SHA encrypted SMTP; 4 Feb 2014 01:45:13 -0000
Received: from RENEXMB01.roe2.renesasmobile.com ([fe80::e58a:2b9f:54fe:ff5]) by renexfe01.roe2.renesasmobile.com ([fe80::ec94:bbb3:68e:a94a%18]) with mapi id 14.03.0174.001; Tue, 4 Feb 2014 03:45:12 +0200
From: jonne.soininen@broadcom.com
To: ajs@anvilwalrusden.com, dnsop@ietf.org
Thread-Topic: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Thread-Index: AQHPIUeNwYLSV6MX4ki2zpkW9UfcIZqkUumA
Date: Tue, 04 Feb 2014 01:45:11 +0000
Message-ID: <CF160FB8.1983E7%jonne.soininen@renesasmobile.com>
References: <20140130004530.C660CE086E0@rock.dv.isc.org> <20140203151958.GA1673@nic.fr> <6BE00F1A-1F8D-4B30-A5C7-10E7466109C2@vpnc.org> <ACF06352-98E5-4368-A8C9-5AB50783C2D3@hopcount.ca> <20140203212333.1259EE44493@rock.dv.isc.org> <CF15D98C.197C0B%jonne.soininen@renesasmobile.com> <CAKr6gn1dpWz3LP9bpA2JebRDSN7GeOW65+Q1tW_dv=9KzgZaCQ@mail.gmail.com> <A6D7CE2E-BF9C-4077-A571-0C455E5DAE1F@nominum.com> <CAKr6gn08xayJCK_GtGNeYbet6tD=GwPJoSYL3tbRXomfxckHWA@mail.gmail.com> <ED2AE016-766D-41DE-A428-DEC49A350E8C@nominum.com> <20140204012148.GE16180@mx1.yitter.info>
In-Reply-To: <20140204012148.GE16180@mx1.yitter.info>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.22.172]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9E06B2050B99F249A1ED13C9F92FABC2@renesasmobile.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-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: Tue, 04 Feb 2014 01:45:19 -0000

Hi Andrew,


On 2/4/14 3:21 AM, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote:

>On Mon, Feb 03, 2014 at 08:08:59PM -0500, Ted Lemon wrote:
>> 
>> purely on the basis that some of us don't like what they did.  We
>> need a better reason than that, and thus far none has been stated.
>
>In the particular case of .onion, I'm not sure I agree none has been
>stated.  But let me try again:
>
>    If you want to use a name in DNS protocol slots, then you need a DNS
>    name.  You didn't get a DNS name, and instead you used a label
>    that wasn't under your control.  That's been against the rules in the
>    DNS since forever.  Now you want to short-circuit the allocation
>    mechanism.  But we have an allocation mechanism for this.  In the
>    normal case, you apply to ICANN.  In an unusual case where the
>    protocol depends on this, then you can use this special-use
>    registry.  So you need to show that your protocol needs to depend
>    on this special-use label, and then we can register it under the
>    special use mechanism.  Otherwise go to ICANN.

In addition, I would say that perhaps the current rules are targeted
towards DNS (or extensions of DNS as mDNS could be considered). These new
protocols are something else. They are not DNS and not even specified in
the IETF. They have taken a design choice where they look like DNS and
therefore, may clash with the DNS namespace. The aspect of reserve these
or you'll break the Internet (in some definition of break) isn't really
valid. It is more that you interfere with the functionality of these
protocols, which is a different magnitude of a problem. Perhaps, it is a
different problem all together.

>
>What we ought to be arguing about, in effect, is precisely why this
>needs a special-names registration.  Now, _maybe_ there is an argument
>that this is a DNS-looking series of labels but it never goes into the
>DNS namespace (that's what I've heard once).  In that case, there
>might be an argument.  ("Put this in the default local zones, always
>NXDOMAIN, because we want to protect the DNS.")  Maybe the argument is
>instead that sometimes these names are handed to DNS resolvers and are
>supposed to resolve.  In _that_ case, it seems to me that the "this is
>a DNS name" consideration is also pretty high.  I'm unsure we've had
>clear and consistent arguments about this for each of the cases.

Right. From there comes the question that if this is a way to work around
the process we have in the Internet now - you want a TLD you go to ICANN.
Regardless of what people think of that process, this is the process we
have created already a long time ago and it has been operational since the
beginning of ICANN. There is no other process to get TLDs.
 
>
>In the chapin draft, the argument is different, and it appears to be
>purely a local-resolution-only one -- that is, always "protection of
>the DNS" because of de facto resolution and security decisions
>deployed on the Net.  I haven't read it closely enough to decide
>whether this is true for every label in the list.

Completely agree. The Chapin draft is trying to protect the Internet by
reserving names that for various reasons have collisions in the Internet.
It would be nice to remove these collisions, but it seems to be currently
impossible. So, this is a way to deal with a real problem in the Internet
we have today and avoid that these names would be delegated and cause
breakage in the Internet.

I also believe these two cases should be considered very separately.

Cheers,

Jonne.
>
>Best,
>
>A
>
>-- 
>Andrew Sullivan
>ajs@anvilwalrusden.com
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop