Re: [ietf-provreg] Anyone working on 4310-bis?

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] Anyone working on 4310-bis?

“This problem has always been the case with EPP. If I submit a domain update
request with adding the status "clientHold" and removing the status "clientHold"
at the same time, what is the outcome? This applies to contacts, name servers
and other stuff as well.”

We really haven’t run into any issues with adding and removing contacts, name servers, or host ip addresses at the same time.  In our system, trying to add and remove the same element like the clientHold status will result in a 2306 “Parameter value policy error”.  The adds and removes are applied to the object within a single transaction so there should really be no ordering issue and the registry can address corner cases like trying to add and remove the same element.  

“If this "select" solution is taken, I don't mind whether it is implemented via
elements or attributes.”

Either the elements or attributes will work, but I still like your schema proposal the best.  The key is whether the elements (keyTag, alg, digestType, and digest) are required or optional and if they’re optional what happens if the specified elements match multiple DS records.  I don’t have an issue making them optional as long as the registry returns an error if they match more then one DS record.  I see it as a big issue if the client accidently deletes more then what was desired because they didn’t specify enough unique information.   It’s better to error out and require the client to explicitly specify what they want deleted.   

-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
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: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Fri, 30 Oct 2009 13:30:50 -0400
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On 30/10/09 15:39, Andrew Sullivan wrote:
> Hi,

Hi Andrew,

>
> On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote:
>
>[...]
>> 2) there is a consensus that<add>  and<rem>  elements shall be allowed in
>> a single request, which must be on the other hand mutually exclusive to
>> the<chg>  element.
>
> Are we sure that the<add>  and<rem>  elements have to be processed in
> the order in which they appear?  I am not completely sure.  I recall
> at least one operator who had an issue related to this
> processing-order question.  If they do _not_ have to be so processed,
> then in fact they can't be allowed in a single request because the
> effect could be different from what is intended.  (Note that this
> remark also means that there is by no means a consensus on this matter
> yet.)
>
> [...]

This problem has always been the case with EPP. If I submit a domain update
request with adding the status "clientHold" and removing the status "clientHold"
at the same time, what is the outcome? This applies to contacts, name servers
and other stuff as well.

So the protocol should clearly say how such a situation shall be handled:
- define a static execution order, e.g. first the removal, then the addition
- declare this as ambiguous and reject the order
- declare this as a non-change and ignore

By the way, as there seems to be some confusion: IMHO the order in the XML
document should *never* imply any order of execution.

>
> Not elements, but attributes, is the way I've got it at the moment.  I
> didn't include the attributes other than the hash in the text as it's
> written, but I think James has convinced me there'd be no harm in
> adding the other ones.

If this "select" solution is taken, I don't mind whether it is implemented via
elements or attributes.

Regards,

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