Re: Registry Escrow Information as EPP Spec?

Andrew Sullivan <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <[email protected]>
On Thu, Feb 23, 2006 at 11:00:59AM -0000, Dan Maharry wrote:
> Shouldn't the point of escrow be that if a registry did stop
> functioning, another system could pick up the escrow document and use it
> to rebuild that regidtry with the minimum of fuss? Or am I missing

Yes.  Which is why I'm uncomfortable with the escrow spec as it is:
it covers some, but not all, of the registry data, which means that
"rebuild the registry" is not actually something you can do from a
conforming escrow deposit set.  Since I'm a bit of a data geek,
that's the sort of thing that worries me.

But note the problem with doing this in XML: for any largish database
with heavy traffic, you're already looking at _at least_ megabytes of
deposit data.  I'm not totally convinced that the benefits of XML in
this instance outweigh the considerable additional cost in
chattiness.

> registry operator which includes operations on registrar objects. It
> occurred to me that either an EPP extension to match that or just a new
> registrar object could make that Payload to EPP mapping easier? And then
> it would also make the creation of an escrow document easier - just
> calling <registrar:info> for each registrar object in your database
> makes some sense.

I'm certainly not opposed to this idea; but there are going to be a
lot of repository-specific data that need to be captured in this
object, I expect.  (For instance, I can imagine a repository for
more than one top level domain, where the registrar objects are
shared.  That would require quite an extensive permissions system, I
imagine.)  Which returns us to the observation that this is exactly
what extensions are for.  But if someone were to write an I-D for a
registrar object mapping, I suppose some people would review it.  

A
-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email protected]>                              M2P 2A8
                                        +1 416 646 3304 x4110
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.