AS112 Redirection Using DNAME
draft-ietf-dnsop-as112-dname-06

[Ballot comment]
Draft 05 added text aimed at Ted Hardie's comments.

was

Holding the dicsuss until a rev that addresses ted hardie's indivual comments is complete


for the record.

My own personal comments, were the document to come back for last call, would be a request for additional discussion of cache poisoning considerations in the absence of DNSSEC in the security considerations section, some clarifications in the language of section 4's discussion of replacement of the existing infrastruction and a request for expansion of the text in Section 5.  There may be other comments from others, of course, were the document's scope highlighted in the last call.

Thanks for your consideration,

was
Holding the dicsuss for pete until IAB question is resolved.

was:

Discuss (2014-08-21 for -04)

A strictly procedural point that I haven't seen anyone else comment on.

Section 7 says that the address delegation will require IAB approval. Is the
IESG tracking that, or is that an IANA thing to track, or is it done, or what?
Comment (2014-08-21 for -04)

In the document writeup, the shepherd suggests that there was some ambivalence
regarding the status of this document, and suggested that perhaps Experimental
would be appropriate, even though they landed on Informational. I think
Experimental is exactly right, with an eye toward moving this to BCP
eventually. (See my comments on 6304bis.)
from scott bradner: opsdir review.

in the 2nd paragraph of section 3.3 - remove the comment about the IPv6 testing environment and the note about the IANA request

in the 2nd paragraph of section 4.2 - add a forward reference to section 4.4. Routing Software

[Ballot discuss]
Holding the dicsuss until a rev that addresses ted hardie's indivual comments is complete


for the record.

My own personal comments, were the document to come back for last call, would be a request for additional discussion of cache poisoning considerations in the absence of DNSSEC in the security considerations section, some clarifications in the language of section 4's discussion of replacement of the existing infrastruction and a request for expansion of the text in Section 5.  There may be other comments from others, of course, were the document's scope highlighted in the last call.

Thanks for your consideration,

[Ballot comment]
was

Holding the dicsuss for pete until IAB question is resolved.

was:

Discuss (2014-08-21 for -04)

A strictly procedural point that I haven't seen anyone else comment on.

Section 7 says that the address delegation will require IAB approval. Is the
IESG tracking that, or is that an IANA thing to track, or is it done, or what?
Comment (2014-08-21 for -04)

In the document writeup, the shepherd suggests that there was some ambivalence
regarding the status of this document, and suggested that perhaps Experimental
would be appropriate, even though they landed on Informational. I think
Experimental is exactly right, with an eye toward moving this to BCP
eventually. (See my comments on 6304bis.)
from scott bradner: opsdir review.

in the 2nd paragraph of section 3.3 - remove the comment about the IPv6 testing environment and the note about the IANA request

in the 2nd paragraph of section 4.2 - add a forward reference to section 4.4. Routing Software

is the second Last Call review for draft-ietf-dnsop-as112-dname-04. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are four actions which IANA must complete.

First, in accordance with the requirements of RFC 5736 and RFC 6890, in the IANA IPv4 Special Purpose Address Registry located at:

http://www.iana.org/assignments/iana-ipv4-special-registry

a new IPv4 /24 netblock will be reserved with the following information:

Address Block: [ TBD-at-registration ]
Name: AS112-v4
RFC: [ RFC-to-be ]
Allocation Date: [ TBD-at-registration ]
Termination date: [ N/a ]
Source: True
Destination: True
Forwardable: True
Global: True
Reserved-by-protocol: False

IANA understands that the authors have suggested 192.31.196.0/24 and IANA is considering using that suggestion.

Second, in accordance with the requirements of RFC 5736 and RFC 6890, in the IANA IPv6 Special Purpose Address Registry located at:

http://www.iana.org/assignments/iana-ipv6-special-registry

a new IPv6 /48 netblock is to be reserved with the following information:

Address Block: [ TBD-at-registration ]
Name: AS113-v6
RFC: [ RFC-to-be ]
Allocation Date: [ TBD-at-registration ]
Termination date: [ N/a ]
Source: True
Destination: True
Forwardable: True
Global: True
Reserved-by-protocol: False

