To: EPP Provreg <firstname.lastname@example.org>
From: Howard Eland <email@example.com>
Date: Tue, 23 Feb 2010 15:17:01 -0600
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
|In addition to that already posted to the list, I have the following comments:|
Section 3.3. Maximum Signature LIfetime
Nit: for clarity, you may want to add "in the parent zone" to the end of the sentence "The maxSigLife value applies to the RRSIG resource record (RR) over the DS RRset.".
Section 5.1.2. EPP <info> Command, Example <info> Response for a Secure Delegation using the Key Data Interface:
I believe the server should also return the server generated <secDNS:dsData> when the client only sends in the Key Data interface.
Section 5.2.1. EPP <create> Command, second bullet set plus examples
It is not clear in this section of the document that <secDNS:dsData> and <secDNS:keyData> elements, when used to create DS records on the server, cannot be intermixed. The text seems to imply that under a single <secDNS:create>, one could specify multiple <secDNS:dsData> elements, multiple <secDNS:keyData> elements, or a mixture of both, as a method for creating multiple DS records in the server. Using this interpretation, the example is actually ambiguous, as it is not sure if the <secDNS:keyData> is part of the optional "validation" element for the previous <secDNS:dsData>, or if it is implying the creation of another DS record by using only the <secDNS:keyData> for the second DS. I understand it's specified in the XML explicitly as "dsOrKeyType", but the text under create should reflect this as well.
The text could do one of the following:
0) Add text that explicitly states that only one of <secDNSdsData> or <secDNS:keyData> can be specified.
1) Change the "Zero or more" statement to "Zero or one", forcing a <secDNS:create> for each DS record desired (although this hoses up maxSigLife, so there's a bit more to this than just that).
2) Add something akin to a <secDNS:dsKeyData> element that would be used as a wrapper for the <secDNS:keyData> when it is used as the optional element under <secDNS:dsData>. This would avoid confusion as to when the client was specifying <secDNS:keyData> for validation purposes, or when it's used to specify another DS. In fact, couldn't doing this eliminate the need for <secDNS:dsData> and <secDNS:keyData> to be mutually exclusive?
9. Security Considerations, 2nd to last paragraph
After "Data validity checking", add "and Delegation Signer record creation".
On Feb 17, 2010, at 4:06 PM, James Gould wrote: