I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dnsext-rfc6195bis-04.txt Reviewer: Dan Romascanu Review Date: 2012/10/09 IESG Telechat date: 2012/10/11 This draft is basically ready for publication, but has nits that should be fixed before publication. Minor Comments: 1. RFC 6195 was published only a year and a half ago. It would be good to explain in a sentence in the introduction the reasons of obsolescing it so soon by a new RFC. Is this because of the publication of [RFC2671bis], or because problems with the IANA registries and processes that needed to be fixed, or both? 2. Section 2: > The header for DNS queries and responses contains field/bits in the following diagram taken from [RFC2136] and [RFC6195]: I think you should drop the mention to [RFC6195]. As this document will obsolete RFC6195 there is no need to mention that the diagram is taken from there 3. Section 2.2: > New OpCode assignments require a Standards Action as modified by [RFC4020]. This sentence seems to have a historical flavor. I suggest s/modified/defined/ 4. Section 3.1.1: > RRTYPEs that do not meet the requirements below may nonetheless be allocated by a Standards Action as modified by [RFC4020]. Same comment and suggestion as above 5. Section 3.1.1: > If the Expert does not approve the application within this period, it is considered rejected. I believe it would be good to recommend that an explanation be returned to the supplicants about the reasons of the rejection, with possible suggestions to complete or fix the problems that led to the allocation request to be rejected. 6. Section 3.1.2: Is not duplicated mnemonic another reason for rejecting an RRTYPE allocation request that should be listed? 7. Section 5: > The dnsext at ietf.org mailing list is for community discussion and comment. I do not believe that this statement belongs in the IANA considerations section, there is no indication for an IANA action, but rather a recommendation to the supplicant to prepare their request and get community input by sharing it on the dnsext list. 8. Appendix B: > Note that this can be considered to update [RFC2845] and [RFC2930]. No room for conditional language, as the update is mentioned in the header of the document. I suggest: s/can be considered/is considered/ 9. id-nits flags the downref dependency on the approval of [RFC2671bis] - I guess that this was taken into consideration by the WG. Regards, Dan