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

[Olaf Kolkman <[e-mail]>]

On Jan 4, 2010, at 3:08 PM, The IESG wrote:

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




Colleagues, Ron,

In the context of Joe Abley's reverse servers draft (draft-jabley-reverse-servers) there has been some discussion about the need for a standards track document for the delegation.

I was the IAB member that suggested Joe to follow standards track on the basis of my strict reading of RFC3172 section 3. I did so after considering whether an IAB stream document for this was sufficient. Unfortunately, when the appropriateness of the IAB statement (section 4) in Abley's draft was brought to the IAB list, the reference to the trade-off between STD-track and IAB stream was overlooked and not discussed timely.

After having seen the discussion on the list I believe that RFC3172 (2.1) is clear about the use of zones under .arpa within the context of protocol parameters (in-addr.arpa, urn.arpa, etc e164.arpa). The implementation thereof is described in section 3 of the document.

However in this case the argument has been made that the creation of a subdomain is done for purely operational purposes.

In the case of purely operational matters, such as redelegation of nameservers for specific domains, or DNSSEC signing of .ARPA, the IAB instructs or approves modifications in the .ARPA zone that need to be implemented by IANA.

This document is closer to describing an operational matter than a protocol matter and could have been treated differently -- as an IAB-stream informational RFC-- obviously after a "Call for Comments".  The current review is useful for transparency: having to explain clearly the 'why and how' is beneficial to everyone.

The point I am trying to make is one of setting precedent: A future IAB may make a different tradeoff between IETF Standards Track versus IAB-stream publication. In this case the coin dropped in the direction of Standards Track review.

Having made that point I want to share the observation that the document has no protocol elements as such. Publication as BCP instead of Standards Track would therefore be better. Another decision the IESG could make based on the last call comments is to hand the document back to the IAB for publication on the IAB stream. As far as timely publication of the material is concerned either path would do. I do not think the IESG would need more time if the document would be BCP instead of Standards track, nor would the IAB need a call for comments, as the discussion on this list has been thorough.

To be clear, we are where we are, and I personally do not think that any of these consideration should delay publication: the decision is currently with Ron.

--Olaf
  as IAB chair.