Re: [DNSOP] Strong objection to draft-wkumari-dnsop-alt-tld-04

Warren Kumari <warren@kumari.net> Mon, 16 February 2015 00:00 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 698541A039A for <dnsop@ietfa.amsl.com>; Sun, 15 Feb 2015 16:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.078
X-Spam-Level:
X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Jptsdb8c7CKq for <dnsop@ietfa.amsl.com>; Sun, 15 Feb 2015 16:00:27 -0800 (PST)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33C21A0362 for <dnsop@ietf.org>; Sun, 15 Feb 2015 16:00:26 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id w55so26372747wes.5 for <dnsop@ietf.org>; Sun, 15 Feb 2015 16:00:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jJV4mBtBPvzZt/DUrGqmehOOL75oj4Xp3gStgs8Ld7I=; b=lRGYQ2DpT7Mj8zdOI3Z8YmtVEOyqDnLtliGCkeZjFrM04jZ0mGfjrZkDszaYA7GOAp 8JaHt1P4zIAFsyXlEKvt/JzUktUYCVrK2oylH33tp7XFKRhrYn0ZRg2U0/jMx0/fCMol 3vBXxVYD3dX90XcBzoXupUVayD8a18QTTvDeWIoPwfslujLgHU53kFv/Z6p4zT/3RGN8 MxcjrYkMA+vc7DdC08af7YIqJ4LgLAEpxyAk6Fcg9CgvJt8qHh1qFVCG2xFDXvYY4/Jf d//+ymZBvGNQvDfAra9WtVMa5qtT0QbCWE6FvZ2Pqe5OS2QTSNitZjRkboXyR9G6SOaL aZCQ==
X-Gm-Message-State: ALoCoQmC0yNsCJMiAf5940OfE3WSKwNJLk6IaX1YQMIV/N/Osho6d/wiTcw7BpY4UohLwYNsd6kt
MIME-Version: 1.0
X-Received: by 10.194.84.176 with SMTP id a16mr43269273wjz.113.1424044824979; Sun, 15 Feb 2015 16:00:24 -0800 (PST)
Received: by 10.194.158.229 with HTTP; Sun, 15 Feb 2015 16:00:24 -0800 (PST)
In-Reply-To: <20150214165630.GB3616@sources.org>
References: <20150212063638.GD6950@mx1.yitter.info> <20150214165630.GB3616@sources.org>
Date: Mon, 16 Feb 2015 08:00:24 +0800
Message-ID: <CAHw9_iKS1JotXn3OUQk8wBfHDjYnicmsimK-6kVVWZnASLxa=Q@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/t7T7dW9usXR29Np4NgNxsLXF2Ls>
Cc: dnsop <dnsop@ietf.org>, Andrew Sullivan <ajs@anvilwalrusden.com>
Subject: Re: [DNSOP] Strong objection to draft-wkumari-dnsop-alt-tld-04
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, 16 Feb 2015 00:00:33 -0000

