[Gen-art] Gen-art review of draft-ietf-dnsop-bad-dns-res-06

["Sharon Chisholm" <[e-mail]>]

I am the assigned Gen-ART reviewer for:

	draft-ietf-dnsop-bad-dns-res-06

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments
you may receive.

---------------------------------------------------------

This draft is basically ready for publication, but has nits that
	should be fixed before publication.


1. The document doesn't actually say anywhere that it is informational.
Looking at recently published informational RFCs (4586 for example), it
would seem the document needs a 'Category: Informational' in the header

2. In section 1, first paragraph, it refers to 'the thirteen com/net TLD
name servers' but isn't that just the number at the time of publication?
Shouldn't we clarify that?

3. In section 2.1, on page 5, second paragraph, I think I got a little
turned around. It is claiming that under the circumstances described
there is no value in re-querying the parent, since it gave you the bad
information in the first place, but what about a potentially valid peer
name server? Couldn't you get that from the parent or is it assumed that
is already in the cache?  I.e., if ns1 is bad, is ns2 not an option? Are
these meant to have different zones?
     example.com.   IN   NS   ns1.example.com.
     example.com.   IN   NS   ns2.example.com.

4. Section 2.2 implies that that an implementation can detect a lame
server and differentiate this case from others. It would be helpful to
remind implementers how to detect this.

5. In section 2.4.1, should implementations also consider detecting that
they send queries to a particular server and never get responses and
adapt as a result?

6. In section 2.5.1, the advice is to not be excessive with queries, but
is this a well understood query rate? 1 per minute or 1 per nanosecond?

7. Section 2.10.1 is the best example in the document of how to write up
the recommendation section. It clearly states where errors will be
reported (either through a user interface or a log file) where in most
other sections it was never specified. It might be interpreted as actual
protocol warnings and error that could be returned to the client in some
cases. Sections 2.6.1, 2.7.1, etc should be reworked to be more clear in
their recommendations.

8. Section 2.8 starts talking about agents. This appears to be a change
in terminology. 

9. The first paragraph of section 2.11 seems like a good introduction to
the entire section 2, but seems a bit out of place in its current
location

10. Section 2.11.1 mixes problem statement and recommendation in a way
that is inconsistent with the rest of the document.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art