Simon,
all,

All in all, this document is in very good shape and about ready to pass 
Last Call. The only issue is that I find the use of normative language as 
of RFC 2119 a little bit shaky, I think that's something that should be 
thoroughly reviewed. Here come some examples of it, together with a 
mixture of nits and issues:

* Section 2, 3rd paragraph: "only CERT RRs with the same key tag need be 
examined". Though that is absolutely true, I am missing a statement 
(security considerations?) that key tags are not unique, so tag matching 
is a necessary but not a sufficient condition.
* Section 2, 3rd paragraph: "This is only possible if the key is 
applicable to an algorithm (and limits such as key size limits) defined 
for DNS security". It's about the wording ("key applicable to a limit"). 
What about "This is only possible if the key is applicable to an algorithm 
and complies to limits (such as key size) defined for DNS security".
* Section 2, 3rd paragraph: s/SHOULD BE/SHOULD be/
* Section 3, 2nd paragraph: "the use in DNS names of characters that 
require DNS quoting which". What about "the use in DNS names with 
characters that require DNS quoting, which"?
* Section 3, 4th paragraph: "CERT RRs MUST already know" should be "CERT 
RRs must already know"
* Section 3, 4th paragraph: "owner name MAY be the same" should be "owner 
name may be the same"
* Section 3.1, ASN description: What is that strange ".&Type" after the 
x400Address definition?
* Section 3.1, 2nd paragraph: "The recommended locations of CERT storage". 
Shouldn't that be "RECOMMENDED" to be useful?
* Section 3.1, 1st example: s/uri/URI/. Besides: What about using RFC2606 
domains instead of the existing john-doe.com?
* Section 3.1, 2nd example: I suggest using RFC3330 IP addresses for 
examples (192.0.2.0/24)
* Section 3.4, 1st paragraph: s/auxilliary/auxiliary/. Besides: What about 
including a preference in the order of appearance (simmilar to the order 
in section 3.1)? Like for instance, first looking for the fingerprint and 
then for the key ID.
* Section 7, 1st paragraph: I suggest s/MAY/may/
* Section 7, 3rd paragraph: s/it's/its/
* Section 7, 5th paragraph: "so there are no security considerations 
related to CERT RRs and securing the DNS itself". But that's not true 
anymore since you included the comments made by Ed regarding DNSSEC zone 
enumeration problems.

Best regards,
Marcos

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>