Re: [ietf-provreg] registries, XML & EPP (again)

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

Edward Lewis wrote:
> At 18:01 +0200 10/18/05, Klaus Malorny wrote:
> 
>> while EURid has updated their specs in a thankworthy way, this still 
>> has a slightly bad aftertaste, as even the namespace of the framing 
>> XML (i.e. the "urn:ietf:params:xml:ns:epp-1.0" namespace) was required 
>> to be changed due to ...
> 
> What bothers me is that there is a second instance of a registry, in 
> this other case, avoiding EPP and instead building their own protocol.  
> I am not making a judgement call on the wisdom of prefering a home grown 
> effort over a standard, but rather am concerned that the standard wasn't 
> "good" enough for them.
> 
> See: 
> http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-enum-epp.pdf 
> 
> 
> The talk is somewhat mistitled in the agenda, why DENIC didn't use EPP 
> for ENUM.  The reason is simply that DENIC doesn't use EPP for 
> anything.  (;))  From slide 7 onwards though is the interesting stuff - 
> why DENIC doesn't use EPP for anything.
> 
> This is a cry for "use the IETF for what it is for."  I would hope to 
> see a detailed critique outlining why EPP is failing to meet the needs 
> of the community come in, and not a feeling that EPP should be shunned.  
> The definition of EPP by the IETF is not to be taken as a royal edict.  
> It should be the collective wit and wisdom of us wise guys.


Hi Edward,

being a member of the technical advisory committee of DENIC, I strongly 
supported the decision of DENIC to implement its own protocol and not EPP, and I 
can explain why. At the time the decision was made, EPP was still in the draft 
state, and the underlying model of EPP was just incompatible with the DENIC 
model, most notably the inability to deal with a "hostless" structure. In 
following drafts EPP became more flexible regarding this (via the hostAttr 
element). However, still today there are quite a lot differences in the models, 
starting at additional contact fields, multiple registrant contacts per domain, 
different transfer mechanisms and requirements and special commands, like the 
transit or changeholder commands. A possible EPP solution would be either to 
adopt the generic EPP model or to build a large set of extensions for EPP to 
allow the representation of DENIC's model as EPP. The first case would not only 
have had a large impact to DENIC itself, but to all DENIC registrars as well. 
Large amounts of money would have been burnt for the developments at DENIC and 
the registrars, and the transition from the DENIC model to the EPP model would 
not have been an easy one. The other solution would have had the clear 
disadvantage that every single XML element added as an extension of EPP 
diminishes the benefit of EPP, namely to have a generic interface that can be 
used with a generic toolkit and a generic registrar software. Any solution 
in-between merely inherits the disadvantages and not the advantages of both 
solutions.

Sorry to say that, but in the beginning of the provreg working group Scott and 
others of the gTLD faction were just too confined to the Verisign model and 
fully ignored the ccTLDs, their needs and their models. IMHO this discouraged 
many ccTLDs from participating. EPP is indeed "extensible", but in some aspects 
just not at all.

While I think it is reasonable that existing registries go their own way in 
dealing with registry protocols for their own benefit and the benefit of their 
registrars and customers, I believe that new registries should adopt EPP with as 
few extensions as possible and with a registry model as compatible as possible, 
even though I do not consider myself as a big friend of EPP. Therefore I am 
disappointed that EURid did not manage to provide a cleaner EPP implementation 
within two years or so, but using the very same concepts of the .be registry.

regards,

Klaus


___________________________________________________________________________
      |       |
      | knipp |                   Knipp  Medien und Kommunikation GmbH
       -------                           Technologiepark
                                         Martin-Schmeißer-Weg 9
      Dipl. Inf. Klaus Malorny           44227 Dortmund
      Klaus.Malorny@knipp.de             Tel. +49 231 9703 0