At 8:13 PM +0200 4/22/09, Peter Koch wrote: >Please review the draft and send comments and/or statements of support or >non-support to the WG mailing list. >There will be a five reviewer threshold.
I support the publication of this document. Some comments: Section 2: "Using a DS format is also recommended because it is smaller than the DNSKEY format and is easier to enter manually, either by typing or cutting and pasting." I don't know of anyone who can accurately type Base64 for more than a few bits worth. I agree that cut-and-paste of Base64 for DS is easier than for a DNSKEY. Section 3: "Priming can occur when the validating resolver starts, but a validating resolver SHOULD defer priming of individual trust anchors until each is first needed for verification." I disagree with this as a SHOULD; "may want to" is much more appropriate. I see nothing wrong with wanting to get the first round of crypto out of the way at startup. Section 3: "Following are the steps a validating resolver SHOULD take to prime a configured trust anchor:". What do you propose they do if they don't follow the SHOULD? All four of those steps feel pretty damn required. Section 4, "Trusted update mechanism": "This mechanism is realistically only feasible for updating a small number of trust anchors, such as for the top-level domains." That statement is conjecture unsupported by facts. What is so hard about doing this for a few thousand trust anchors? The queries will be spread over hours (if not weeks). Maybe remove the sentence, or soften it. --Paul Hoffman, Director --VPN Consortium _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
