Re: 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
[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 07:39:00 -0400
To: EPP Provreg <[email protected]>
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 [email protected]