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

[James Gould <jgould@verisign.com>]

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

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 

-------------------------------------------------------
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 07:39:00 -0400
To: EPP Provreg <ietf-provreg@cafax.se>
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.

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


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