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

[Klaus Malorny <Klaus.Malorny@knipp.de>]

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


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