Subject: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for Review

From: James Gould <[email-masked]>
Date: Tue, 08 Dec 2009 10:01:05 -0500

All,

I haven¹t received any negative feedback to the draft that I previously sent
to the list, so I¹m assuming that everyone is fine with it.  I officially
submitted the draft.  The official draft is available at the URL below.  I¹m
looking for feedback to the draft from the list to ensure that we have
consensus to move forward.  Please send your feedback to the list or to me
privately.  

ftp://ftp.ietf.org/internet-drafts/draft-gould-rfc4310bis-00.txt

The draft meets the following goals that were previously sent to the list:

1. XML schema is backward compatible
2. Support for add and rem in the same command
3. Support for passing all four dsData attributes on a rem
4. Support for a dsData and keyData primary interface.  Only one primary
interface should be supported by the server.
5. Remove support for the wildcard delete of dsData in the rem by just using
the keyTag with a clear statement (i.e. Server must return error if the
keyTag matches multiple DS records) in the specification.  From my
perspective and I believe a couple others this is a key issue that must be
addressed.    
6. Clarity in the specification on the use of the chg as a replace or a
³change all².   
7. Clarity around the corner case of a client attempting to add and remove
the same dsData or keyData in a single command.  This must result in an
error from the server.  Additionally an error must be returned if the client
tries to remove dsData or keyData that does not exist or tries to add dsData
or keyData that already exists.

I received confirmation that the URI can stay the same as long as the XML
schema is backward compatible.

Thanks,    

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
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: Jaap Akkerhuis <[email-masked]>
Date: Wed, 09 Dec 2009 12:38:03 +0100

I'm looking for feedback to the draft from the list to ensure
    that we have consensus to move forward.  Please send your
    feedback to the list or to me privately.

[Procedural note].
Note that this list is just a mailing list. To advance this draft
to an RFC, it should either be an individual contribution, find a
home in an existing WG or a new one needs to be started.

	jaap
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: James Gould <[email-masked]>
Date: Mon, 14 Dec 2009 17:56:41 -0500

All,

I submitted 01 of the draft.  The official draft is available at the URL
below:

http://www.ietf.org/id/draft-gould-rfc4310bis-01.txt

The following is a summary of the changes from 00:

1. Added ³Appendix A. Changes from RFC 4310² section
2. Added Scott Hollenbeck as a co-author since much of the text comes from
the original RFC 
3. Added support for zero or more DS or Key Data with the secDNS:chg

Please provide me with any feedback that you have via the list or privately.

Thanks,

-- 

JG 

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

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 18 Dec 2009 10:38:42 +0100

On 14/12/09 23:56, James Gould wrote:
> [...]

Hi James,

thank you for your work. Unfortunately, I did not find time earlier to review 
the -00/-01 drafts, but here are my comments on the -01 draft (minor issues mostly):

- - 8< - -

section 3.

   The server MUST support use of one specification form consistently.

What does "consistency" mean in this context? This is a bit too vague for me. 
Shall it be possible to use one form for one domain, and the other form for 
another domain at the same instance?

section 4.1.2.

While the XML schema and the wording "one or more ...dsData...|...keyData... 
elements" implies the following, maybe it is worth to mention that if a domain 
does not have and DS or key data at all, the <secDNS:infData> element MUST not 
be included.

section 4.2.1.

same issue as 4.1.2. regarding the inclusion of <secDNS:create>.

section 4.2.5.

    The EPP <update> command provides a transform operation that allows a
    client to modify the attributes of a domain object.  In addition to
    the EPP command elements described in the EPP domain mapping, the
    command MUST contain an <extension> element.  The <extension> element
    MUST contain a child <secDNS:update> element that identifies the
    extension namespace and the location of the extension schema.

This implies that the extension element would have to be provided even in the 
case that the client does not intend to update the DNSSEC related data at all. 
In my humble opinion, this should not be the case, although the schema does 
allow an empty transformation regarding DNSSEC data.

    (<secDNS:rem> section)

    <secDNS:dsData> element is used to uniquely define the DS record to
    remove by using all four elements <secDNS:keyTag>, <secDNS:alg>,
    <secDNS:digestType>, and <secDNS:digest> that is guaranteed to be
    unique.

    <secDNS:keyData> element is used to uniquely define the key data to
    remove along with the associated DS data.  There can be more then one
    DS record created for each key, so removing a key could remove more
    then one DS record.

I would prefer if -- similar as for the dsData element -- the elements would be 
mentioned that are relevant for the identification, i.e. <flags>, <protocol>, 
<alg>, <pubkey> (excluding <maxSigLife>)

As Scott Hollenbeck recently clarified that the order in the XML document 
implies the execution order of the various changes contained in a request, I 
suggest to change the order of the <add> and <rem> element so that the <rem> 
element comes first. This would allow a client to change the <maxSigLife> value 
for a single entry using the <rem>/<add> scheme.

section 5/section 7:

I discovered that the schema uses the same XML namespace as RFC 4310. I am not 
familiar with the policies of XML namespaces at the IETF, but I wonder whether 
there is a need to use a different XML namespace, since we considerably changed 
the schema (despite the fact that it should be backward compatible).

- - 8< - -

Regards,

Klaus