[DNSOP] On squatting and draft-grothoff-iesg-special-use-p2p-names

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 02 January 2014 20:00 UTC

Return-Path: <paul.hoffman@vpnc.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 4D49F1AE167 for <dnsop@ietfa.amsl.com>; Thu, 2 Jan 2014 12:00:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 lqanTvHpYbwd for <dnsop@ietfa.amsl.com>; Thu, 2 Jan 2014 12:00:36 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D99F31AE00C for <dnsop@ietf.org>; Thu, 2 Jan 2014 12:00:22 -0800 (PST)
Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s02K0DEM010136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Jan 2014 13:00:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <52C48A4A.6090303@in.tum.de>
Date: Thu, 2 Jan 2014 12:00:14 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C051985-6E70-463A-9672-02657842754D@vpnc.org>
References: <20131231000412.GV4291@mx1.yitter.info> <52C323CE.3090909@grothoff.org> <20131231234421.GA5732@mx1.yitter.info> <52C48A4A.6090303@in.tum.de>
To: Christian Grothoff <grothoff@in.tum.de>
X-Mailer: Apple Mail (2.1827)
Cc: dnsop <dnsop@ietf.org>
Subject: [DNSOP] On squatting and draft-grothoff-iesg-special-use-p2p-names
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: Thu, 02 Jan 2014 20:00:37 -0000

On Jan 1, 2014, at 1:36 PM, Christian Grothoff <grothoff@in.tum.de> wrote:

> Well, my point is that if you expect everybody to first get an RFC through
> to document everything they are doing, expect squatting.

We do. And squatters should expect that the name that they are using might eventually be legitimately assigned later, possibly to someone whose intentions are quite different from the squatters. This is how the IETF has worked for over 20 years. The purpose of RFC 6761 is not to say "if you start squatting on a TLD, you will be able to later get it reserved". It is to say "if there are legitimate errors in TLD use, those can be dealt with".

It seems that one of the themes of your responses here is "the TLDs are now being used in software and we won't change that software ever". If that is a correct reading, then there really isn't any reason to move forwards on these requests. The folks using the names are squatting, and will continue to do so regardless of the outcome of the application, much less the outcome of ICANN later allocating those TLDs to someone else.

On the other hand, if the software using the currently-squatted TLDs are willing to change the names, there is room for discussion. One possibility for RFC 6761 is that an application can specify a use for a non-allocated TLD, and a random string (short, typeable, but unlikely to be wanted by anyone in the ICANN space) can be generated for that. So, instead of ".bit" (which has high value), ".gp4x7" could be allocated. That gets the community what they want (a string that ICANN is prevented from later allocating) and follows the spirit of RFC 6761.

--Paul Hoffman