ietf
[Top] [All Lists]

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

2010-01-05 18:56:37
Hi Joe,
At 08:00 05-01-2010, Joe Abley wrote:
We think the re-delegation of IN-ADDR.ARPA and IP6.ARPA is of great interest to dnsop and other operational forums outside the IETF, and as I mentioned yesterday the redelegation

I apologize for the working group question. I forgot that the draft was brought to the attention of the WG.

of both zones includes a communication plan intended to inform the operational community of the changes that are taking place. Those plans are still in draft form, as noted yesterday. We appreciate that there are likely to be some hard-coded references to the current NS RRSet for both zones which will behave differently following the change.

I think that those (draft) plans could have been circulated before the Last Call. Although I prefer something more substantive than a communication plan intended to inform the community, this may not be the right venue for me to make such a request.

We had expected the naming scheme (just the naming scheme, not the redelegation) for the nameservers to stimulate less operational interest, and did not specifically publicise the document there. However, the existence of the draft was brought to the attention of the dnsop wg in a review posted there by Alfred Hoenes on 13 November:

In my opinion, it is helpful to have early reviews, i.e. before the Last Call. This is a matter of author preference.

I believe there was no other reaction to -00 by the participants of the dnsop wg, although it was a couple of months ago and perhaps my memory is faulty.

It is my memory that is faulty. For what it is worth, the draft was brought to the attention of namedroppers yesterday by Paul Hoffman [1]. As an off-topic note, there's a problem with the namedroppers list archive for the year 2010.

The proposal is not directly concerned with operations, but with the procedural assignment of namespace under the ARPA zone. We were advised that the use of domains under ARPA in this way, per RFC 3172, required a standards-track RFC, hence this document.

That requires the technical approval of the IETF. The community consensus can be expressed through a BCP as the proposal calls for full and immediate instantiation. The RFCs about the naming scheme have a checkered history (see RFC 3152, predecessors and successor). It can be argued that it is suitable to use the Standards Track Maturity Levels because of the IP6.ARPA delegation.

The text that appears in the document in section 4 was supplied to the document authors by the IAB following their internal review of the document. I know that people on the IESG are aware of it since I've talked to them, but I'm not sure I would expect that awareness to be reflected in telechat minutes.

A year or so ago, the IAB Chair mentioned that minutes are published so that anyone who wants to read them can do so. There is an expectation, at this end at least, that the non-confidential information brought to the attention of the IESG and the IAB are reflected in their minutes for the awareness of the IETF Community. As IAB statements are not the usual fare in RFCs, I think that it is worth a mention.

Unless someone can identify new security risks for the Internet that assigning these two names would cause, I don't know what other text could plausibly be included in section 6. If you have suggestions, I would happily read them.

From Appendix A:

The NS RRSet for the IN-ADDR.ARPA zone at the time of writing is as
   follows:

     IN-ADDR.ARPA.         86400   IN      NS      A.ROOT-SERVERS.NET.
     IN-ADDR.ARPA.         86400   IN      NS      B.ROOT-SERVERS.NET.
     IN-ADDR.ARPA.         86400   IN      NS      C.ROOT-SERVERS.NET.
     IN-ADDR.ARPA.         86400   IN      NS      D.ROOT-SERVERS.NET.
     IN-ADDR.ARPA.         86400   IN      NS      E.ROOT-SERVERS.NET.
     IN-ADDR.ARPA.         86400   IN      NS      F.ROOT-SERVERS.NET.
     IN-ADDR.ARPA.         86400   IN      NS      G.ROOT-SERVERS.NET.
     IN-ADDR.ARPA.         86400   IN      NS      H.ROOT-SERVERS.NET.
     IN-ADDR.ARPA.         86400   IN      NS      I.ROOT-SERVERS.NET.
     IN-ADDR.ARPA.         86400   IN      NS      K.ROOT-SERVERS.NET.
     IN-ADDR.ARPA.         86400   IN      NS      L.ROOT-SERVERS.NET.
     IN-ADDR.ARPA.         86400   IN      NS      M.ROOT-SERVERS.NET.

   The NS RRSet for the IP6.ARPA zone at the time of writing is as
   follows:

     IP6.ARPA.             84600   IN      NS      NS-SEC.RIPE.NET.
     IP6.ARPA.             86400   IN      NS      SEC1.APNIC.NET.
     IP6.ARPA.             86400   IN      NS      NS2.LACNIC.NET.
     IP6.ARPA.             86400   IN      NS      NS.ICANN.ORG.
     IP6.ARPA.             86400   IN      NS      TINNIE.ARIN.NET.

The diversity of operators has some advantages, i.e. not sharing fate. The Introduction Section of this draft mentions that "The choice of operators for individual nameservers is beyond the scope of this document". I don't know whether a change of operators is envisioned.

I leave it to the authors of the draft to determine whether a reference to RFC 2870 is necessary given that the "secure and stable hosting of the IN-ADDR.ARPA and IP6.ARPA zones is critical to the operation of the Internet".

The text from RFC 3172 could be adapted as follows:

   The security considerations as documented in RFC 2870 apply to
   the operation of the nameservers for "IN-ADDR.ARPA" and "IP6.ARPA".

I suggest changing the following paragraph in Section 1:

  "The choice of operators for individual nameservers is beyond the
   scope of this document, and is an IANA function which falls under the
   scope of section 4 of the MoU between the IETF and ICANN [RFC2860]."

to

   The operational administration of the IN-ADDR.ARPA and IP6.ARPA zones
   is performed by the IANA under the terms of the MoU between the
   IAB and ICANN concerning the IANA [RFC2860].

Section 3 of RFC 3172 mentions that:

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

I suggest changing the following paragraph in Section 5:

  "The choice of operators for all nameservers concerned is beyond the
   scope of this document, and is an IANA function which falls under the
   scope of section 4 of the MoU between the IETF and ICANN [RFC2860]."

to

   The operational administration of the IN-ADDR-SERVERS.ARPA and
   IP6-SERVERS.ARPA zones shall be performed by the IANA under the terms
   of the MoU between the IAB and ICANN concerning the IANA [RFC2860].

Regards,
-sm

1. http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg03218.html
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf