Re: Lists and EPP

At 11:13 +0100 6/8/11, Jim Reid wrote:

>Yes, an industry-wide standarised way to do this kind of thing would of
>course be good Patrik.

First let's put the cart and the horse in the right sequence.  First 
solve the problem and then worry about making the solution generally 
applicable.  Before that (zeroth?) define and scope the problem.

If "one of the first question I get every time I meet registrars is 
'How can I get a list of all my domains?'" really is something common 
across registries, this sounds like a worthwhile topic to take on. 
Solving real problems is a lot more fun than making them up. ;)

In the "it seems to me" column, efforts with the goal of finding a 
standard solution usually die on the vine.  Efforts that attack the 
problem regardless of generalization yield better fruit from which we 
can extract a more general solution.

>I'm not convinced EPP is the tool to use though. Not every registry
>and registrar speaks EPP.

That's a valid point ("the tool to use") but the issue isn't that it 
isn't ubiquitous.  No one is prevented from adopting EPP or deploying 
it as an interface, but anyone is free to not adopt it.

>There could be icky implementation issues too: eg locking the database while
>something ploughs through it to generate the list. [We can't have the database
>changing while the list is generated, eh?] I fear this could be the start of a
>slippery slope as more SQL reporting type stuff gets shoe-horned into EPP:
>"gimme a list of all the domain names I registered for this contact that then
>got transferred to that registrar over the last N months", "which domains I
>manage reference this nameserver (or contact) object?".

What's to fear isn't the slippery slope.  There's no rules for what 
any protocol can or can't be made to do.

The analysis needed (and Jim begins it) is first to identify the 
strengths and weaknesses of EPP.  Besides its functional abstract, 
how well does it do the job in certain situations and how poorly does 
it do the job in others.  Then any alterations to the protocol had 
better not weaken its strong points.  Alterations should highlight 
the strong points.

EPP is a registrar-registry protocol.  Its role is entering 
provisioning data.  The two are not the same.  How well does it 
handle high latency operations?

Why has IRIS failed to bloom?  Why did it fail where EPP succeeded? 
Maybe there are clues there pointing out how EPP might be able to do 
this.

Maybe this is a fit for EPP.  But maybe it isn't.  Just because EPP 
was built for one use case (provisioning) doesn't mean it has to 
stick to that.  The "E" stands for Extensible after all.

>Perhaps a BCP might be a better approach than an EPP extension?

Remember that code trumps spec in the IETF.

(Die on the vine, yield fruit, IRIS blooming...hmm maybe I should 
take the rest of the day off and tend to a garden.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg