Re: Last Call: <draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt> (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[John C Klensin <[e-mail]>]

Olafur,

Based on reviewing the current draft and the handling of my
objections and other of others to the prior ones, I agree that
the document is ready for publication.  

However, I feel a need to comment on one of your observations
below because it seems to lie at the core of why this particular
document took up so much IETF list time and correspondence.
Most of that could have been avoided, IMO, and I think there is
something to be learned from it to which I hope you, the DNSEXT
WG, and Ted (as responsible AD) will pay attention.


--On Thursday, June 20, 2013 09:39 -0400 Olafur Gudmundsson
<[e-mail]> wrote:

> The document is going to be the specification of two DNS
> RRtypes that have been allocated via expert review, we (DNS
> community) want to encore that any such allocations be
> published as RFC's for future references. 

The IETF has historically had strong opinions about change
control, consensus, and the nature of recommendations.
Personally, I hope those opinions will continue and, if
anything, get stronger.

It seems to me that it is reasonable to say "we want a
lightweight registration procedure that imposes few if any
requirements on allocating an RR TYPE" or you can say "want to
ensure RFC publication" but that you don't get to say both at
once, especially when Standards Track or the IETF Stream are
involved.  If you (and DNSECT) want the very lightweight
registration procedure, then you should reasonably expect to
make sure that any documents are clearly informational (in
content and category) and to take your chances about
publication: Informational in either the IETF Stream or the
Independent Submission Stream could result in a "no" answer or,
more likely, requirements to justify the design decisions behind
the RRTYPEs as a condition of publication.  You can't "ensure"
anything because the relevant groups really do get to evaluate
both document quality and appropriateness for use.

By contrast, if the WG really does "want to ensure..." then it
would be appropriate to change the registration procedure so
that the I-Ds are posted and RFC publication is agreed to before
the RRTYPEs are registered so everyone can be sure that the two
match.    That could be coupled with some sort of provisional
arrangement while document review is in progress, if the WG
thought that was necessary.   Howver the bottom line, IMO, is
that, if you want RFCs and want those RFCs to accurately
describe an RRTYPE and there is going to be open review during
the RFC development process, you can't have lightweight
registration and then insist that an RFC be published to
match... at least IMO and, if the discussions of the recent Last
Calls are indicative, a significant part of the the community
may share that view.

So some review of the DNSEXT-specified procedures and
expectations may be in order.

regards,
   john