[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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


Home | Date list | Subject list