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

[Klaus Malorny <Klaus.Malorny@knipp.de>]

On 14/12/09 23:56, James Gould wrote:
> 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
>
> [...]
>
> Please provide me with any feedback that you have via the list or
> privately.
>
> Thanks,
>

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






-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se