To:
ietf-provreg@cafax.se
From:
Andrew Sullivan <andrew@ca.afilias.info>
Date:
Mon, 27 Feb 2006 10:49:27 -0500
Content-Disposition:
inline
In-Reply-To:
<97D835CEC713134BB0980951BB3238A004896DAF@nbhex1.osgcs.local>
Mail-Followup-To:
Andrew Sullivan <andrew@ca.afilias.info>,ietf-provreg@cafax.se
Reply-To:
Andrew Sullivan <andrew@ca.afilias.info>
Sender:
owner-ietf-provreg@cafax.se
User-Agent:
Mutt/1.5.11
Subject:
Re: [ietf-provreg] Registry Escrow Information as EPP Spec?
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
<andrew@ca.afilias.info> M2P 2A8
+1 416 646 3304 x4110