Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

hellekin <hellekin@gnu.org> Thu, 21 May 2015 19:32 UTC

Return-Path: <hellekin@gnu.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 22FA91A88D2 for <dnsop@ietfa.amsl.com>; Thu, 21 May 2015 12:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level:
X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 HcS6zPcFSk6W for <dnsop@ietfa.amsl.com>; Thu, 21 May 2015 12:32:28 -0700 (PDT)
Received: from fencepost.gnu.org (fencepost.gnu.org [IPv6:2001:4830:134:3::e]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C381A889D for <dnsop@ietf.org>; Thu, 21 May 2015 12:32:26 -0700 (PDT)
Received: from ol168-138.fibertel.com.ar ([24.232.138.168]:43332 helo=raiz.hellekin.gnu) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from <hellekin@gnu.org>) id 1YvWCe-0000vN-FW for dnsop@ietf.org; Thu, 21 May 2015 15:32:24 -0400
Message-ID: <555E32AC.1040402@gnu.org>
Date: Thu, 21 May 2015 16:31:56 -0300
From: hellekin <hellekin@gnu.org>
Organization: https://gnu.org/consensus
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0
MIME-Version: 1.0
To: dnsop@ietf.org
References: <20150521034135.67747.qmail@ary.lan> <DDD750B2-91C9-4818-B04A-933A721728E4@fb.com> <589B9950-8311-49CF-9E28-DB0E7C9D7401@nominum.com>
In-Reply-To: <589B9950-8311-49CF-9E28-DB0E7C9D7401@nominum.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/j6J-87i5lHBD_a8A3vgzQft1bWE>
Subject: Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld
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, 21 May 2015 19:32:30 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/21/2015 04:21 PM, Ted Lemon wrote:
> 
> It would make sense to call it a reserved special-use top-level domain
 name.
> It's not a top-level domain in the DNS, though.
> I think that's the distinction to make.
> 
*** A distinction that the P2PNames draft made:

   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.  A pTLD is mentioned in
   capitals, and within double quotes to mark the difference with a
   regular DNS gTLD.

In the introduction, we specify the shared characteristics of pTLDs:

The set of Special-Use Domain Names for Peer-to-Peer Systems (pTLDs)
   reserved by this document meet this requirement, as they share the
   following specificities:

   o  pTLDs are not manageable by some designated administration.
      Instead, they are managed according to various alternate
      strategies or combinations thereof, introduced in this document,
      and their respective protocol specifications: automated
      cryptographic assignment (".onion", ".zkey"), user-controled
      assignment in a private scope (".gnu", ".i2p"), or in a global
      public ledger (".bit"), or used as a source-routing mechanism to
      delegate DNS resolution to a remote peer (".exit").

   o  pTLDs do not depend on the DNS context for their resolution: GNS
      and Namecoin domains MAY use the DNS servers infrastructure, as
      they return DNS-compatible results; and all pTLDs use specific P2P
      protocols for regular name resolution, covered by their respective
      protocol specifications.

   o  When a pTLD protocol has been implemented, the implementation MUST
      intercept queries for the pTLD to ensure P2P names cannot leak
      into the DNS.

   o  The appropriate pTLD protocols can be implemented in existing
      software libraries and APIs to extend regular DNS operation and
      enable P2P name resolution.  However, the default hierarchical DNS
      response to any request to any pTLD MUST be NXDOMAIN.

   o  Finally, in order for pTLDs to realize a censorship-resistant,
      fully-decentralized name system, and provide security and privacy
      features matching user expectations, this document specifies
      changes required in existing DNS software and DNS operations.

==
hk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJVXjKhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9sR0P/RdE7DV7G8tmeJ75tAAS3lmC
Au1SiOjeCdB1kN5ztifd6AvffeOqxueIUisvw7P1Tefow94kLOqR01gcfNd3q5kq
nj52NmAya6dvnG3pCiyzclQviaZ3FxPOy5Bc1a8nwgCf+Km5Ze0AAjPmev7Y7QUD
yrTaw7GpOdn6Q63VgFcekMbN7hEXpV2wY7U0dLEXvn0IKbggVFTjMf2T81FBNrlv
6shf9iqgso4ocUHz7CjZo3oyc+7uZcIZxJkBoi6a4AYO/s8nDWCv/cJF4Vx69Eej
FRhBdqcngZtlDuUAcSTX6tCfYL8OAu2Lr3qKfL5seYxyluoghaRZ2RxR0kJbPgPa
xI58qJZ44R5mNHfQ9JYJzo6Y4RU9XaK7/Wf7GanwnImYw0S/XbokwsJjf45rqhVj
HYee6KuKNMj6Q46bIclBa/tmyVmWkRVoTnjr2dWf9L9+HzK4MfmRnzFim+9+jnYb
8ultuqWsmh7s5NnTaUlincGO1m9tXoqxSmAy9y6IG2LnkvDUOUelQAhtkFOEy4iB
6vnWv25V9vBewX9akqdCTZL53TAp3hFzcr+ku1j5qNjrkbTrUVHqENbf0fUUp7Rj
U+wIky95YOrHDECiPDvPzAJw6dLQI+3TuytFChTFBV53yOH4bRCoiLUOcISJ5ULS
ELRKa+P9ejBy73uJJVr7
=bz5s
-----END PGP SIGNATURE-----