Re: draft-gould-rfc4310bis-05.txt Submitted for Review

Howard,

Thanks for the feedback.  Below is my reply to your feedback:

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

No problem I can add this to the ­06 draft.

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

What is the purpose for doing this, since with the Key Data Interface the
client is managing the keys and the server is managing the DS associated
with the keys?  What would the client really do with the DS returned since
they don¹t explicitly set it or manage it.  We don¹t return the RRSIG
resource records with the DS Data Interface, so why would another generated
set of resource records be returned back?

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

This text is used throughout the draft, since section 4 ³DS Data Interface
and Key Data Interface² is meant to more fully define the two supported
interfaces of using either <secDNS:dsData> elements or <secDNS:keyData>,
where only one is used.  It is hard for me to believe that it can be
interpreted to use the optional ³validation² element of the <secDNS:dsData>
in the sentence ³Zero or more <secDNS:dsData> elements or <secDNS:keyData>
elements².  Based on your proposal 0, would it be clearer to say ³Zero or
more <secDNS:dsData> elements or <secDNS:keyData> elements, but not both as
defined in section 4²?  I view this as being redundant, but maybe because I
wrote it.  Please let me know if this sentence is really ambiguous and
whether the extra verbiage for the one sentence helps.

> 9. Security Considerations, 2nd to last paragraph
> After "Data validity checking", add "and Delegation Signer record creation".

No problem I can add this to the ­06 draft.



-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email protected]
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.



From: Howard Eland <[email protected]>
Date: Tue, 23 Feb 2010 16:17:01 -0500
To: EPP Provreg <[email protected]>
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".

-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
> [email protected] <x-msg://170/[email protected]>
> 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.
>