Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review

[Howard Eland <heland@afilias.info>]

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".

-Howard

 

On Feb 17, 2010, at 4:06 PM, James Gould wrote:

All,

I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.txt which includes the feedback that I received so far.  I included an open question on the inclusion of the ttl element to the AD for guidance.  Please let me know if you have any feedback to the latest draft.

Thanks,  

--


JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or Registry  Sensitive information intended solely for the recipient and, thus may not be  retransmitted, reproduced or disclosed without the prior written consent of  VeriSign Naming and Directory Services.  If you have received  this e-mail message in error, please notify the sender immediately by  telephone or reply e-mail and destroy the original message without making a  copy.  Thank you.