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 <ogud@xxxxxxxx> 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