IANA notes that the authors have suggested 2001:112::/48 for this purpose. While ICANN is aware that there is not a shortage of IPv6 address space, it would like to maximize the use of 2001::/23 and keep shorter prefixes available where possible. Selecting 2001:112::/48 for the AS112 project means that 2001:100::/24 is no longer available for allocation because of a single /48 assignment within it. For this reason, we would like the authors to consider using an alternative prefix from nearer the start of 2001::/23. For instance, 2001:3:112::/48.

Third, upon approval and direction by the Internet Architecture Board and in conformance with RFC 3172, IANA will request the following delegation:

Domain: AS112.ARPA
Administrative Contact: Internet Architecture Board (IAB) c/o IETF Administrative Support Activity, ISOC
Technical Contact: Internet Assigned Numbers Authority (IANA)
Contact: Internet Assigned Numbers Authority (IANA)
Nameservers: [ TBD-at-delegation ]
DS-RDATA: [ TBD-at-registration ]

To aline with the registration information for ipv4only.arpa, the authors may want to use the following:

Organization: Internet Architecture Board (IAB)
Administrative Contact: Internet Architecture Board (IAB)
Technical Contact: Internet Assigned Numbers Authority (IANA)
Nameservers: [ TBD-at-delegation ]
DS-RDATA: [ TBD-at-registration ]

(The "c/o IETF Administrative Support Activity, ISOC" is part of the address information)

Fourth, IANA will host and sign the zone AS112.ARPA (see task three above) using nameservers and DNSSEC signing infrastructure of IANA's choosing.

IANA notes that Figure 2 of [ RFC-to-be ] provides a possible template for the SOA RDATA.

IANA understands that these four actions are the only ones required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (AS112 Redirection using DNAME) to Informational RFC - (dname and additional zones)


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'AS112 Redirection using DNAME'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-10-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Subsequent to the IETF Last call on this document. questions arose as
to wether the implications of using dname and therefore allowing zones
other than those described by the draft  and previously served by the as112
project to be served by as112 project nameservers was fully considered.
We have requested an additional last call to address this question.

The mechanism specified in 3.2 can be employed in practice by the
managers of a zone without coordination with as112 server operators.
This facilitates the deployment of additional zones for the purposes of
authoritative negative answers.

http://tools.ietf.org/html/draft-ietf-dnsop-as112-dname-04#section-3.2

Abstract


  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 IN-ADDR.ARPA authoritative servers.  The AS112 project is named
  after the Autonomous System Number (ASN) that was assigned to it.

  The AS112 project does not accommodate the addition and removal of
  DNS zones elegantly.  Since additional zones of definitively local
  significance are known to exist, this presents a problem.  This
  document describes modifications to the deployment and use of AS112
  infrastructure that will allow zones to be added and dropped much
  more easily.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-dname/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-dname/ballot/


No IPR declarations have been submitted directly on this I-D.

[Ballot discuss]
Holding the dicsuss for pete until IAB question is resolved.

was:

Discuss (2014-08-21 for -04)

A strictly procedural point that I haven't seen anyone else comment on.

Section 7 says that the address delegation will require IAB approval. Is the
IESG tracking that, or is that an IANA thing to track, or is it done, or what?
Comment (2014-08-21 for -04)

In the document writeup, the shepherd suggests that there was some ambivalence
regarding the status of this document, and suggested that perhaps Experimental
would be appropriate, even though they landed on Informational. I think
Experimental is exactly right, with an eye toward moving this to BCP
eventually. (See my comments on 6304bis.)

[Ballot comment]
The abstract on this document is way too long.  You don't need to explain everything; just give enough of a hook that people who should read the document will.  At its current length, it's unlikely anyone will read the abstract.  E.g.:

  AS112 provides a mechanism for handling reverse lookups on
  IP addresses that are not unique (e.g., RFC 1918 addresses).
  This document describes modifications to the deployment
  and use of AS112 infrastructure that will allow zones to be
  added and dropped much more easily, using DNAME resource
  records.

Otherwise, looks good!

