RE: [ietf-provreg] EPP Document Updates

[Edward Lewis <Ed.Lewis@neustar.biz>]

At 13:13 -0400 8/4/05, Ram Mohan wrote:

>We should consider re-initiating the provreg group.  A number of changes are
>due in EPP, and enough registries are now using EPP that actual practice has
>exposed both issues and deviances from the protocol.  Further, registries
>have implemented extensions that, in some cases, make more sense to be part
>of a standard -- the case of what happened with RGP is relevant here.

I think it's clear that there's a demand (as in supply and demand) 
for coordination of work involving the EPP protocol.  However, I 
don't think there's  justification for an IETF-style working group.

I think there are maybe three factors that prevent the EPP documents 
from being the epitome of perfection.

1) They were produced by humans.  (Meaning errata are needed.)
2) The audience of interest grew as the specifications were put to RFC.
    (Meaning that elements were designed for domain specific applications.)
3) The protocol is supposed to be extensible and future looking.

These are three reasons why there is a demand for EPP coordination. 
But is this demand best met by an IETF WG?

Reason #1 is fairly self-explanatory, a number of textual edits have 
been identified.  If RFC documents were "living" these changes would 
have been made without thought.  An IETF WG isn't needed for this.

Reason #2 is a bit more telling of the culture of the IETF and why I 
think an IETF-style WG might not be the correct path at this moment. 
The IETF isn't the right venue to attract interest of registries. 
For example, CENTR has a higher concentration of attendees that have 
applicable experience and interest in what is happening in EPP now. 
There was a time in which EPP development needed the input of other 
protocol engineering experts.

EPP has an extension mechanism that separates the process of adding 
new messages to the protocol from issue dealing with security and 
transport.  During the IETF run, we had to wrestle with the question 
of whether we could define SMTP as a transport for EPP elements - we 
decided no for various reasons.  This is an IETF question.  How to 
encode ENUM validation data into EPP is much less of a question that 
needs input from, say, the SMTP experts.

I'm sure another run of the PROVREG WG would gather a different and 
probably more well-rounded set of participants than the first try. 
But still, there is no guarantee that we get who we need.

Reason #3 is based on the existence of the final RFC of the original 
EPP documents (3735 I think).  Basically, there is a statement from 
the WG on how to proceed with extensions.  I don't believe this is 
enough, certainly, but I can't imagine how an IETF WG would improve.

For one, just because guidelines are documented doesn't mean that 
"generations" of following implementers will grok and comply fully. 
My other experience is in DNS - looking closely at that I see there 
was about a decade between the original specifications and the 
beginning of a "reformation" in which the ad hoc coding practices had 
"voided" some of the basic assumptions about the DNS.  The result is 
a plethora of badly written code screaming for backwards 
compatibility.

Another factor here is that there are a need to reign in on some 
extension efforts.  Sometimes there is too much freedom to expand and 
you wind up with a bloated protocol.  E.g., let's say each of the 200 
or so registries out there decides to extend EPP in some unique way. 
It's the registrars that suffer trying to maintain a client code base 
with the 200 or so unique extensions.  I don't think this is an 
effort suited to the IETF, especially because it is operations (and 
market) based.

What would be a good reason to reconvene an IETF (style) WG?   A 
reason that requires an engineering solution, a reason that requires 
cross-checking with other protocol domain engineers.

I liked the CENTR meeting that happened the day before the IETF in 
Paris.  It was a dedicated registry meeting yet co-located with the 
IETF engineering meetings.  I realize that CENTR is not the open 
forum that the IETF is, and it is not the only interested party, but 
it is a good example and has a significant  concentration of interest 
in EPP.  To emphasize this one more time - CENTR's meeting is an 
example of a non-IETF group that resulted in some interesting talk on 
EPP.  An example.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.