Skip to main content

Shepherd writeup

This is a document shepherd write-up of draft-ietd-dnsop-rfc6304bis-03,
structured according to the requirements of RFC 4858 and following
the corresponding template dated 24 February 2012.

   Intended status of draft-ietf-dnsop-rfc6304bis is Informational,
   consistent with RFC6304 which it aims to replace.

Technical Summary:

   Many sites connected to the Internet make use of IPv4 addresses that
   are not globally-unique.  Examples are the addresses designated in
   RFC 1918 for private use within individual sites.

   Devices in such environments may occasionally originate Domain Name
   System (DNS) queries (so-called "reverse lookups") corresponding to
   those private-use addresses.  Since the addresses concerned have only
   local significance, it is good practice for site administrators to
   ensure that such queries are answered locally.  However, it is not
   uncommon for such queries to follow the normal delegation path in the
   public DNS instead of being answered within the site.

   It is not possible for public DNS servers to give useful answers to
   such queries.  In addition, due to the wide deployment of private-use
   addresses and the continuing growth of the Internet, the volume of
   such queries is large and growing.  The AS112 project aims to provide
   a distributed sink for such queries in order to reduce the load on
   the corresponding authoritative servers.  The AS112 project is named
   after the Autonomous System Number (ASN) that was assigned to it.

   RFC6304 described the steps required to install a new AS112 node, and
   offered advice relating to such a node's operation.  This document
   updates that advice to facilitate the addition and removal of zones
   for which query traffic will be sunk at AS112 nodes, using DNAME,
   whilst still supporting direct delegations to AS112 name servers.

Working Group Summary:

   Since this document was an update of RFC 6304, the point was
   raised that the Internet had changed some and that there were
   better mechanisms to aid in these configurations. Specially
   around IPv6 transport, and also to allow for using DNAME.  The
   outcome of this discussion was draft-ietf-dnsop-as112-dname-03.

Document Quality:

   The document updates an existing RFC that has gone through the
   IETF RFC editorial process and is reflecting changing best
   practices. Therefore existing implementations exist, and have
   been observed for some time.


   The Document Shepherd is Tim Wicinski.

   The dnsop working group chairs are Tim Wicinski and Suzanne

   The Area Director is Joel Jaggeli.

   The document shepherd reviewed this document for clarity, potential
   for ambiguity or self-contradiction, technical accuracy and
   operational impact.

   It is the document shepherd's opinion that this document is ready
   to forward to the IESG.

   The Document Shepherd has no concerns about the depth or breath
   of the reviews. The document has cycled through the WG several
   times, each with very detailed and useful reviews.

   In the view of the Document shepherd, no wider review is necessary.

   The Document Shepherd has no such concern and has identified no
   such issue.

   No IPR disclosures have been made for this document.

   The authors have indicated that no IPR disclosures are intended
   to be made.

   The document shepherd has identified no reasons for an IPR
   disclosure to be made.

  No IPR disclosure has been made.

   There is solid working group consensus.  The documents were
   presented in several meetings, as well as a long mailing list
   discussion, and the consensus all areas have been covered.

   No appeal has been indicated and there is no extreme discontent.

   Most nits raised are in reference to the subject matter (e.g.
   the use of non-RFC5737 addresses for good reason, since the
   addresses specified are the actual addresses that need to be
   used, not example addresses).

  == Missing Reference: 'THIS DOCUMENT' is mentioned on line 793, but not

   This is a reference to the document itself for the purposes of
   registration in an IANA registry. This nit will be addressed upon
   the assignment of an RFC number to this document, as part of the
   RFC Editor's review.

   == In section 10, Acknowledgments, the document thanks individuals for
   their assistance in the preparation of the current document, but references
   it as RFC6304. This will need to be adjusted during the editing process.

   No such formal review is needed.

   All references have been identified as either normative or

   There is a reference to a document ietf-dnsop-as112-dname which
   is being submitted to the IESG in a bundle with this document.
   The document shepherd suggests both documents be considered for
   the IESG together, since they reference each other.  Following
   direction from the IESG to proceed, both documents would most
   naturally proceed through the publication process together.

   There are no downward normative references.

   This document is intended to obsolete RFC6304.

   This document requests that an AAAA RRSet be added to each of
   The request is clear and actionable.

   This document registers one code point in the Special-Purpose
   AS Numbers registry. The registry to be updated is well-described,
   and informal review of the IANA Considerations section by IANA
   staff suggests no problem with this registration.

   This document does not create any new IANA registries.

   This document does not create any new IANA registries.

   The document shepherd has performed checks (or, in some cases,
   has delegated checks to others) to confirm that the configuration
   examples provided for BIND9 and Quagga are accurate.

   The document shepherd confirms that based on all tests performed,
   the examples are accurate and usable.