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

[James Gould <jgould@verisign.com>]

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

Eland,

“I was under the impression that the selectType idea was pretty much dead.”

The comment is associated with the use of elements versus attributes and less on whether all of the elements are required or optional.  The optional scheme is like the selectType idea, where a set of attributes/elements could match more then one DS record.  Either attributes or elements work, but one of the earlier points was that digest is not really an attribute of a keyTag and similarly alg is not an attribute of a digest.  The elements are cleaner.  

“If I once again go back to RFC 5731, I see that non-unique attributes of an element that is to be selected for the rem command are optional.  If we want to keep the EPP flavor, then I'd suggest that we only require the digest itself, and make the others optional.”

I suggest that we just make all four required to be consistent with the add and chg.  There is a statistical chance (yes, very remote chance)  of producing the same digest for two different DS records, so it’s cleanest to remove any chance of matching duplicate DS records.  I don’t believe that it’s overly burdensome to pass all four attributes on a rem to remove any ambiguity.   

I’m still not sure what is wrong with Klaus’s proposal.  Is it really too burdensome to pass all four attributes to a remove?  I have to assume that everyone is fine with support for add and rem in the same command like is the case for contacts and name servers in domains and ip addresses for hosts.  

-- 


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: Howard Eland <heland@afilias.info>
Date: Fri, 30 Oct 2009 14:37:01 -0400
To: James Gould <jgould@verisign.com>
Cc: Klaus Malorny <Klaus.Malorny@knipp.de>, EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?


On Oct 30, 2009, at 1:27 PM, James Gould wrote:

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

I was under the impression that the selectType idea was pretty much dead.

>  
>  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.

If I once again go back to RFC 5731, I see that non-unique attributes of an element that is to be selected for the rem command are optional.  If we want to keep the EPP flavor, then I'd suggest that we only require the digest itself, and make the others optional.

-Howard

  
 
--
 
 
 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