Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IP

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.

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf