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

From: James Gould <[email-masked]>
Date: Wed, 28 Oct 2009 10:32:19 -0400

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
[email-masked]
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-masked]>
Date: Tue, 27 Oct 2009 19:38:02 -0400
To: James Gould <[email-masked]>
Cc: Howard Eland <[email-masked]>, EPP Provreg <[email-masked]>
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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 29 Oct 2009 11:32:49 -0400

On Wed, Oct 28, 2009 at 10:32:19AM -0400, James Gould wrote:

> four elements on a rem? 

Can you say why you prefer to use all four elements instead of just
the digest?  The digest actually is unique, so adding the other
elements doesn't make it easier, I don't think, does it?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: Howard Eland <[email-masked]>
Date: Thu, 29 Oct 2009 10:57:38 -0500

This is what I was saying.  The digest is unique (specially when we're  
talking across only the same keytag), so the rest of the information  
is superfluous.

-Howard

---

From: Howard Eland <[email-masked]>
Date: Thu, 29 Oct 2009 12:05:57 -0500

One thing that does make using all four elements easier: it's  
consistent with both the add and chg operators, which may make it  
easier for implementors to code (well, a tiny bit, anyway).  James,  
I'm not sure if this is to your point or not.

Codifying the edge cases is important, however, and it appears that  
we'll have to lose some of this compatibility to do so (regardless if  
we use just the hash on the rem, or the entire dsData).  By requiring  
anything other than just the keyTag itself, it will not be backwards  
compatible for implementors - today, the keytag submission is  
sufficient, tomorrow, it will not be (going strictly by the RFC, not  
by registry policy).

I am no longer particular to either method - they both would be fine.

-Howard

On Oct 29, 2009, at 10:57 AM, Howard Eland wrote:

> This is what I was saying.  The digest is unique (specially when  
> we're talking across only the same keytag), so the rest of the  
> information is superfluous.
>
> -Howard
>

---

From: James Gould <[email-masked]>
Date: Thu, 29 Oct 2009 15:52:27 -0400

³One thing that does make using all four elements easier: it's
consistent with both the add and chg operators, which may make it
easier for implementors to code (well, a tiny bit, anyway).  James,
I'm not sure if this is to your point or not²

Yes, using all four elements makes it consistent with the add and chg.  The
rem could make some if not all of the 4 elements optional, but I¹m not sure
if this make things simpler or more complex for the client.

³Codifying the edge cases is important, however, and it appears that
by registry policy).²

Yes, the backwards compatibility would only be at the XML schema level.
This should be a reasonable compromise.

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Howard Eland <[email-masked]>
Date: Thu, 29 Oct 2009 13:05:57 -0400
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

-Howard

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 30 Oct 2009 12:39:00 +0100

Hi all,

trying to catch up on the e-mails of yesterday, I'd like to summarize the state 
of the discussion as far as I understand:

1) it is a little bit unclear to me whether we still want to create an update of 
RFC 4310 that is fully backward compatible, XML-wise and mostly semantically.

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.

3) there is a consensus that as of RFC 4310, the <chg> is a replace-all 
operation, i.e. all existing DS records are removed completely and independently 
from the data provided and the provided DS records are added.

4) there is a disagreement of how to interpret a 
<rem><keytag>1234</keytag></rem> in the case that multiple DS records with this 
key tag have been provisioned earlier. One choice is to reject the operation, 
the other is to remove all DS records matching the key tag. There is a third 
choice of removing the the <keytag> element at all.

5) there is a disagreement of how to repair the <rem> element. One choice is to 
use the existing "dsDataType", with the semantics that it must match exactly an 
existing DS record, otherwise the request will fail (questionable though what an 
exact match is). The other choice is to create a separate "selectType" datatype 
which contains optional elements only. All existing DS records are tested 
against the respective element. If a key tag, algorithm, digest type or digest 
has been specified, the respective component must match, otherwise the DS record 
is retained. While easy to define, still unknown what happens if no DS records 
match or a DS record matches multiple "selectType" instances.

6) if we break backward compatibility, the <keyData> element can be revisited. 
It is unclear to me whether registries exist that would prefer to have the key 
data *instead* of the DS data and not *in addition*.

Please feel free to correct me if I misunderstood something.

-------

Now my further comments:

* If we break compatibility, then we should consider removing either <add>/<rem> 
or <chg> for the sake of symmetry to the base EPP standards and extensions. As 
far as I understand the Scott Hollenbeck's design pattern, there is *either* a 
replace-all/change strategy *or* an add/remove strategy on a certain data 
element. For example, the registrant contact adheres the "change" strategy, 
while the other contacts adhere an add/remove strategy. RFC 4310 breaks it.

* I am a little bit undetermined regarding the "selectType" approach. While it 
is a nice idea, it is also some kind of novelty in the EPP world. As far as I 
can remember, always the same datatype has been used for both the removal and 
addition. Of course, not in all cases all data fields have been used for 
comparison. For example, I assume no registry implementation will check the 
human readable text and the language for a removal of a status value, while it 
is possible to specify it. Also, I don't see that much the use cases. IMHO the 
most frequent use will be the KSK rollover, and for that purpose, this 
flexibility is not required.

* regarding 4), the <keytag> element, I think the least trouble is to allow the 
removal of multiple DS records, but still rejecting the request, if no DS record 
is found at all.

Regards,

Klaus

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Oct 2009 10:39:46 -0400

Hi,

On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote:

> 1) it is a little bit unclear to me whether we still want to create an 
> update of RFC 4310 that is fully backward compatible, XML-wise and mostly 
> semantically.

My impression was that we _do_ need at least an update that allows old
clients to continue to work, and will allow new clients to work with
old servers.  I haven't figured out whether it's possible to make the
necessary schema changes and still be technically backward compatible,
though I'm leaning toward "no".  That will mean a bump in the schema
version.  Such a bump would be an even stronger reason to make it
operationally backward compatible.

I attach a -00 version as a scratch proposal.  The draft submission
window is closed due to the upcoming Hiroshima meeting, so I'm posting
it here.  Anyway, this doubtlessly needs changes before really being
submitted.

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

RFC5731 says, "Commands are processed by a server in the order they
are received from a client."  But in this case these aren't actually
different commands, and I have so far been unable to convince myself
that a server operator has to process the elements of one command in
the order in which those elements appear.  If someone knows otherwise
(and I would be very much pleased to have such proof), I'd like to
hear it.  But as things stand, my reading is that a server operator
could handle all the <add> elements first, and all the <rem> elements
second, and the effect of that could be quite different than what
we're trying to achieve.

> <rem><keytag>1234</keytag></rem> in the case that multiple DS records 
> with this key tag have been provisioned earlier. One choice is to reject 
> the operation, the other is to remove all DS records matching the key 
> tag. There is a third choice of removing the the <keytag> element at all.

I have candidate text for this now.  In order to make this backward
compatible, one has to accept it in the protocol.  I have written the
text so that by registry policy, sich an operation can nevertheless be
rejected. 

> 5) there is a disagreement of how to repair the <rem> element. One choice 
> is to use the existing "dsDataType", with the semantics that it must 
> match exactly an existing DS record, otherwise the request will fail 
> (questionable though what an exact match is). The other choice is to 
> create a separate "selectType" datatype which contains optional elements 
> only. All existing DS records are tested against the respective element. 

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.

Comments are welcome.

Best,

A

---

From: James Gould <[email-masked]>
Date: Fri, 30 Oct 2009 11:08:16 -0400

Klaus,

Thanks for the summary of the topic.  I personally liked the schema updates
that you had proposed with the added text around returning an error for use
of the existing <rem><keyTag> method when more than one DS record matches
and clarity around the use of the <chg>, so my responses are pretty much in
line with that proposal below.

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Klaus Malorny <[email-masked]>
Date: Fri, 30 Oct 2009 07:39:00 -0400
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

Hi all,

trying to catch up on the e-mails of yesterday, I'd like to summarize the
state
of the discussion as far as I understand:

1) it is a little bit unclear to me whether we still want to create an
update of
RFC 4310 that is fully backward compatible, XML-wise and mostly
semantically.

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.

I agree the <add> and <rem> should be allowed at the same time.  This makes
it consistent with the other EPP RFC¹s.  If <add> and <rem> were supported
at the same time, if we could uniquely identify each DS record, and if we
weren¹t worried about backward compatibility, then the <chg> option could be
removed.  

3) there is a consensus that as of RFC 4310, the <chg> is a replace-all
operation, i.e. all existing DS records are removed completely and
independently
from the data provided and the provided DS records are added.

In it¹s current form, for the current specification to work, the <chg> needs
to be interpreted as a replace  all.  Having to split an update with
multiple DS across multiple commands, is not a good practice and increases
the risk of domains be published in an in-the-middle invalid state.

4) there is a disagreement of how to interpret a
<rem><keytag>1234</keytag></rem> in the case that multiple DS records with
this
key tag have been provisioned earlier. One choice is to reject the
operation,
the other is to remove all DS records matching the key tag. There is a third
choice of removing the the <keytag> element at all.

I believe that it should be reject if there is a mechanism to uniquely
identify a DS record.  We are planning on deleting all of the matching DS
records with the current specification, which is one of the areas of
confusion that I would like to be fixed.  EPP should be explicit to what the
client really wants to do, so I¹m in favor of rejecting if there is
ambiguity and we¹re supporting the existing form of <rem> for backward
compatibility.  This is at list backward compatibility from an XML schema
perspective.  

5) there is a disagreement of how to repair the <rem> element. One choice is
to
use the existing "dsDataType", with the semantics that it must match exactly
an
existing DS record, otherwise the request will fail (questionable though
what an
exact match is). The other choice is to create a separate "selectType"
datatype
which contains optional elements only. All existing DS records are tested
against the respective element. If a key tag, algorithm, digest type or
digest
has been specified, the respective component must match, otherwise the DS
record
is retained. While easy to define, still unknown what happens if no DS
records
match or a DS record matches multiple "selectType" instances.

I prefer just using the dsDataType since there should be no question related
to matching the DS.  I don¹t believe that there should be two DS records for
a domain with the same four elements (keyTag, alg, digestType, and digest)
and the registry should ensure this.  There is the very remotely possibility
of having more than one DS record with the combination of a subset of the
elements.  Although I agree the likelihood of duplicate digest values is
statistically impossible.  I don¹t see any huge advantage to use a subset of
the elements since it leaves no ambiguity.  Supporting the existing
<rem><keyTag> scheme for backward compatibility should return an error when
more than one DS records matches if the dsDataType scheme is supported.

6) if we break backward compatibility, the <keyData> element can be
revisited.
It is unclear to me whether registries exist that would prefer to have the
key
data *instead* of the DS data and not *in addition*.

We are not planning on supporting the optional <keyData> element.

-------

Now my further comments:

* If we break compatibility, then we should consider removing either
<add>/<rem>
or <chg> for the sake of symmetry to the base EPP standards and extensions.
As
far as I understand the Scott Hollenbeck's design pattern, there is *either*
a
replace-all/change strategy *or* an add/remove strategy on a certain data
element. For example, the registrant contact adheres the "change" strategy,
while the other contacts adhere an add/remove strategy. RFC 4310 breaks it.

* I am a little bit undetermined regarding the "selectType" approach. While
it
is a nice idea, it is also some kind of novelty in the EPP world. As far as
I
can remember, always the same datatype has been used for both the removal
and
addition. Of course, not in all cases all data fields have been used for
comparison. For example, I assume no registry implementation will check the
human readable text and the language for a removal of a status value, while
it
is possible to specify it. Also, I don't see that much the use cases. IMHO
the
most frequent use will be the KSK rollover, and for that purpose, this
flexibility is not required.

* regarding 4), the <keytag> element, I think the least trouble is to allow
the
removal of multiple DS records, but still rejecting the request, if no DS
record
is found at all.

Regards,

Klaus

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Oct 2009 11:37:38 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, October 30, 2009 10:40 AM
> To: EPP Provreg

[snip]

> 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.)
> 
> RFC5731 says, "Commands are processed by a server in the 
> order they are received from a client."  But in this case 
> these aren't actually different commands, and I have so far 
> been unable to convince myself that a server operator has to 
> process the elements of one command in the order in which 
> those elements appear.  If someone knows otherwise (and I 
> would be very much pleased to have such proof), I'd like to 
> hear it.  But as things stand, my reading is that a server 
> operator could handle all the <add> elements first, and all 
> the <rem> elements second, and the effect of that could be 
> quite different than what we're trying to achieve.

The answer to this question is implicit in the understanding of how XML
Schema works.  As currently specified, the <add> and <rem> elements are
part of a <choice>.  Only one can appear, so there's no ordering issue.

If the <choice> is changed to a <sequence>, the order will be specified
in the schema.  If you don't want the order to matter, use <all>.  I
would like to suggest that a sequence makes more sense if you want to
avoid issues related to processing order.

Scott

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Oct 2009 11:57:44 -0400

On Fri, Oct 30, 2009 at 11:37:38AM -0400, Hollenbeck, Scott wrote:
> Schema works.

Aha, well, this is obviously where I fell down.

> avoid issues related to processing order.

Ok, cool.  This is terribly helpful.  Expect the next iteration to
include this strategy, then.

Thanks!

A

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 30 Oct 2009 18:30:50 +0100

> Hi,

Hi Andrew,

>> 2) there is a consensus that<add>  and<rem>  elements shall be allowed in
>> the<chg>  element.
> Are we sure that the<add>  and<rem>  elements have to be processed in

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.

> written, but I think James has convinced me there'd be no harm in

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

Regards,

Klaus

---

From: Howard Eland <[email-masked]>
Date: Fri, 30 Oct 2009 12:58:25 -0500

On Oct 30, 2009, at 12:30 PM, Klaus Malorny wrote:

> 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.
>
> By the way, as there seems to be some confusion: IMHO the order in  
> the XML document should *never* imply any order of execution.

Yes and no - that's _exactly_ what <sequence> is for - to prescribe a  
predetermined order via XML.

If we follow RFC5731 (see below), using domain status as in Klaus'  
example, then the correct thing to do is declare update child elements  
as a <sequence>, with add first, then rem.  The RFC is silent beyond  
that, so I would assume that this means the server must execute all  
adds in any order, then execute all rems in any order, then execute  
all chgs in any order.

    <!--
    Child elements of the <update> command.
    -->
    <complexType name="updateType">
     <sequence>
       <element name="name" type="eppcom:labelType"/>
       <element name="add" type="domain:addRemType"
        minOccurs="0"/>
       <element name="rem" type="domain:addRemType"
        minOccurs="0"/>
       <element name="chg" type="domain:chgType"
        minOccurs="0"/>
     </sequence>
    </complexType>

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

---

From: James Gould <[email-masked]>
Date: Fri, 30 Oct 2009 14:27:08 -0400

³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 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Klaus Malorny <[email-masked]>
Date: Fri, 30 Oct 2009 13:30:50 -0400
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

Hi Andrew,

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.

> written, but I think James has convinced me there'd be no harm in

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

Regards,

Klaus

---

From: Howard Eland <[email-masked]>
Date: Fri, 30 Oct 2009 13:37:01 -0500

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

> 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.
>
>
> update
> the XML

---

From: James Gould <[email-masked]>
Date: Fri, 30 Oct 2009 14:52:15 -0400

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 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Howard Eland <[email-masked]>
Date: Fri, 30 Oct 2009 14:37:01 -0400
To: James Gould <[email-masked]>
Cc: Klaus Malorny <[email-masked]>, EPP Provreg
<[email-masked]>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

> ³If this "select" solution is taken, I don't mind whether it is implemented

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

> 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