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

hellekin <hellekin@gnu.org> Tue, 27 September 2016 08:37 UTC

Return-Path: <hellekin@gnu.org>
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 540DD12B036 for <dnsop@ietfa.amsl.com>; Tue, 27 Sep 2016 01:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.237
X-Spam-Level:
X-Spam-Status: No, score=-9.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kGwwdwyDryDg for <dnsop@ietfa.amsl.com>; Tue, 27 Sep 2016 01:37:49 -0700 (PDT)
Received: from eggs.gnu.org (eggs.gnu.org [208.118.235.92]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EAC612B09F for <dnsop@ietf.org>; Tue, 27 Sep 2016 01:37:49 -0700 (PDT)
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <hellekin@gnu.org>) id 1bontD-00018m-KL for dnsop@ietf.org; Tue, 27 Sep 2016 04:37:27 -0400
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59610) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hellekin@gnu.org>) id 1bonsz-00010i-EE; Tue, 27 Sep 2016 04:37:09 -0400
Received: from [128.153.145.125] (port=40154 helo=[0.0.0.0]) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <hellekin@gnu.org>) id 1bonsx-00061G-Gm; Tue, 27 Sep 2016 04:37:08 -0400
To: Warren Kumari <warren@kumari.net>
References: <147368142586.14471.16897934069436083953.idtracker@ietfa.amsl.com> <6ce7ea83-5ccc-aeda-d1e4-f5e5d1ccbf53@gnu.org> <CAHw9_iKtmVh8xvwVydWUs-g9t_JiKAF7Frdx_iieSEOvQFHJ1w@mail.gmail.com>
From: hellekin <hellekin@gnu.org>
X-Enigmail-Draft-Status: N1110
Organization: https://gnu.org/consensus
Message-ID: <f33a6d06-2c17-04fd-d6a7-b73274705c37@gnu.org>
Date: Tue, 27 Sep 2016 08:33:04 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAHw9_iKtmVh8xvwVydWUs-g9t_JiKAF7Frdx_iieSEOvQFHJ1w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eBVL3Swbg5q89ON8-KpV46Qxr5E>
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 08:37:51 -0000

On 09/27/2016 02:37 AM, Warren Kumari wrote:
> 
> 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.
> 

Thank you for your clarification.  Indeed the discussion was long ago
and details slipped from memory.

> 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.
> 

I remember introducing the term 'pseudo-TLD' in the P2P Names draft and
doing a similar research as the one I cut from your message for brevity.
 At the time I thought the Canada Dry effect would work: it looks like
DNS, it tastes like DNS, but it's not DNS, hence 'pseudo'.  But indeed
that can as well bring confusion.

I have no alternate suggestion at this point, but I have one to avoid
talking about "squatting" names: "using names without ICANN sanction".
It may be longer, but it's more accurate, and doesn't conflate a
legitimate but often criminalized practice with a fact of usage that can
stem from many reasons, one of them being the need of humans to name
things. Using names without ICANN sanction also speaks to people who
don't know why it's a problem, and places it in the correct context
where the problem can then be solved.  Except, of course, if that
particular name represents a technical issue ;o)

==
hk