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

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

On 18/12/09 18:55, James Gould wrote:
> Klaus,
>

Hi James,

> Thanks for the feedback. My answers are below:
>
>>  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?
>
> My intent was for the server to support either the DS Data Interface or
> the Key Data Interface and not both. This is similar to the hostObj and
> hostAttr models in the RFC 5731. If the server supports different
> interfaces at the object level, it will not be straight forward to the
> client what interface to implement to. Do you see a need for the server
> to support both models at the same time and if so can you describe why?
> Should more be added to the draft to make it clear that the server
> should support either the DS Data Interface or the Key Data Interface
> and not both?
>

Well, technically, this is feasible to support both at the same time. But I 
agree that this would be rather confusing and thus should be avoided. I would 
appreciate a sentence with a SHOULD NOT according to RFC 2119.

>>  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.
>
> Yes, this is good feedback, but I believe that the exclusion of the
> extension when there is no relevant data is pretty standard across the
> EPP extensions and is assumed in the original RFC. For example in the
> RGP EPP RFC 3915 it doesn’t state that the <rgp:rgpStatus> should not be
> included if none of the rgp statuses apply. The secDNS:infData can not
> be empty based on the XML schema, so the server has no choice but to not
> include the extension. I’m not sure if explicit text is warranted here
> or for the other commands (secDNS:create and secDNS:update) around not
> including the extension when there is no relevant data associated to
> secDNS.
>

While a standard should be concise, it should avoid implicit assumptions in my 
humble opinion. Maybe I am wrong, but I can't remember that RFC 5730 or RFC 3735 
say anything about the semantics of not including a certain extension. Also, 
giving the existence of an extension element any meaning limits the forward 
compatibility of the extension itself. For example, if someone thinks to extend 
RFC 3915 to report something in addition to the <rgp:rgpStatus>, then the 
semantics of the infData element would have to be changed regarding the existence.

>>  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.
>
> This is pretty standard text in the original RFC and other EPP
> extensions. The global assumption is that the extension should not be
> included in the secDNS:create, secDNS:update, secDNS:infData if there is
> no data or updates associated with secDNS.

I cannot agree. RFC 2119 says regarding "MUST":

    1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
       definition is an absolute requirement of the specification.

Although I am not a native English speaker, this seems to be pretty clear to me 
that there may not exist any hidden assumptions. There is no comparative to 
"absolute". And it is no excuse for me that other EPP related RFCs do the same. 
Their wording has been the source for confusion more than once ;-)

> [...]

>
>>  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.
>
> I prefer to keep the order of <add> and <rem> consistent with the other
> EPP RFC’s ( RFC 5731 and RFC 5732 ). RFC 4310 is somewhat unique in the
> sense that the <maxSigLife> is an attribute that might need to be
> changed in the act of an <add> and <rem>, so some text might be needed
> to clarify this in the draft. So really the only reason for <add> and
> <rem> of the same DS or Key Data would be to change the <maxSigLife> value?

There is probably no other reason. But I can live with your decision since there 
is an alternative way to achieve the same. It would be worse if the client would 
have to issue two commands to the server in order get the maxSigLife changed. If 
just between the two commands the server would take a snapshot for the zone 
generation, it would render the domain inoperable.

>
>
> JG

Klaus


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