[Gen-art] GEN-ART telechat review of draft-ietf-dnsext-rfc6195bis-04.txt

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Tue, 09 October 2012 14:22 UTC

Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 09 Oct 2012 16:22:09 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A040822F948@307622ANEX5.global.avaya.com>
Thread-Topic: GEN-ART telechat review of draft-ietf-dnsext-rfc6195bis-04.txt
Thread-Index: Ac2mKXe8zInd18z9SsG1+nqpJVL+MA==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: gen-art@ietf.org
Subject: [Gen-art] GEN-ART telechat review of draft-ietf-dnsext-rfc6195bis-04.txt
Precedence: list

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

[Gen-art] GEN-ART telechat review of draft-ietf-d… Romascanu, Dan (Dan)