RE: [ietf-provreg] Registry Escrow Information as EPP Spec?

["Dan Maharry" <dan@mcd.coop>]

Andrew,

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
something here? Obviously, it makes sense to take backups in your native
database format as well, but the nice thing about XML is that it is
universal so everyone can use it. I agree that the current escrow
specifications for any regsitry wouldn't provide enough information for
a system rebuild but isn't that why the issue should be addressed?

Regarding the registrar as epp object thought, I saw that dotAero
uses\used the Payload 2.0 protocol rather than EPP prior to swapping
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.

On the reserved domains idea - I was referring to those ICANN puts on a
reserved list rather than anything else - I take your point. Scott, I
take yours too.

Dan


-----------

Dan Maharry
Technical Manager, 
Midcounties Co-operative Domains Ltd
-----Original Message-----
From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]
On Behalf Of Andrew Sullivan
Sent: 21 February 2006 16:41
To: ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] Registry Escrow Information as EPP Spec?

On Tue, Feb 21, 2006 at 04:02:10PM -0000, Dan Maharry wrote:

> the registry coming up this year, it seems an excellent time to 
> address the escrow schema ICANN gave us last time which was actually 
> invalid for several reasons.

Aside from the XML problems with the escrow spec, I have the reservation
that the escrow requirements (or at least, the ones I've had to comply
with) wouldn't actually allow one to rebuild the registry if one were
reduced to using it.  My own view is that it is inadequate, therefore.

But that's really more of a contractual issue, and not a strict matter
of EPP.  It seems to me that you _could_ represent most of the content
of an EPP-provisioned registry simply by outputting all of the EPP
commands necessary to generate the content of the registry. 
Whether the storage required for that would be worth the bother is a
matter of policy, it seems to me.

>  - With the escrow information for registrars almost identical to that

> for domains, hosts and contacts, why aren't registrars regarded as EPP

> objects.

I think because using "registrars" is probably a local policy issue. 
I can't imagine anyone would be opposed to seeing an object mapping for
registrars, but I might be wrong about that.  I'd be very surprised,
however, if anyone wanted to put such a document on the standards track.
(On the other hand, we already have a standards-track document for the
ICANN RGP policy, so maybe people would like such a draft.  But keep in
mind that the point of the protocol is interoperation.  I presume that
nobody except your own staff creates registrars in your registry.  Of
course, perhaps a registry registrars is what we need, in which case
interoperation would seem to be an issue.)

>  - Should reserved domain names be regarded as domains in EPP as well?

> I would have thought Yes.

Again, since the point of the protocol is not to specify policy, you
could handle this however you like.  One could argue that a combination
of serverDeleteProhibited and serverUpdateProhibited (and maybe
serverRenewProhibited?) amounts to a "reserved" domain name. 
But in any case, if you need more, that is what extensions are for.

A

--
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew@ca.afilias.info>                              M2P 2A8
                                        +1 416 646 3304 x4110


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________