On Sun, Feb 15, 2015 at 12:56 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> On Thu, Feb 12, 2015 at 02:36:39PM +0800,
>  Andrew Sullivan <ajs@anvilwalrusden.com> wrote
>  a message of 20 lines which said:
>
>> Warren and I have prepared draft-wkumari-dnsop-alt-tld-04.  We'd
>> appreciate feedback.  If there isn't any, maybe that's a sign that
>> we could just publish it and thereby create a special TLD in which
>> people could set up their various special use special names?
>
> This is a bad idea and should be dropped completely.
>
> The main reason why I say so is that we already have RFC 6761 and it
> exists precisely to register special names. I was not a big fan of
> this RFC (that's an understatement) but, now that it exists, I see no
> reason to obsolete it after only two years of existence and only one
> TLD, an Apple's one, registered.
>  Worse, draft-wkumari-dnsop-alt-tld-04
> misrepresents RFC 6761 by saying things like "Special Use TLDs which
> should only be used in exceptional circumstances" while it is never
> written in RFC 6761.

For those following along at home, this comes from the introduction:

"This document provides a solution which should be used in most cases
  instead of [RFC6761].  RFC6761 specifies Special Use TLDs which
  should only be used in exceptional circumstances."

This document is not intended to, and does not, obsolete RFC 6761:

draft-wkumari-dnsop-alt-tld wkumari$ grep -i 'Obsoletes' *
draft-wkumari-dnsop-alt-tld wkumari$

It is trying to provide guidance on when RFC6761 is appropriate and
when this solution should be used instead.
The second sentence was not intended to sound like a quote from
RFC6761, but it could be worded better.

How about:
"This document provides a solution that may be more appropriate than
[RFC6761] in many cases"?


>
> Other reasons:
>
> * existing code will not be modified and the names in
> draft-grothoff-iesg-special-use-p2p-names will have to be considered
> anyway. So, .ALT adds work for dnsop / the IESG without addressing the
> existing requests (.ONION, .GNU, .IP2P, etc).

Yup. This does not address the existing requests - it's neither my
place, nor intent to do so. I happen to think that some of the
existing requests have merit, but that's not relevant...
This document is intended to cut down on the number of future
requests, and provided guidance to folk who are developing alternate
namespaces.
As we can see from the ICANN new gTLD process (1930 applications,
~$185,000 USD each[0]) people have decided that TLDs (and probably
things that act like TLDs) have value.
I'm quite sure we will see a large increase in people using things
that look and act like TLDs.
This proposal provides a place for people who want to use things that
kinda act like the DNS, without having the names leak into the DNS
(possibly colliding with names in the global DNS, and also potentially
leaking private info, like the names being looked up)

>
> * the draft is confused in terminology between "domain name" and "DNS
> name". There is no such thing as a "DNS name". Domain names can be
> looked up in the DNS but they are used in many different contexts and
> can be resolved by several protocols. If someone sets up a RDAP server
> for Namecoin, names in .BIT or .COM will use the same protocol for
> information retrieval.
>
> * the draft uses terms like "pseudo-TLD" which are uselessy
> deprecative.

Can you suggest a better term (noting that this term is used in  both
RFC6761 and draft-grothoff-iesg-special-use-p2p-names-04)?
They are things that look like TLDs when leaking into the DNS context,
but are not actually TLDs.

This seems to be a very common term, and was not intended to be
perjorative, see for example:
RFC6761 - Special-Use Domain Names
(https://tools.ietf.org/html/rfc6761)  Section 1:
"This is typically done by stating that any fully qualified domain
name ending in a certain suffix (i.e., falling within a specified
parent pseudo-domain) will receive the special behaviour. "

draft-grothoff-iesg-special-use-p2p-names-04, Section 3 (Terminology
and Conventions Used in This Document):
"The abbreviation "pTLD" is used in this document to mean a pseudo
Top-Level Domain, i.e., a Special-Use Domain Name per [RFC6761]
reserved to P2P Systems in this document."

RFC1429 - Listserv Distribute Protocol, Section 3.3:
"You can use the pseudo-domain ".BITNET" for BITNET recipients: it is
always supported within DISTRIBUTE requests."

RFC1849 -  "Son of 1036": News Article Format and Transmission (Historic):
"The pseudo-domain ".uucp" MAY be used for hosts registered in the
UUCP maps ...."

'Measuring the Leakage of Onion at the Root “A measurement of Tor’s
.onion pseudo-top-level domain in the global domain name system”' -
Matthew Thomas and Aziz Mohaisen.
https://www.petsymposium.org/2014/papers/Thomas.pdf


>
> * .ALT claims to be registered under the RFC 6761 framework but the
> draft ignores the requirments of its section 5.

Yup, good catch -- we have not filled in the "form" in RFC6761. This
was one of those things that we kept meaning to get to, but kept
putting off... and then completely forgot about...


W
[0]: Yup, not all were approved, some were withdrawn, some may have
qualified for hardship reductions, this is only application fees,
doesn't count a: auctions, b: legal, c: operations, d: marketing, e:
legal, etc. Whatever the case, lots of folk have decided that there's
gold in them thar hills...



>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf