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