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

[James Gould <jgould@verisign.com>]

Howard,

I donıt believe that there is a desire to allow wildcard deletion of DS
records.  That is the existing issue, where the client requests to delete
keyTag 12345 and if there are multiple DS records with the same keyTag 1234
for the domain, all of the DS records will be deleted.  I believe it is
preferable to make the deletions as explicit as possible, where the option
of using the dsDataType will address it by requiring all four elements to be
passed (keyTag, alg, digestType, and digest) for uniquely identifying the DS
record to delete.  None of the attributes alone uniquely identify a DS
record, so the natural primary key is the combination of all four of them.
If clients desire to be able to uniquely identify a DS record by using a
subset of the four elements, than a change could be made to make one or more
of the elements of dsData optional by defining a new complexType like
dsDataType with minOccurs=²0².  The selectType meets the need, but it best
not to introduce a new element like ³select² under the rem element.

My recommendation is for the registry to return an error if the client
specifies a DS that does not result in a single DS record being deleted.  If
we want to make the input elements for the rem flexible to allow the client
to decide what uniquely identifies the DS to remove than the schema could
look like below (the remType dsData element could be renamed to something
like "select" if needed).  Specifying no elements for the dsData should
result in an error since it won't match anything.

    <complexType name="updateType">

        <choice>
  
            <element name="chg" type="secDNS:dsType"/>

            <sequence>

                <element name="add" type="secDNS:dsType" minOccurs="0"/>

                <element name="rem" type="secDNS:remType" minOccurs="0"/>

            </sequence>

        </choice>
 
        <attribute name="urgent" type="boolean" default="false"/>

    </complexType>
    
    


     <complexType name="selectType">
       <sequence>
         <element name="keyTag" type="unsignedShort"
                  minOccurs="0"/>
         <element name="alg" type="unsignedByte"
                  minOccurs="0"/>
         <element name="digestType" type="unsignedByte"
                  minOccurs="0"/>
         <element name="digest" type="hexBinary"
                  minOccurs="0"/>
       </sequence>
     </complexType>


    <complexType name="remType">

        <choice maxOccurs="unbounded">

            <element name="keyTag" type="unsignedShort"/>

            <element name="dsData" type="secDNS:selectType"/>

        </choice>
 
    </complexType>
    


-- 


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: Wed, 28 Oct 2009 17:19:32 -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?

So, thinking about this, plus Ed's comments about being able to use the
digest itself led me to add a couple more things.

First, I'd think it'd be good to be able to specify which DS records to
operate on with as little information as possible, and make it flexible
(without having to specify the entire DS record).

Second, I could see people wanting to do things like "remove all algorithm
ID 5 records".

So, I came up with a selectType, that let's you pick from keyTag, alg ID,
digest type, or digest itself.  For a rem, that's all that is needed.
However, to make this consistent, I added it to chg as well (creating
"chgType" in the process, so you could specify changing only one of many DS
records without repeating the entire set.  I made these changes to your last
post of "updateType" below, so the simultaneous add/rem is in there as well.

I believe we're _mostly_ backwards compatible here (see Caveat 3).
A couple of caveats:
1) Both with this and the post below, it looks like the XML would allow for
a no-op on updateType (since the second choice contains all elements with
minOccurs=0).
2) I did not validate this XML yet - I wanted to explain the concepts before
going any further.
3) As written, this allows for selecting _no_ attributes, which, in theory,
would allow one to remove all DS records for a domain object.  Currently RFC
4310 does not allow this, because the keyTag is required.  This adds
functionality, but at the expense of a foot-shotgun.

(non-validated) XML code below.

-Howard

    <complexType name="updateType">
        <choice>
          <element name="chg" type="secDNS:chgType"/>
          <sequence>
            <element name="add" type="secDNS:dsType" minOccurs="0"/>
            <element name="rem" type="secDNS:remType" minOccurs="0"/>
          </sequence>
        </choice>
        <attribute name="urgent" type="boolean" default="false"/>
    </complexType>

     <complexType name="selectType">
       <sequence>
         <element name="keyTag" type="unsignedShort"
                  minOccurs="0" maxOccurs="1"/>
         <element name="alg" type="unsignedByte"
                  minOccurs="0" maxOccurs="1"/>
         <element name="digestType" type="unsignedByte"
                  minOccurs="0" maxOccurs="1"/>
         <element name="digest" type="hexBinary"
                  minOccurs="0" maxOccurs="1"/>
       </sequence>
     </complexType>

     <complexType name="remType">
         <element name="select" type="secDNS:selectType"
          maxOccurs="unbounded"/>
     </complexType>

     <complexType name="chgType">
       <sequence maxOccurs="unbounded">
         <element name="select" type="secDNS:selectType"/>
         <element name="selectChg" type="secDNS:dsType"/>
       </sequence>
     </complexType>


