Internet-Draft submission

idnits 2.12.18 

/a/www/www6s/staging/draft-grothoff-iesg-special-use-p2p-names-00.txt:

  Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--).
  Errors MUST be fixed before draft submission.  Flaws SHOULD be fixed before draft submission.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** The document seems to lack a Notice of Compliance with BCP 78 and BCP 79
     according to IETF Trust Provisions of 28 Dec 2009, Section 6.a or
     Provisions of 12 Sep 2009, Section 6.a. 

     IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
        This Internet-Draft is submitted in full conformance with the provisions
        of BCP 78 and BCP 79.


  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand
     corner of the first page

  ** The document seems to lack a 1id_guidelines paragraph about
     Internet-Drafts being working documents. 

     1id_guidelines, paragraph 1:
        Internet-Drafts are working documents of the Internet Engineering Task
        Force (IETF), its areas, and its working groups.  Note that other
        groups may also distribute working documents as Internet-Drafts.

  ** The document seems to lack a 1id_guidelines paragraph about 6 months
     document validity. 

     1id_guidelines, paragraph 2:
        Internet-Drafts are draft documents valid for a maximum of six months
        and may be updated, replaced, or obsoleted by other documents at
        any time.  It is inappropriate to use Internet-Drafts as
        reference material or to cite them other than as "work in
        progress."

  ** The document seems to lack a 1id_guidelines paragraph about the list of
     current Internet-Drafts. 

     1id_guidelines, paragraph 3:
        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/1id-abstracts.html

  ** The document seems to lack a 1id_guidelines paragraph about the list of
     Shadow Directories. 

     1id_guidelines, paragraph 4:
        The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html


  Running in submission checking mode -- *not* checking nits according to
  http://www.ietf.org/id-info/checklist .
  ----------------------------------------------------------------------------


     Summary: 6 errors (**), 0 flaws (~~), 0 warnings (==), 0 comments (--).

draft-grothoff-iesg-special-use-p2p-names-00.txt
Internet Engineering Task Force (IETF)                       C. Grothoff
IESG Approval document                                         TU Munich
                                                                M. Wachs
                                                               TU Munich
                                                         H. Wolf, editor
                                                           GNU consensus
                                                            J. Appelbaum
                                                        Tor Project Inc.
                                                            Nov 13, 2013

Intended status: IESG Approved
Expires: May 17th, 2014


          Special-Use Domain Names of Peer-to-Peer Name Systems


Abstract

   Today, the Domain Name System (DNS) is a key service for the
   Internet.  DNS is primarily used to map human-memorable names to IP
   addresses, which are used for routing but generally not meaningful
   for humans.  However, the hierarchical nature of DNS makes it
   unsuitable for various Peer-to-Peer (P2P) Name Systems.  As
   compatibility with applications using DNS names is desired, these
   overlay networks often define alternative pseudo Top-Level Domains
   (pTLDs) to integrate names from the P2P domain into the DNS
   hierarchy.

   This memo describes common Special-Use Domain Names [RFC6761]
   pseudo Top-Level DNS Names designed to help harden name resolution
   security (e.g., [RFC6840][RFC6975]), provide censorship resistance,
   and protect the users' privacy on the Internet.

   In this IESG Approval document we are asking for domain name
   reservations for five Special-Use Domain Names [RFC6761] TLDs:
   ".gnu", ".zkey", ".onion", ".exit", and ".i2p".

Status of this Memo

   This is an IESG Approval document specification [RFC5226] defining
   special handling of the said five Special-Use Domain Names for
   Peer-to-Peer Name Systems, in conformance with the registration
   procedure defined in RFC 6761, section 4.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

1.  Introduction

   [RFC6761] defines a mechanism for reserving DNS names for special
   use.

   This document is an IESG Approval document requesting the
   reservation of five pTLDs for special use: ".gnu", ".zkey",
   ".onion", ".exit", and ".i2p".  They relate to peer-to-peer systems
   that, given their decentralized design, do not require a central
   authority to register names.

   The GNU Name System (GNS) (".gnu", ".zkey"), the Tor network
   (".onion", ".exit"), and the Invisible Internet Project (".i2p")
   use these pseudo-Top-Level Domains (pTLDs) to realize
   fully-decentralized and censorship-resistant secure alternatives
   for DNS or, in the case of the ".exit" pTLD, to control overlay
   routing and to securely specify path selection choices [TOR-PATH].

   To facilitate integration with legacy applications, the overlay's
   namespaces can be accessed from applications to resolve these
   special TLDs, for example via specialized SOCKS proxies [RFC1928],
   specialized DNS servers, or transparent name resolution and
   ephemeral address mapping.

   This document describes the proposed special treatment for each of
   these five pTLDs below following the questions from [RFC6761],
   section 5.

2.  Terminology and Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in "Key words for
   use in RFCs to Indicate Requirement Levels" [RFC2119].

   The word "peer" is used in the meaning of a individual system on
   the network.  Thus, "local peer" means the localhost.

   The acronym "pTLD" is used as a shortcut to mean a pseudo Top-Level
   Domain, i.e., a name or label for a network not present in
   operational DNS, and not registered with IANA for use within the
   scope of operational DNS.  Specifically, it refers to one of the
   Special-Use Domain Names already in use on the Internet and
   described in this document.

   In this document, ".tld" (with quotes) means: any domain or
   hostname within the scope of a given pTLD, while .tld (without
   quotes), or dot-tld, both refer to an adjective form.  For example,
   a collection of ".gnu" peers, but an .onion URL.  The pTLD itself
   is mentioned with dot, and within double quotes, and usually
   followed by the word pTLD.