Last Call Review of draft-ietf-dnsext-rfc6195bis-04
review-ietf-dnsext-rfc6195bis-04-genart-lc-romascanu-2012-10-09-00

Request Review of draft-ietf-dnsext-rfc6195bis
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-10-09
Requested 2012-10-04
Authors Donald Eastlake
Draft last updated 2012-10-09
Completed reviews Genart Last Call review of -04 by Dan Romascanu (diff)
Secdir Last Call review of -?? by Steve Hanna
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-dnsext-rfc6195bis-04-genart-lc-romascanu-2012-10-09
Reviewed rev. 04 (document currently at 05)
Review result Ready
Review completed: 2012-10-09

Review
review-ietf-dnsext-rfc6195bis-04-genart-lc-romascanu-2012-10-09

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