Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question

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

On 12/10/2008 02:16 AM, Patrick Mevzek wrote:

> For me, no mix at all would be the simpler case, both on registry
> side and registrar side: that way there is nothing to think about
> what will happen if we do add+rem at the same type for the same info
> (otherwise it depends on registry policies and in some case it will
> be a noop as add+rem will be seen as opposite, where sometimes in
> other registries or other cases it will be a removal since it comes
> last), and registrars still have all power to do what they want, they
> just, if really needed, do multiple domain:update calls one after the
> following and each one with either an add, a rem or a chg. And this
> can be encapsulated on their side as a global operation in an higher
> API.
>
> I also observe that, for the same object types, some registries allow
> *only* chg, others allow *only* add and/or rem and some allow all
> 3 ... which create even more confusion.
>

Just my two cents: I personally want to have as few calls as possible, so I like 
being able to do additions and removals at the same time. Generally speaking, 
the design question is whether the "add/remove" approach is the preferable 
solution, or whether it is better to choose a "replace all" approach, 
especially, as the number of items (status values, contact reference, IP 
addresses etc.) are rather small. So a client side application would either 
determine the desired state from its own storage and submit it to the registry 
or would query the current state from the registry, alter the state at its own 
discretion and submit it as a whole to the registry. Our experience with such an 
approach in other protocols is rather good, although we discovered the need to 
select which part of the data shall be updated. If one only wants to change the 
name servers of a domain but not the contacts, it could be regarded as a burden 
if the submission of the contact data would be also required.

Regards,

Klaus