[Ballot discuss]
A strictly procedural point that I haven't seen anyone else comment on.

Section 7 says that the address delegation will require IAB approval. Is the IESG tracking that, or is that an IANA thing to track, or is it done, or what?

[Ballot comment]
In the document writeup, the shepherd suggests that there was some ambivalence regarding the status of this document, and suggested that perhaps Experimental would be appropriate, even though they landed on Informational. I think Experimental is exactly right, with an eye toward moving this to BCP eventually. (See my comments on 6304bis.)

[Ballot comment]

I have one possibly dumb question. I don't think any change
is likely needed, but I'd like to check. Let's imagine a
horrible thing happens and some company decide to fire one
of their DNS ops people. On the way out the door, that
person installs a DNAME RR for (some of) the company's
addresses that sends reverse lookups of those addresses to
AS112. Is that something new either in terms of being harder
to detect or to fix? Or could our now ex-employee also have
sent other queries (e.g. forward lookups) to AS112 as well
and would that be easily spotted and fixed?  If none of this
is really new or interesting or harder to detect, (as I
suspect), then we're done. But like I said, I wanted to
check in case there actually is a new security consideration
which doesn't seem that unlikely since we're adding another
level of indirection and those often do add a security
wrinkle or two.

This also relates to the secdir review [1] I guess, though
the reviewer was happy with the responses he got thus
increasing the probability that my question is dumb:-)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04956.html

[Ballot comment]
I have no objection to the publication of this document, but time to
stop "proposing" things, and start "defining" or "describing".

  This document proposes a more flexibl approach for sinking queries

And other examples.

Oh, and s/flexibl/flexible/

---

In Section 2

  Some or all of the existing AS112 nodes should be extended to support
  these new nameserver addresses, and to host the EMPTY.AS112.ARPA
  zone.

I wondered about "should" in this sentence. Is there an objective to
this, or a philosophical reason, or...?

[Ballot comment]
Some very minor nits:

In this text in the abstract:

  The AS112 project does not accommodate the addition and removal of
  DNS zones elegantly.  Since additional zones of definitively local
  significance are known to exist, this presents a problem.  This
  document describes modifications to the deployment and use of AS112
  infrastructure that will allow zones to be added and dropped much
  more easily.

when this draft is approved, the first sentence won’t be true, will it? Could you think about how you want the RFC to say this?

The corresponding text in the Introduction may also benefit from the same thinking:

  AS112 nameserver operators are only loosely-coordinated, and hence
  adding support for a new zone (or, correspondingly, removing support
  for a zone that is no longer delegated to the AS112 nameservers) is
  difficult to accomplish with accuracy; testing AS112 nameservers
  remotely to see whether they are configured to answer authoritatively
  for a particular zone is similarly challenging since AS112 nodes are
  distributed using anycast [RFC4786].

Nit: s/flexibl /flexible /

In this text:

6.  DNAME Deployment Considerations

  DNAME was specified a significant time following the original
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  implementations of [RFC1035], and hence universal deployment cannot
  be expected.

This didn’t parse well for me. Perhaps “was specified years after the original implementations of”?

In this text:

9.  Security Considerations

  This document presents no known additional security concerns to the
  Internet.

  For security considerations relating to AS112 service in general, see
  [RFC6304bis].

is the first paragraph saying “no additional considerations beyond http://tools.ietf.org/html/draft-ietf-dnsop-rfc6304bis-00#section-8” or "no additional considerations beyond [RFC6304]"? I’m not sure how to read it.

[Ballot comment]
Some very minor nits:

In this text in the abstract:

  The AS112 project does not accommodate the addition and removal of
  DNS zones elegantly.  Since additional zones of definitively local
  significance are known to exist, this presents a problem.  This
  document describes modifications to the deployment and use of AS112
  infrastructure that will allow zones to be added and dropped much
  more easily.

when this draft is approved, the first sentence won’t be true, will it? Could you think about how you want the RFC to say this?