On Oct 28, 2009, at 9:32 AM, James Gould wrote:

>  Klaus,
>  
>  Your proposal will work with one small fix of replacing </sequence> in
> remType to </choice>.    This will be backward compatible, will address the
> issue of  identifying the DS record to remove, and will support adding and
> removing more than one DS record in the same command.  I like that the chg
> still behaves like a replace, which again is backward compatible.  The only
> difference is that all four elements need to be provided (keyTag, alg,
> digestType, digest) with a rem, which I donıt believe should be a big issue.
> Does anyone see an issue with having to specify either the keyTag or all four
> elements on a rem?  The following is the schema elements with the small fix
> that I tested through with various use cases successfully.
>  
>      <complexType name="updateType">        <choice>          <element
> name="chg" type="secDNS:dsType"/>          <sequence>            <element
> name="add" type="secDNS:dsType" minOccurs="0"/>            <element name="rem"
> type="secDNS:remType" minOccurs="0"/>          </sequence>        </choice>
> <attribute name="urgent" type="boolean" default="false"/>    </complexType>
> <complexType name="remType">        <choice maxOccurs="unbounded">
> <element name="keyTag" type="unsignedShort"/>          <element name="dsData"
> type="secDNS:dsDataType"/>        </choice>    </complexType>
>  
>  The following tests worked and passed schema validation:
>  
>  
> * Passing a single add, chg, or rem with the rem containing just the keyTag.
> This is the backward compatible tests.
> * Passing multiple dsData elements for both the  add and rem elements
> * Passing multiple keyTag or dsData elements with the rem element
> *  
> 
>  
>  
>  -- 
>  
>  
>  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: Tue, 27 Oct 2009 19:38:02 -0400
>  To: James Gould <jgould@verisign.com>
>  Cc: Howard Eland <heland@afilias.info>, EPP Provreg <ietf-provreg@cafax.se>
>  Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
>  
>  On 2009-10-27 22:31, James Gould wrote:
>> [...]
>> 
>> Updated XML schema:
>>      <complexType name="remKeyType">
>>          <simpleContent>
>>              <extension base="unsignedShort">
>>                  <attribute name="alg" type="unsignedByte"/>
>>                  <attribute name="digestType" type="unsignedByte"/>
>>                  <attribute name="digest" type="hexBinary"/>
>>              </extension>
>>          </simpleContent>
>>      </complexType>
>> 
>>      <complexType name="remType">
>>          <sequence>
>>              <element name="keyTag" type="secDNS:remKeyType"
>> maxOccurs="unbounded"/>
>>          </sequence>
>>      </complexType>
>> 
>> [...]
>  
>  Hi James,
>  
>  instead of adding attributes, one could declare the content of the <rem>
> element
>  to be a choice between the <keyTag> element and the <dsData> element, with
>  unbounded repetition, e.g.
>  
>        <complexType name="remType">
>          <choice maxOccurs="unbounded">
>            <element name="keyTag" type="unsignedShort"/>
>            <element name="dsData" type="secDNS:dsDataType"/>
>          </sequence>
>        </complexType>
>  
>  Also, I propose a change to allow both <add> and <rem> to occur in the same
>  request, i.e. something like this (may be formally incorrect, haven't checked
>  the syntax):
>  
>        <complexType name="updateType">
>          <choice>
>            <element name="chg" type="secDNS:dsType"/>
>            <sequence>
>              <element name="add" type="secDNS:dsType" minOccurs="0"/>
>              <element name="rem" type="secDNS:remType" minOccurs="0"/>
>            </sequence>
>          </choice>
>          <attribute name="urgent" type="boolean" default="false"/>
>        </complexType>
>  
>  
>  Regards,
>  
>  Klaus
>  
>   
>   




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