Re: 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
[email protected]
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 <[email protected]>
Date: Fri, 30 Oct 2009 14:37:01 -0400
To: James Gould <[email protected]>
Cc: Klaus Malorny <[email protected]>, EPP Provreg
<[email protected]>
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
>  [email protected]
>  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 <[email protected]>
>  Date: Fri, 30 Oct 2009 13:30:50 -0400
>  To: EPP Provreg <[email protected]>
>  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 [email protected]
>  
>  
>   
>