Subject: [dnsext] Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard

From: The IESG <[email-masked]> (by way of Paul Hoffman)
Date: Mon, 4 Jan 2010 06:19:37 -0800

The IESG has received a request from an individual submitter to consider 
the following document:

- 'Nameservers for IPv4 and IPv6 Reverse Zones '
   <draft-jabley-reverse-servers-01.txt> as a Proposed Standard

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
[email-masked] mailing lists by 2010-02-01. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-jabley-reverse-servers-01.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19391&rfc_flag=0

---

From: David Conrad <[email-masked]>
Date: Mon, 4 Jan 2010 10:00:52 -0500

In general, I strongly support this document.

My only question would be whether it would make sense to use "IP4-SERVERS.ARPA" instead of "IN-ADDR-SERVERS.ARPA" (a foolish consistency being the hobgoblin of little minds like my own).

Regards,
-drc

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 04 Jan 2010 11:53:36 -0500

> My only question would be whether it would make sense to use "IP4-SERVERS.ARPA" instead of "IN-ADDR-SERVERS.ARPA" (a foolish consistency being the hobgoblin of little minds like my own).
I agree with David.

I also question that this would be a "Proposed Standard".  I'm wondering
how they are going to demonstrate interoperability between multiple
implementations -- some sort of Internet in a parallel universe?

I suggest this should be an update to BCP52 (RFC 3172):
           Management Guidelines & Operational Requirements for
          the Address and Routing Parameter Area Domain ("arpa")

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Jan 2010 12:53:24 -0500

>         the Address and Routing Parameter Area Domain ("arpa")

Following section 3 of RFC 3172 was the only motivation to put this document forward for the standards track. Since there is no need for the document to ever progress from proposed standard to draft standard, there will be no need to demonstrate interop, etc.

It certainly seems possible that updating 3172 could have been another mechanism. However, modifying 3172 (as opposed to following its rules) seems likely to be a far more involved, political process; we were attempting to solve for operational pragmatism rather than philosophical perfection.

Joe

3. Delegation of "arpa" Sub-Domains

   While the decision as to which protocol elements are loaded into the
   "arpa" domain, and the hierarchical structure of such protocol
   elements, remains within the role of the IAB, the role of managing
   the sub-domain may be delegated by the IAB to an appropriate protocol
   management entity.

   The IAB shall only recommend the creation of "arpa" sub-domains
   corresponding to protocol entities where:

   -  the delegation, and the hierarchical name structure, is described
      by an IETF Standards Track document [4], and

   -  the use of the "arpa" domain is explicitly recommended in the
      "IANA Considerations" section of that document.

   The "IANA Considerations" section should include the name of the
   subdomain, the rules for how the subdomain is to be administered, and
   the criteria for entries within the subdomain.