The corresponding text in the Introduction may also benefit from the same thinking:

  AS112 nameserver operators are only loosely-coordinated, and hence
  adding support for a new zone (or, correspondingly, removing support
  for a zone that is no longer delegated to the AS112 nameservers) is
  difficult to accomplish with accuracy; testing AS112 nameservers
  remotely to see whether they are configured to answer authoritatively
  for a particular zone is similarly challenging since AS112 nodes are
  distributed using anycast [RFC4786].

Nit: s/flexibl /flexible /

In this text:

6.  DNAME Deployment Considerations

  DNAME was specified a significant time following the original
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  implementations of [RFC1035], and hence universal deployment cannot
  be expected.

This didn’t parse well for me. Perhaps “was specified years after the original implementations of”?

In this text:

9.  Security Considerations

  This document presents no known additional security concerns to the
  Internet.

  For security considerations relating to AS112 service in general, see
  [RFC6304bis].

is this “no additional considerations beyond http://tools.ietf.org/html/draft-ietf-dnsop-rfc6304bis-00#section-8”? I’m not sure how to read it.

[Ballot comment]
from scott bradner: opsdir review.

in the 2nd paragraph of section 3.3 - remove the comment about the IPv6 testing environment and the note about the IANA request

in the 2nd paragraph of section 4.2 - add a forward reference to section 4.4. Routing Software

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dnsop-as112-dname-04.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are four actions which IANA must complete.

First, in accordance with the requirements of RFC 5736 and RFC 6890, in the IANA IPv4 Special Purpose Address Registry located at:

http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

a new IPv4 /24 netblock will be reserved with the following information:

Address Block: [ TBD-at-registration ]
Name: AS113-v4
RFC: [ RFC-to-be ]
Allocation Date: [ TBD-at-registration ]
Termination date: [ N/a ]
Source: True
Destination: True
Forwardable: True
Global: True
Reserved-by-protocol: False

IANA understands that the authors have suggested 192.31.196.0/24 and IANA is considering using that suggestion.

Second, in accordance with the requirements of RFC 5736 and RFC 6890, in the IANA IPv6 Special Purpose Address Registry located at:

http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

a new IPv6 /48 netblock is to be reserved with the following information:

Address Block: [ TBD-at-registration ]
Name: AS113-v6
RFC: [ RFC-to-be ]
Allocation Date: [ TBD-at-registration ]
Termination date: [ N/a ]
Source: True
Destination: True
Forwardable: True
Global: True
Reserved-by-protocol: False

IANA notes that the authors have suggested 2001:112::/48 for this purpose. While ICANN is aware that there is not a shortage of IPv6 address space, it would like to maximize the use of 2001::/23 and keep shorter prefixes available where possible. Selecting 2001:112::/48 for the AS112 project means that 2001:100::/24 is no longer available for allocation because of a single /48 assignment within it. For this reason, we would like the authors to consider using an alternative prefix from nearer the start of 2001::/23. For instance, 2001:3::112/48.

Third, upon approval and direction by the Internet Architecture Board and in conformance with RFC 3172, IANA will request the following delegation:

Domain: AS112.ARPA
Administrative Contact: Internet Architecture Board (IAB) c/o IETF Administrative Support Activity, ISOC
Technical Contact: Internet Assigned Numbers Authority (IANA)
Contact: Internet Assigned Numbers Authority (IANA)
Nameservers: [ TBD-at-delegation ]
DS-RDATA: [ TBD-at-registration ]

To aline with the registration information for ipv4only.arpa, the authors may want to use the following:

Organization: Internet Architecture Board (IAB)
Administrative Contact: Internet Architecture Board (IAB)
Technical Contact: Internet Assigned Numbers Authority (IANA)
Nameservers: [ TBD-at-delegation ]
DS-RDATA: [ TBD-at-registration ]

(The "c/o IETF Administrative Support Activity, ISOC" is part of the address information)

Fourth, IANA will host and sign the zone AS112.ARPA (see task three above) using nameservers and DNSSEC signing infrastructure of IANA's choosing.

IANA notes that Figure 2 of [ RFC-to-be ] provides a possible template for the SOA RDATA.

