Subject: [ietf-provreg] Presentation on EPP present and future

From: Patrick Mevzek <[email-masked]>
Date: Wed, 23 Jun 2010 21:00:57 +0200

Hello,

I've done last monday in the ICANN ccNSO
tech day a presentation on my current view of EPP, based on the
extensions seen in the wild, and what could be future works on EPP
with some data on the 60+ extensions I've seen, and choices among EPP
"options" (host as attribute or contact, contact data, etc.)

You can find the presentation online here:
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-icann-brussels-ccnso-techday-201006/index.html
or if you want just the text as PDF:
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-icann-brussels-ccnso-techday-201006/netdri-future-epp-icann-brussels-ccnso-techday-201006.pdf

While the attendance was high, there has not been any real feedback
at that time on the relevance on working again on EPP or even, as
stated in my presentation, to try at least to make people (from
registries, registrars, and outside developers such as myself) to
collaborate together, starting with extensions documentation and
public announcements.

Hope that helps.

-- 
Patrick Mevzek
Dot and Co <http://www.dotandco.com/> <http://www.dotandco.net/>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: "Michael Young" <[email-masked]>
Date: Thu, 24 Jun 2010 01:20:46 +0200

As far as I understand the process to initiate further EPP work in the IETF
would focus on a) defining a problem and subsequent scope of work  b)
garnering support from the relevant area director  c) following the process
of initiating a working group - mailing list where clear efforts are
demonstrated, BOF, etc OR another option is to file an informational RFC.

Its been said before, but I'll say it again, EPP is an Extensible protocol.
Given its flexibility, I have yet to hear an argument as to why existing
issues cannot be addressed using the extension system.

If a valid argument can be made, I am happy to support additional efforts on
the base protocol, as of yet, I have not seen one.

Best Regards,

Michael Young

-----Original Message-----
From: Patrick Mevzek [mailto:[email-masked]] 
Sent: June-23-10 9:01 PM
To: EPP Provreg
Subject: [ietf-provreg] Presentation on EPP present and future

Hello,

You can find the presentation online here:
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-ica
nn-brussels-ccnso-techday-201006/index.html
or if you want just the text as PDF:
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-ica
nn-brussels-ccnso-techday-201006/netdri-future-epp-icann-brussels-ccnso-tech
day-201006.pdf

Hope that helps.

---

From: Wil Tan <[email-masked]>
Date: Thu, 24 Jun 2010 10:31:29 +1000

> demonstrated, BOF, etc OR another option is to file an informational RFC.
I missed Patrick's presentation at the ccNSO tech day, but did read the
draft that he circulated a while ago.

>From my perspective, the main problem with how the implementations have
evolved is a loss of interoperability. IIRC, in the case of CZNIC, complete
schemas were defined to replace the standard domain and contact mappings,
reducing EPP into not much more than a framing protocol. Not sure exactly
the rationale for doing that, though I'm sure considerable thoughts have
been put into it. It does mean that registrars could not easily reuse
existing libraries or code written for one registries to talk to another
though.

> issues cannot be addressed using the extension system.
See above. Also, I believe there are some minor tweaks that could be done to
the existing schema that would make less inherent assumptions about the
registry data model (by making some fields optional). However, I don't any
way to handle schema changes in a backwards compatible manner.

Working along the lines of defining new mapping encompassing common use
cases would perhaps be worth pursuing and more productive than attempting to
change the core protocol. Patrick's work would certainly come in handy in
that case.

wil.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 24 Jun 2010 07:43:31 +0200

> issues cannot be addressed using the extension system.

The overall problem is that it is extensible. The amount of new code that has to be written for each registry is a royal pain, and an indication the protocol in reality is not interoperable at all.

So, I think the big question is:

- Is there a goal to get interoperable implementations?

If so, the ability to extend must be _decreased_ a lot.

Example of things that must be agreed upon:

- The format accepted for various attribute values (telephone numbers, names etc)

- What happens in detail with various related records when a domain is transferred

...

Just look at the number of special hacks in the perl library for example.

If that is not a goal, so that code has to be rewritten for each registry, then of course we have a base protocol that "works".

   Patrik

---

From: Ulrich Wisser <[email-masked]>
Date: Thu, 24 Jun 2010 09:30:17 +0200

Hello,

EPP is in fact *very* extensible. The problem (in my opinion) is that 
most registry are really new to EPP when they start to develop an EPP 
server. At that point it is very easy to get lost in an extension 
frenzy. And once the whole server is build around the new schema it 
almost impossible to revert to standard schema.

Then there is the part that EPP does not support business objects. There 
are no accounts, no registrar objects, no billing data, ...

EPP has no way of specifying registry rules, e.g. max. number of ns per 
domain, ...

The nice thing about all the extensions in the wild is, that we are now 
seeing real world business needs for EPP. We could try to filter out a 
common set of extensions needs and create one or more new standard 
extensions.

I can see a bunch of work for a WG here.

/Ulrich

-- 
Help building the worlds most comprehensive list of judo dojos.
Put your dojo on the list at http://JudoWorldMap.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: James Gould <[email-masked]>
Date: Thu, 24 Jun 2010 11:28:36 -0400

I agree with Ulrich.

I believe that it¹s impossible for all of the registries to agree on a
single business model and a single way of doing things.  Compromise had to
be made even with the standard mappings (hostObj/hostAttr, thick/thin, etc.)
with the use of optional features, so over time additional business ideas
will naturally result in new extensions.  It is the technologist¹s
responsibility to try to meet the business needs without causing interface
issues like updating the base mappings themselves, without creating new
mappings for the same mapping objects, and without creating required
extensions except for specific cases.  Every registry has had it¹s own
unique set of requirements.  The ability of EPP to define new mappings is
extremely useful and I don¹t believe is at issue.  We could look to create
standard mappings for Registry objects like Registrar, User, Registrar
Contact, and billing if needed.  It¹s the extensions made to the standard
mappings that is of most interest for combining and standardization.   I¹m
not a fan of updating the base mappings unless there is a compelling reason
to do so, but instead focus on the set of extensions that have been created
for consolidation. 

As stated in the EPP BOF extensions are not evil but a natural result of
using EPP for different business models.  There is no way that we¹re all
going to agree on a single business model, but it would be a useful exercise
to work on some standard set of extensions.

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
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: Ulrich Wisser <[email-masked]>
Date: Thu, 24 Jun 2010 03:30:17 -0400
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Presentation on EPP present and future

Hello,

/Ulrich

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 24 Jun 2010 11:45:09 -0400

> common set of extensions needs and create one or more new standard  

One way to tackle this would be for someone to put together
draft-epp-common-profile that would outline the extensions (including
-- or not -- the base domain, host, contact extensions) that support
the widest interoperation.  That is not actually a change to the
protocol as such, though it is of course an overall change to the
operating protocol as deployed.

I think it would be very helpful to have a draft that one could
discuss, however.  But since I work for neither a registry nor a
(real) registrar, I'm not offering to write it.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.