(No hat) A few comments on the -03 version of the draft:
Section 2, paragraph 1 ---------------------- > A validating resolver's configuration MUST allow one or > more trust anchors to be specified. The draft is about trust anchor configuration and maintenance, yet this places a requirement on validating resolvers. Is the draft the right place for it? Section 2, paragraph 3 ---------------------- The paragraph points out that the main reason for the recommendation is a "slight advantage" of the DS format over the DNSKEY one. Does the use of the word "slight" weaken the case for having this document? Section 2, paragraph 4 ---------------------- The fact that the DS record is smaller is an advantage. But as previous posts have noted, the advantage lies in the fact that it is easier to manually compare DS records, not that it is easier to enter the information by hand. Section 3, step 4 ----------------- > Verify that the DNSKEY RRSet is signed by one of the DNSKEYs > found in the previous step As step 3 only talks about one DNSKEY corresponding to the trust anchor, this should be "Verify that the DNSKEY RRSet is signed by the DNSKEY found in the previous step". Section 3, paragraph 8 ---------------------- > If any of the steps above result in an error, the validating resolver > SHOULD log them and abort the verification as specified in section 5 > of RFC 4035 [RFC4035]. Strictly speaking, section 5 does not describe how to abort verification; it (section 5.5) describes what to do if verification fails. Section 3, paragraph 9 ---------------------- (The one starting "If there are multiple trust anchors configured for a zone") The first two sentences are repeated. Section 3, paragraph 10 ----------------------- In the last-but-one line, "trust anchor" is spelt with a capital "T". Final sentence: it took me a moment to realise what a "DS from parent" error was. Perhaps it could be rephrased as something like: "The processing of a trust anchor verification failure MUST follow the same rules as the processing of a failure to verify a DS record obtained from the parent zone." Section 4, paragraph 4 ---------------------- (DNSSEC In-band Update) It is not usual to name the working group that developed a protocol. A reference to RFC5011 should be enough. Stephen Morris _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
