Re: [ietf-provreg] a question for the list

[Patrick Mevzek <[e-mail]>]

Edward Lewis <[e-mail]> 2010-01-14 18:23
> EPP is also growing in deployments.  Early it was the registration  
> protocol for the ICANN shared registry model but it has been spreading to 
> other registries that are not subject to ICANN's overview.  With less 
> "evidence" on hand, a few registries have had to modify something to get 
> an EPP interface.  I suspect that some of the extensions have not been 
> published as RFCs (which is fine, but, it would be nice).

I confirm (as an EPP client implementor of more than 30 extensions)
that almost all EPP extensions have NOT been published as
RFCs, even as drafts except for a few exceptions, most of the times
unmaitained. Worse than that, as other have said, not all EPP
extensions specifications are available publicly.

> Based on this, I wanted to ask the audience of this list if they thought 
> it would be a good idea to organize a new WG to cover EPP.  

Maybe. Depending on the goals, and indeed on the global reach of
participants to avoid the previous case where ccTLDs have seen EPP as
a purely gTLD thing, before entering the arena with 5 to 10 years of
useless delay.

> I can imagine extensions being discussed here, as well as trying to  
> promote the existing ones to Draft and Full.  Also, a document that  
> discusses what could have been done better in EPP (as maybe a  
> requirements to EPP 2.0).

Some of you may recall one of my posting on this list more than one
year ago (!) with a link to some notes I've made as an implementor,
seeing many extensions of various qualities, and the rationale being
them being sometimes some shortcomings in the current EPP.

The document is still at
http://www.deepcore.org/ietf/draft-mevzek-epp-implementor-experience-00.txt
but I've not worked on it since then. It could be used as a base.

Also in light of the recent DNSSEC discussions, please have a look at
§3.3.2 that deals with some kind of EPP extensions used by some
registries (.CZ and .EU if I recall correctly) for handling key
materials.

And about using EPP for non provisioning operations, see §3.8.3

> So - the question here is - is there interest?

I really believe there are two separate points that may not be good
to deal at the same time in the same place even if there is some
overlap:

- discussion/work on an EPPv2, taking into account some current
shortcomings (such as static list of status codes, domain name
status, contact types ; handling of clTRID, etc... see my draft)

- enhancement of the current state of EPP, without changing its core,
but by taking into account all current extensions and trying to
persuade all stakeholders to work together to make some superseeding
extensions with some factorizations and enhancements (again see my
draft). Or at least producing some strong advises/recommandations to
extensions creator, as RFC3735 is a good starting point but is not
enough.

I'm personnally interested to contribute in both of them, 
but I do not have a lot of free time to invest in them.
I do fear however that,
specially for the second point, even if there is indeed a lot of work
to do technically (meaning that I think many extensions could be made
better), there is a reduced probability that it would be useful in
the sense that, specially without broad participation by the
extension creators themselves, there would be no motivation to change
the current extensions as they are already deployed and working even
if not perfect.
While there was and still is a pressure for some ccTLDs to finally
switch to EPP, in part by their registrars, I do not believe there
will be the same kind of pressure to switch to "better" extensions,
because all serious registrars already adapted their software to take
into account the unavoidable fact that with each TLD there are
specific procedures and extensions to deal with.

-- 
Patrick Mevzek
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [e-mail]