IANA understands that these four actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (AS112 Redirection using DNAME) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'AS112 Redirection using DNAME'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-07-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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 IN-ADDR.ARPA authoritative servers.  The AS112 project is named
  after the Autonomous System Number (ASN) that was assigned to it.

  The AS112 project does not accommodate the addition and removal of
  DNS zones elegantly.  Since additional zones of definitively local
  significance are known to exist, this presents a problem.  This
  document describes modifications to the deployment and use of AS112
  infrastructure that will allow zones to be added and dropped much
  more easily.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-dname/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-dname/ballot/


No IPR declarations have been submitted directly on this I-D.

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

1)

  Requested status is Informational.

  This document describes an approach for mitigating a key deficiency
  in the existing ("Direct Delegation") model of AS112 deployment
  that makes use of DNAME, namely the difficulty in adding or
  dropping particular zones from the AS112 infrastructure.

  The use of DNAME for this purpose is novel, and while some
  experiments (as described in this document) have indicated
  widespread support across the Internet for DNAME and have confirmed
  that the approach is functionally feasible, DNAME has not been
  previously used for AS112 in the wild. Note that the document
  does not propose immediate refactoring of the direct delegation
  approach for existing zones sunk in the AS112 infrastructure.

  Given the experimental aspects of this approach the document
  shepherd and the authors are not opposed to Experimental status.
  However, the document shepherd feels that Informational is
  preferred given plausible indications that the dependent mechanism
  (i.e. DNAME) are well-defined, well-deployed and suitable for
  the purpose.

2)

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 IN-ADDR.ARPA authoritative
  servers.  The AS112 project is named after the Autonomous System
  Number (ASN) that was assigned to it.

  The AS112 project does not accommodate the addition and removal
  of DNS zones elegantly.  Since additional zones of definitively
  local significance are known to exist, this presents a problem.
  This document describes modifications to the deployment and use
  of AS112 infrastructure that will allow zones to be added and
  dropped much more easily.

Working Group Summary:

  There were no notable outcomes from the WG process or in the
  working-group last call. The dnsop working group chair observed
  strong consensus on the text and the approach described by the
  text following presentations and discussion on the mailing list
  and in multiple in-person meetings.

Document Quality:

  The document describes the use of protocols that are already
  defined and implemented to augment AS112 infrastructure. The
  approach was validated by experiment, and an abridged summary
  of that experiment and its results are included in the document.

  The Acknowledgements section of the diagram does not omit to
  mention any significant reviewer.

  The working group review included input from participants with
  significant DNS protocol and operations expertise, and in the
  opinion of this document shepherd and the working group chairs
  no additional expert consultation is required.

Personnel:

  The document shepherd is Tim Wicinski.

  The dnsop working group chairs are Tim Wicinski and Suzanne
  Woolf.

  The responsible area director is Joel Jaeggli.

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

4)
  The document shepherd has no such concern.

5)
  In the opinion of the document shepherd, no further or wider review
  is necessary.

6)
  The document shepherd has no such concern and has identified no
  such issue.

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

8)
  No such IPR disclosure has been made.

9)
  The document shepherd and dnsop working group chairs have identified
  strong working group consensus for this document to proceed.

  The document has been discussed at some length on the dnsop mailing
  list and has also been presented in multiple face-to-face meetings.

10)
  The document shepherd and working group chairs are aware of no
  such threat or discontent.

11)
  No I-D nits have been identified by the document shepherd.

12)
  No such formal review is required for this document.

13)
  All references have been identified as either normative or
  informative.

14)
  This document contains a normative reference to
  draft-ietf-dnsop-rfc6304bis which is being submitted to the IESG
  in a bundle with this document.  The document shepherd suggests
  that both documents be considered by 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.

15)
  There are no downward normative references.

16)
  Publication of this document will not change the status of any
  existing RFC.

17)
  The document shepherd has been informed by the authors that the
  IANA Considerations section has already been informally reviewed
  by IANA staff, and that changes informally suggested have been
  implemented.

  All number resource assignments and directions relating to the
  delegation of a zone from the ARPA TLD have been confirmed (again,
  informally) to be clear and actionable.

  No new registries are requested by this document.

  The use of a name under the ARPA TLD requires IAB approval, per
  RFC 3172. This document includes an IAB Considerations section
  that is sufficient to request and document the IAB's review, in
  the opinion of the document shepherd.

