Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

Warren Kumari <warren@kumari.net> Tue, 27 September 2016 02:37 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DED12B3CD for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 19:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 cxEUjyS0LvSm for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 19:37:49 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 82C5712B0E8 for <dnsop@ietf.org>; Mon, 26 Sep 2016 19:37:49 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id z190so466947qkc.3 for <dnsop@ietf.org>; Mon, 26 Sep 2016 19:37:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EZ96wjQDPELtRzd/16EhrwzT47MhrzrTKThlfuKZrkc=; b=sjakiCPNTCqSy4qL4fSv4fcbkGe36XLRKXdIFkyXPFODZbe6bAlm7PcnNhvVwk0hLD g+AFBAGM6LBUo6oczByPd4ShKpZrCq5SEfKgHu0fjZLE3D5e/uDfMXaCP20deBZMg1N/ ogIB/M6M+mRqoJP66IB27DoOSSzeEvwUnpnLllwgyHsIIMu/6sBMi8pBin5uJ2cv4+SS uR811+afZCLf48Ju7XueHIu0dWFkExITiJgiKA5cBraECPhV3YOCSY/fMIkhrYgbL9h1 MxwMywD4NkSTcnz+ATpsCwpcQCNlQnCejHTRqoJjmBv28ig41/9CjICJFzVSLx8A7qt0 CKxg==
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:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EZ96wjQDPELtRzd/16EhrwzT47MhrzrTKThlfuKZrkc=; b=jbJwCZvdISrbstSe3gdGjVXpJ+27JOV1oqmCIYj35SOvgwyauj7GvrjhrJa2cMrmQN BnIKlwco/OsbtJWg8SDxgjznL5CHvD4B2lQjL6GGbkHvvsPzGfSqCgO5YnozVkFpOJmj S9rSM7HYL89BiYbRvwr4xa9op+HhfodK/RB1Ea2Da7Kn6TwOZxcwXsDwb0mx4NdS390M W67F7FZngxSwXkDXDSITU1tcC2JdHrPpI1Yzfn1kRkcHoMifYmU2YqQmtbTqgCU4B88c LlLGilVj8nkqGJWXh+I9mgf1ysCsIKBeX+97fPbkLQHtHVBHWMNz2eB5gyknNydZNeNB HOqA==
X-Gm-Message-State: AA6/9RljRHEj0R5nmby1lbf3QkcsY3ngJxAAFDbTaOMUesv++AkyCagOMaXIQEmaizYDMIBU+EB3qmMnS/IgaU5r
X-Received: by 10.55.175.134 with SMTP id y128mr23949356qke.134.1474943868569; Mon, 26 Sep 2016 19:37:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Mon, 26 Sep 2016 19:37:18 -0700 (PDT)
In-Reply-To: <6ce7ea83-5ccc-aeda-d1e4-f5e5d1ccbf53@gnu.org>
References: <147368142586.14471.16897934069436083953.idtracker@ietfa.amsl.com> <6ce7ea83-5ccc-aeda-d1e4-f5e5d1ccbf53@gnu.org>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 26 Sep 2016 22:37:18 -0400
Message-ID: <CAHw9_iKtmVh8xvwVydWUs-g9t_JiKAF7Frdx_iieSEOvQFHJ1w@mail.gmail.com>
To: hellekin <hellekin@gnu.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LFiW0RzMYvZY1sWJ8YFeeqCpIGs>
Cc: dnsop <dnsop@ietf.org>, "draft-grothoff-iesg-special-use-p2p-names@tools.ietf.org" <draft-grothoff-iesg-special-use-p2p-names@tools.ietf.org>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 27 Sep 2016 02:37:52 -0000

On Sun, Sep 25, 2016 at 1:48 PM, hellekin <hellekin@gnu.org> wrote:
> On 09/12/2016 11:57 AM, internet-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Domain Name System Operations of the IETF.
>>
>>         Title           : The ALT Special Use Top Level Domain
>>         Authors         : Warren Kumari
>>                           Andrew Sullivan
>>       Filename        : draft-ietf-dnsop-alt-tld-05.txt
>>       Pages           : 10
>>       Date            : 2016-09-12
>>
>> Abstract:
>>    This document reserves a string (ALT) to be used as a TLD label in
>>    non-DNS contexts or for names that have no meaning in a global
>>    context.  It also provides advice and guidance to developers
>>    developing alternate namespaces.
>>
>
> Finally I read this draft after I realized the presence of this "or" in
> "... in non-DNS contexts *or* for names that have no meaning in a global
> context."
>
> I must apologize for staying on
> https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-04 and not
> reading anymore of this draft, as it was explicitly stating the following:
>
> "The ALT label MAY be used in any domain name as a pseudo-TLD to signify
> that this is an alternate (non-DNS) namespace."
>
> And:
>
> "Currently deployed projects and protocols that are using pseudo-TLDs
> (for example, the ".onion" pseudo-TLD (and other labels in
> [I-D.grothoff-iesg-special-use-p2p-names]) are encouraged but not
> required to move under the ALT TLD.  Rather, the ALT TLD is being
> reserved so that future projects of a similar nature have a designated
> place to create alternate resolution namespaces that will not conflict
> with the regular DNS context."
>
> Yet, this explicit recognition of existing name requests for P2P systems
> was removed from the next draft on, and is obviously absent from the
> current draft-ietf-dnsop-alt-tld-05.txt, which implicitly declares the
> special-use names of P2P systems as falling under .ALT.  Since this
> draft is reserving the .ALT TLD using RFC6761, and there's an ongoing
> discussion about this RFC to figure out a proper way to use it, update
> it, or dismiss it, I find the situation unacceptable.  Please correct me
> if I'm wrong, but it really seems to me that this is the case, and that
> the .ALT draft, which wasn't meant to threaten the history of the P2P
> names, indeed became a way to easily dismiss any further discussion
> about them.

This document is not intending to stop discussion of the P2P names. In
my opinion, discussions on those is orthagonal to these. If .ALT is
created and any of them are able to AND would like to, they can move
under .ALT. One of the main things that we seem to have learned from
the Special Use Names discussion is that we are not the DNS police.
There is nothing that we can do to prevent somebody from "squatting"
on a string. The only thing we can do is provide a sandbox for those
who would like to use it, which will not collide with delegated TLDs.
The .ALT draft is still parked and so we are not making significant
changes to it at the moment. Once it is unparked, we are happy to
incorporate the working group's desires and text. In deference to the
chairs, let's not open these discussions at the moment. (We believe
this will be unparked soon.)

It's been a really long time, but IIRC, we removed the mention of the
P2P names because we thought you wanted that -- somewhere around this
whole discussion:
https://www.ietf.org/mail-archive/web/dnsop/current/msg13338.html

My opinion really doesn't matter, but I happen to think that, at this
point, we should evaluate the requested P2P names according to RFC
6761  -- you followed the process in effect *at the time*, and jumped
through many hoops. The process is far from perfect (see
draft-tldr-sutld-ps) but that *was* the process at that point, and so
your drafts should (IMO) be evaluated against that. If the IETF had
been able to quickly and clearly come to consensus that the process
was broken, and what to do to fix it, I might feel differently, but
changing the rules retroactively feels unfair.

Interestingly enough, just above that mail, Stephane also objected to
"pseudo-TLD", but we asked the WG for a better term and (IIRC), didn't
get any better suggestions:
"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
"



>
> Regards,
>
> ==
> hk
>
> _______________________________________________
> 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