18)
  No new registries are requested by this document.

19)
  This document contains no such section.

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

1)

  Requested status is Informational.

  This document describes an approach for mitigating a key deficiency
  in the existing ("Direct Delegation") model of AS112 deployment
  that makes use of DNAME, namely the difficulty in adding or
  dropping particular zones from the AS112 infrastructure.

  The use of DNAME for this purpose is novel, and while some
  experiments (as described in this document) have indicated
  widespread support across the Internet for DNAME and have confirmed
  that the approach is functionally feasible, DNAME has not been
  previously used for AS112 in the wild. Note that the document
  does not propose immediate refactoring of the direct delegation
  approach for existing zones sunk in the AS112 infrastructure.

  Given the experimental aspects of this approach the document
  shepherd and the authors are not opposed to Experimental status.
  However, the document shepherd feels that Informational is
  preferred given plausible indications that the dependent mechanism
  (i.e. DNAME) are well-defined, well-deployed and suitable for
  the purpose.

2)

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 IN-ADDR.ARPA authoritative
  servers.  The AS112 project is named after the Autonomous System
  Number (ASN) that was assigned to it.

  The AS112 project does not accommodate the addition and removal
  of DNS zones elegantly.  Since additional zones of definitively
  local significance are known to exist, this presents a problem.
  This document describes modifications to the deployment and use
  of AS112 infrastructure that will allow zones to be added and
  dropped much more easily.

Working Group Summary:

  There were no notable outcomes from the WG process or in the
  working-group last call. The dnsop working group chair observed
  strong consensus on the text and the approach described by the
  text following presentations and discussion on the mailing list
  and in multiple in-person meetings.

Document Quality:

  The document describes the use of protocols that are already
  defined and implemented to augment AS112 infrastructure. The
  approach was validated by experiment, and an abridged summary
  of that experiment and its results are included in the document.

  The Acknowledgements section of the diagram does not omit to
  mention any significant reviewer.

  The working group review included input from participants with
  significant DNS protocol and operations expertise, and in the
  opinion of this document shepherd and the working group chairs
  no additional expert consultation is required.

Personnel:

  The document shepherd is Tim Wicinski.

  The dnsop working group chairs are Tim Wicinski and Suzanne
  Woolf.

  The responsible area director is Joel Jaeggli.

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

4)
  The document shepherd has no such concern.

5)
  In the opinion of the document shepherd, no further or wider review
  is necessary.

6)
  The document shepherd has no such concern and has identified no
  such issue.

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

8)
  No such IPR disclosure has been made.

9)
  The document shepherd and dnsop working group chairs have identified
  strong working group consensus for this document to proceed.

  The document has been discussed at some length on the dnsop mailing
  list and has also been presented in multiple face-to-face meetings.

10)
  The document shepherd and working group chairs are aware of no
  such threat or discontent.

11)
  No I-D nits have been identified by the document shepherd.

12)
  No such formal review is required for this document.

13)
  All references have been identified as either normative or
  informative.

14)
  This document contains a normative reference to
  draft-ietf-dnsop-rfc6304bis which is being submitted to the IESG
  in a bundle with this document.  The document shepherd suggests
  that both documents be considered by 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.

15)
  There are no downward normative references.

16)
  Publication of this document will not change the status of any
  existing RFC.

17)
  The document shepherd has been informed by the authors that the
  IANA Considerations section has already been informally reviewed
  by IANA staff, and that changes informally suggested have been
  implemented.

  All number resource assignments and directions relating to the
  delegation of a zone from the ARPA TLD have been confirmed (again,
  informally) to be clear and actionable.

  No new registries are requested by this document.

  The use of a name under the ARPA TLD requires IAB approval, per
  RFC 3172. This document includes an IAB Considerations section
  that is sufficient to request and document the IAB's review, in
  the opinion of the document shepherd.

18)
  No new registries are requested by this document.

19)
  This document contains no such section.