Subject: [ire] High level requirements for Internet Registration Data Escrow

From: Francisco Arias <[email-masked]>
Date: Thu, 11 Feb 2010 00:00:54 -0800

If we were to start from the beginning, i.e., the requirements; what do you
think about the list below as an starting point for high level requirements?

A solution for Internet Registration Data Escrow SHALL:

1. Define the format of Full and Incremental Deposits of Registration
Objects that a Registration Organization submits periodically to an
independent third party (the Escrow Agent) for its custody.

2. Allow a Registration Organization (different to the one making the
Deposits) to rebuild the Registration Services of the former in a timely
manner, with minimum harm to the users of those services (e.g., Registrants,
Registrars, Internet users, etc.) using only the Deposits from the Escrow
Agent.

3. Provide a format for Deposits with mechanisms that allow its
extensibility to accommodate new and extended Registration Objects.

4. Use authentication, confidentiality and integrity mechanisms when
transferring the Deposits to and from the Escrow Agent.

5. Support internationalization of "social" data (e.g., contact names,
addresses) in Registration Objects.

6. Identify parameters that are a matter of policy, e.g., frequency and type
of Deposits (Full or Incremental), the set of Registration Objects to
deposit, the time the Deposits have to be kept in custody.

Registration Organization would mean whatever we decide to be in our scope.
Looking horizontally: TLD registries, RIRs, routing registries; or
vertically: Registries, Registrars, Resellers, etc.

Regards,

__ 
Francisco

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 11 Feb 2010 08:20:40 -0800

>From earlier comments on this list, it seems clear that there will be different views about what should and should not be in the deposits. Also, it seems likely that these formats are also useful for self-escrowing, not just with third-party agents. So, I think that should be:

Define a base format for Deposits of Registration Objects that a Registration Organization submits to an Escrow Agent for storage and possible later retrieval. The base format will have an extension mechanism for adding one or more sets of data to different types of Deposits.

>Registrars, Internet users, etc.) using only the Deposits from the Escrow

What kind of "harm to the users" are you thinking of?

>extensibility to accommodate new and extended Registration Objects.

This should not be a second format; it needs to be part of the base format, as indicated above.

>transferring the Deposits to and from the Escrow Agent.

There was not strong agreement that we should define the protocol for moving Deposits around. If a Deposit is a single blob, specifying a mandatory protocol is (typical IETF) overkill. For example, if we specify a client-server protocol, we need to specify how clients both push and pull Deposits from "servers" who really are supposed to mostly be repositories. Do I need to run this protocol just to store my own Deposit on a secured hard drive?

I strongly suggest we leave this item out completely.

>addresses) in Registration Objects.

This is way too limited in scope: *all* text data should be Unicode characters. The IETF would never produce a spec in 2010 without that, so I think it can either be left unsaid. If you really want to say this, append to the first item "All text data in a Deposit is encoded in UTF-8" and be done with it.

>deposit, the time the Deposits have to be kept in custody.

Why? Of what value would that be to the protocol?

>vertically: Registries, Registrars, Resellers, etc.

This seems unnecessarily limited to the current ICANN model. How about "Registration Organizations include DNS zone administrators, IP address administrators, Internet route administrators, and businesses affiliated with them".

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 12 Feb 2010 11:28:11 +0100

On Thu, Feb 11, 2010 at 08:20:40AM -0800,
 Paul Hoffman <[email-masked]> wrote 
 a message of 57 lines which said:

> I strongly suggest we leave this item [authentication,
> confidentiality and integrity mechanisms] out completely.

I strongly agree.
 
> This is way too limited in scope: *all* text data should be Unicode
> characters.

I also agree. Do note it conflicts with the current ICANN requirments
which say (why?) that the escrow of IDN must be done in ASCII :-(

---

From: Daniel Kalchev <[email-masked]>
Date: Fri, 12 Feb 2010 12:49:09 +0200

> This seems unnecessarily limited to the current ICANN model. How about "Registration Organizations include DNS zone administrators, IP address administrators, Internet route administrators, and bus…
I would rather not limit the scope to even this list of organizations.

The escrow data format should ideally be suited for storing and 
retrieving arbitrary 'operational' and 'administrative' information. 
Example operational information would be the domain names and list of 
nameservers, DNSSEC keys etc, while administrative information would be 
all ownership, contact information etc. that is attributed to the 
operational information.. Perhaps there could be another type of 
information, sort of metadata to link them all.

Having the protocol usable outside 'internet registries' will make it 
more widely adopted in the internet-based business practice.

In my opinion, the more important consideration is whether the escrow 
protocol will be interactive, like EPP (which might just do the job), or 
more storage oriented. In the latter case the object format might well 
be opaque and understandable only to the specific source.

Daniel Kalchev
Register.BG

---

From: Edward Lewis <[email-masked]>
Date: Fri, 12 Feb 2010 09:15:59 -0500

>A solution for Internet Registration Data Escrow SHALL:

I would also extend escrow to include data used to operate Internet 
services, for example in an RIR: DNS, WhoIs, Billing, Registration, 
RWhoIs, IRIS, etc.

Where this comes from is the desire to reconstitute a registration 
entity's function by another in a timely manner.  Database schema and 
contents are vital, but there are other pieces of information needed.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 12 Feb 2010 15:43:01 +0100

Ideally it would also include  (non-standard) applications used by
the registry, specific configuration files etc.

	jaap

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 12 Feb 2010 15:59:48 +0100

On Fri, Feb 12, 2010 at 03:43:01PM +0100,
 Jaap Akkerhuis <[email-masked]> wrote 
 a message of 13 lines which said:

> the registry,

And the Oracle licence used by the previous registry :-)

---

From: Daniel Kalchev <[email-masked]>
Date: Fri, 12 Feb 2010 17:51:15 +0200

> And the Oracle licence used by the previous registry :-)
This may be serious security issue -- Internet registries might be 
destroyed for their software licenses. :)

Is there portable way to store applications? Not with their intended 
hardware, I hope.

How about the documentation needed to operate the software? Processes 
flowcharts..

Daniel

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Feb 2010 10:14:20 -0800

>which say (why?) that the escrow of IDN must be done in ASCII :-(

This conflict is a non-issue. If one user of the registry wants to make more restriction in their profiles, they can.

At 12:49 PM +0200 2/12/10, Daniel Kalchev wrote:
>>...snip...
>>... include DNS zone administrators, IP address administrators, Internet route administrators, and businesses affiliated with them".
>

I support widening beyond my list, but not too far. There is no such thing as "generic escrow".

>The escrow data format should ideally be suited for storing and retrieving arbitrary 'operational' and 'administrative' information. Example operational information would be the domain names and list of nameservers, DNSSEC keys etc, while administrative information would be all ownership, contact information etc. that is attributed to the operational information..

Fully agree. This is precisely why I want the extensibility to be in the primary requirement.

> Perhaps there could be another type of information, sort of metadata to link them all.

That would be the schema.

>Having the protocol usable outside 'internet registries' will make it more widely adopted in the internet-based business practice.

But having a base spec that is too generic will prevent it from being useful to the core audience. We can't know ahead of time which way to tip the balance.

>In my opinion, the more important consideration is whether the escrow protocol will be interactive, like EPP (which might just do the job), or more storage oriented. In the latter case the object format might well be opaque and understandable only to the specific source.

My preference is towards storage-oriented because all interactive protocols impose access policies, and we have no idea to what extent the escrow agents want to (or are allowed to!) release the data they are storing. But having an "opaque format" is silly: we already have those now.

>the registry, specific configuration files etc.

Absolutely.

--Paul Hoffman, Director
--VPN Consortium

---

From: Edward Lewis <[email-masked]>
Date: Fri, 12 Feb 2010 14:28:56 -0500

>And the Oracle licence used by the previous registry :-)

In an ideal world, whether one registry uses commercial database 
product one and the other uses schools of trained dolphins, it 
shouldn't matter so long as the registration activity can be 
supported from escrow.  (Ok, in an ideal world, the dolphins will be 
feeding us fish for swimming through hoops.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Christopher Browne <[email-masked]>
Date: Fri, 12 Feb 2010 15:36:12 -0500

Edward Lewis <[email-masked]> writes:
> shouldn't matter so long as the registration activity can be supported
> from escrow.  (Ok, in an ideal world, the dolphins will be feeding us
> fish for swimming through hoops.)

This points at the important point that the format be abstracted enough
away from the deepest darkest details of the activity, whether those be
software licenses, billing policies, or whatever else.

It seems to me that it's a mighty good thing to abstract things enough
that the form is NOT shackled to be identical to individual
implementations.

This may mean that the data carried over gets carried in a rather
"lossy" fashion.

It's legitimate to feel some discomfort about that - but if I was taking
over a registry, I'd be uncomfortable with having every bit of legacy
policy forced on my implementation.  It's a good thing to lose some of
the mistakes, especially if they contributed to the failure.
-- 
output = reverse("ofni.sailifa.ac" "@" "enworbbc")
Christopher Browne
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"

---

From: Francisco Arias <[email-masked]>
Date: Mon, 15 Feb 2010 02:04:20 -0800

> What kind of "harm to the users" are you thinking of?

Basically loss of service, but also malfunction ... caused by missing,
incomplete or simply unintelligible data in the Escrow Deposits.
 
> This should not be a second format; it needs to be part of the base format, as

I didn't mean there should be two formats. I guess I didn't expressed it
correctly. I agree with you, Paul, it should be and extensible format,
that's it.

> characters. The IETF would never produce a spec in 2010 without that, so I
> think it can either be left unsaid. If you really want to say this, append to
> the first item "All text data in a Deposit is encoded in UTF-8" and be done
> with it.

ok
 
> Why? Of what value would that be to the protocol?

Not to the protocol, but to the implementers. I believe the spec should
indentify parameters that are matter of policy so the implementers of a
"Data Escrow engagement" (e.g., ICANN, a registry, an Escrow Agent) would
know a list of parameters they need to define to have something actually
usable.

__ 
Francisco

---

From: Francisco Arias <[email-masked]>
Date: Mon, 15 Feb 2010 02:04:28 -0800

> services, for example in an RIR: DNS, WhoIs, Billing, Registration,

I agree.

> contents are vital, but there are other pieces of information needed.

Ed, what other pieces of information?

__ 
Francisco

---

From: Francisco Arias <[email-masked]>
Date: Mon, 15 Feb 2010 02:04:24 -0800

> the registry, specific configuration files etc.

Jaap, what do you mean by including applications used by the registry?

__ 
Francisco

---

From: Francisco Arias <[email-masked]>
Date: Mon, 15 Feb 2010 02:05:38 -0800

On 2/12/10 10:14 AM, "Paul Hoffman" <[email-masked]> wrote:
>> protocol will be interactive, like EPP (which might just do the job), or more
>> storage oriented. In the latter case the object format might well be opaque
>> and understandable only to the specific source.
> 
> My preference is towards storage-oriented because all interactive protocols
> impose access policies, and we have no idea to what extent the escrow agents
> want to (or are allowed to!) release the data they are storing. But having an
> "opaque format" is silly: we already have those now.

I agree with Paul, storage-oriented makes more sense for Data Escrow. It
solves the problem and it is much more easier to implement than interactive.

I also agree about the format, it has to be pre-defined (vs. opaque) to
allow a different organization to rebuild the services of the original
organization without help from it.

__ 
Francisco

---

From: Francisco Arias <[email-masked]>
Date: Mon, 15 Feb 2010 02:05:58 -0800

On 2/12/10 10:14 AM, "Paul Hoffman" <[email-masked]> wrote:
>>> ... include DNS zone administrators, IP address administrators, Internet
>>> route administrators, and businesses affiliated with them".
>> 

In principle I agree we have to somewhat limit the type of organizations
that may find useful the spec but I do not know how to describe that. Do you
have an idea Paul?

__ 
Francisco

---

From: Francisco Arias <[email-masked]>
Date: Mon, 15 Feb 2010 02:06:11 -0800

On 2/11/10 8:20 AM, "Paul Hoffman" <[email-masked]> wrote:
> There was not strong agreement that we should define the protocol for moving
> Deposits around. If a Deposit is a single blob, specifying a mandatory
> protocol is (typical IETF) overkill. For example, if we specify a
> client-server protocol, we need to specify how clients both push and pull
> Deposits from "servers" who really are supposed to mostly be repositories. Do
> I need to run this protocol just to store my own Deposit on a secured hard
> drive?
> 
> I strongly agree.

I didn't mean to specify a transport protocol for the Deposits and yes, I
agree that transporting a physical media to the Escrow Agent is a
possibility we need to consider.

What I tried to say is that the spec has to define something the involved
parties (registries and Escrow Agent) have to do in order to authenticate
that the information comes from the right party, it is only readable by
whomever is authorized (e.g., the Escrow Agent) and that the Deposits are as
the depositing registry produced them.

For example, the spec could require the Deposits to be digitally signed and
encrypted.

__ 
Francisco

---

From: Francisco Arias <[email-masked]>
Date: Mon, 15 Feb 2010 02:06:22 -0800

> that the form is NOT shackled to be identical to individual

I agree with Christopher, the definition of the objects comprising the data
should be abstract and implementation independent; we should care about the
data needed to run the services not about the way they used to be run.

__ 
Francisco

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 15 Feb 2010 11:33:16 +0100

On Mon, Feb 15, 2010 at 02:06:11AM -0800,
 Francisco Arias <[email-masked]> wrote 
 a message of 39 lines which said:

> What I tried to say is that the spec has to define something the
> involved parties (registries and Escrow Agent) have to do in order
> to authenticate that the information comes from the right party,

No, I disagree. The spec has to explain (that's a good idea for the
Security Considerations section) what are the risks associated with
the transport and the possible solutions. But not to mandate a
specific solution.

As you said, "I believe the spec should indentify parameters that are
matter of policy so the implementers of a "Data Escrow engagement"
(e.g., ICANN, a registry, an Escrow Agent) would know a list of
parameters they need to define to have something actually usable."

> For example, the spec could require the Deposits to be digitally
> signed and encrypted.

Overspecification. I suggest instead a Security Considerations section
with something like:

The escrowed data could be read in transit by unauthorized
third-parties. If it is an issue, a possible solution is to encrypt
the escrowed data for the transport, using solutions like [RFC 4301]
or [RFC 5246].

It is important for the Escrow Agent to check that the escrowed data
is really the authentic one. The Agent may consider the use of digital
signatures like in [RFC 4880].

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 15 Feb 2010 11:50:58 +0100

As quoted above, I said none-standard applications. Lot's of TLDs
have requirements to the registration process which are beyond what
is needed for running a nameserver and register a name. Things that
deal with what that Ed calls "other pieces of information needed".

I one wants to restore a registry from the escrowed data and not
change the operation that piece is needed as well.

	jaap

---

From: Francisco Arias <[email-masked]>
Date: Tue, 16 Feb 2010 08:10:36 -0800

> parameters they need to define to have something actually usable."

Why not? 

I understand your point about policy parameters, but I think the question of
the confidentiality, integrity and authenticity of the information involved
in Data Escrow is of such importance that a solution has to be specified.

__ 
Francisco

---

From: Francisco Arias <[email-masked]>
Date: Tue, 16 Feb 2010 08:17:52 -0800

> change the operation that piece is needed as well.

Do you mean extra data (wrt EPP schemas) required by some registries in
order to accept a registration (e.g., identity document number) or data
needed to run services different to basic DNS resolution (e.g., directory
information like in .TEL)?

__ 
Francisco

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 17 Feb 2010 12:15:33 +0100

Both. Whatever is needed to reconstitute the registry to it's
original state (I made the remark in that context) and function.

When the goal is just to keep the status quo of a registered domains,
it is likely that less data will suffice.

	jaap

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 17 Feb 2010 11:48:37 +0000

Hi Japp, Francisco, folks,
  This has moved the scope a LOOOONG way from Registry data.

For .tel, the directory information stuff is just delegated zone provisioning.
For users, .tel is a standard "delegation only" TLD, so the registry doesn't hold this data.

Did you mean to include standard delegated zone provisioning (of the child zone content) in the Escrow specs?

all the best,
  Lawrence

On 17 Feb 2010, at 11:15, Jaap Akkerhuis wrote:
> _______________________________________________
> ire mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ire

---

From: "Marc Groeneweg" <[email-masked]>
Date: Wed, 17 Feb 2010 12:54:27 +0100

Dear all,

> child zone content) in the Escrow specs?
SNAP

It's the standard definition between a thin registry and a fat registry.
As a thin registry, one only handles delegation information, nothing
else. I guess in this case, the Escrow data is almost the same as the
zonefile contents (and probably the registrar who registered the
domainname).

As a fat registry, one also handles contact information. Most registries
(no gTLD's I guess) are of this type. And it's not only the data, also
the policies which are modeled in the registry operation. Local policies
like privacy issues are built in the processing of the domainname
registration. I believe this is what Jaap mentions and makes a point of.

Regards,

Marc Groeneweg

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 17 Feb 2010 13:34:24 +0100

Yes, it has moved into discussing "what is the problem we want to
solve with this". In other words, what are the High level requirements
for Internet Registration Data Escrow?

	jaap

---

From: "Michael Young" <[email-masked]>
Date: Wed, 17 Feb 2010 08:17:41 -0500

Policies and proprietary schemas are outside the scope basic escrow data
services. This is not about trying to reconstitute a registry operator in
situ, its about basic disaster recovery.  What is the minimum required data
to reconstitute a working/functioning registry? Certainly the specification
MUST support extensions and MUST allow one to describe data relationships,
as there are many customized versions of registries. (I think the current
draft already provides for both). However, how those data relationships are
executed in a operational schema design is entirely up to new Operator
reconstituting the registry.  There are many ways to approach a schema
design to achieve the same data relationship.

The original goal in this discussion seemed to be to have a generic object
that could represent optional submissions like a copy of the registry
software (if the operator was so inclined).  I believe this could already be
handled through the proposed extension framework.

I also think we should agree on the scope and tasks of this working group as
a starting point. Otherwise we are bound to drift sideways on objectives.

Best Regards,

Michael Young

Vice-President,
Product Development
Afilias
O: +14166734109
C: +16472891220

-----Original Message-----
From: Marc Groeneweg [mailto:[email-masked]] 
Sent: February-17-10 6:54 AM
To: [email-masked]
Subject: Re: [ire] High level requirements for Internet Registration
DataEscrow

Dear all,

SNAP

Regards,

Marc Groeneweg

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Feb 2010 09:18:44 -0500

>Ed, what other pieces of information?

For instance - DNS configuration information (the DNS "data-driven" 
portion is derived from the database contents but the stuff that is 
usually in static "config" files is not).

Perhaps it also depends on what one considers the database - but 
there is billing information (account balances, stuff other than 
expiration dates, etc.) that may be stored elsewhere.

I usually view a registry of consisting of the following roughly 
defined interfaces and protocols:

Administrative -> Billing, legal support (think law enforcement...)
Provisioning -> The registration "desk" (like EPP)
Relying Party -> DNS (DN/RI-R), WhoIS other inspection protocols

The information needed to set up these "external" interfaces are also 
needed - if the goal is to reconstitute and continue operations and 
not just "re-host the database."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Feb 2010 09:44:21 -0500

>a starting point. Otherwise we are bound to drift sideways on objectives.

And this is the time to start and do that.  The BoF meeting coming 
(still officially unapproved but James and I have slipped into the 
Apps Area list of chairs) in Anaheim will be a public "hearing" so to 
speak on setting the objectives.

One item to present and discuss at the meeting is a would-be WG 
charter.  That's a given.  I think it might be constructive to have 
some short "show-and-tells" from registries describing what they 
think belongs in escrow.

One of the questions to consider, is the goal of the effort to:
   Allow a thick registry be reconstituted in a thin registry operator?

Registries operate under a lot of policies (we have some registries 
that have oodles of rules to follow), complying with these policies 
is core to "continued operations."  How does this relate?

BTW - We run a few gTLDs and they are thick.  (To answer one comment 
on the list made a few days ago.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: James Gould <[email-masked]>
Date: Thu, 18 Feb 2010 11:31:13 -0500

Ed,

>    Allow a thick registry be reconstituted in a thin registry operator?

I don¹t believe we should consider the target operator system, but focus on
storing all of the provisioning data in a consistent and secure manor no
matter what makes up the Registry system.  I agree that there should be some
requirements around additional information that needs to be deposited to
make the data usable for reconstituting a system, but I want to ensure that
the format is extensible, simple, and straight forward for a target operator
to utilize.  For example, I wouldn¹t want to not include information in the
data escrow because it is Registry specific and was not defined in the RFC.
The target operator should be able to count on at least an agreed upon
subset of information to work with.

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Feb 2010 09:44:21 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: [ire] BoFfing...

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Feb 2010 21:49:09 -0500

>zonefile contents (and probably the registrar who registered the

The comment above is tailored to domain name registries.  In a thin 
registry the information to be put in the DNS is stored as well as 
the sponsoring registrar (using the ICANN environment terminology). 
For that, the escrow data would be the DNS stuff plus at least the 
sponsor stuff.

>(no gTLD's I guess) are of this type.

As this caused some confusion (expressed to me privately) - Neustar 
for one operates gTLDs under a (we prefer) "thick" model.  (Fat is 
not a "positive" term. ;))

>And it's not only the data, also

The policies, I think that is open for debate.  I'm not questioning 
the statement here, but I am not convinced whether the policies are 
in the escrow or not.  It might be that the "goal is to reconstitute 
the registry" is an overstatement of what we need to be able to 
achieve.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Daniel Kalchev <[email-masked]>
Date: Fri, 19 Feb 2010 09:21:00 +0200

On 19.02.10 04:49, Edward Lewis wrote:
> the statement here, but I am not convinced whether the policies are in 
> the escrow or not.  It might be that the "goal is to reconstitute the 
> registry" is an overstatement of what we need to be able to achieve.
In my opinion, this is the most important point, that should be 
discussed before creating any working group to handle any design task.

What is the purpose of the escrow data? So far, there have been two 
opinions:

1. Registry data should be sufficient to facilitate takeover of the 
registry. With possible change in business practices. Apparently, the 
zonefile itself is not. This is why, other mechanisms are sought.

2. Registry data should be sufficient to restore the state of the 
registry in case of failure, with the goal that registry users 
(registrars, direct registrant interface, others) is not affected.

I would like to point out, that in some countries there are laws that 
govern 'database ownership'. It may be unlawful to allow third party to 
obtain and operate whatever database, without prior consent (and what 
not else, according to the law). This makes the first option, although 
very much desired by some, unlikely to happen in this world. No matter, 
how ICANN is trying to enforce it.

Clarifying this issue will help greatly focus on appropriate data model.

Daniel Kalchev
Register.BG

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 19 Feb 2010 10:40:52 +0100

The policies, I think that is open for debate.  I'm not questioning
    the statement here, but I am not convinced whether the policies
    are in the escrow or not.  It might be that the "goal is to
    reconstitute the registry" is an overstatement of what we need
    to be able to achieve.

Yes, it is open for debate and needs to be debated. It should be
clear what escrow will give you and what not. In various circles
data escrow is often seen as the silver bullet which will fix (all
possible) registry failures.

I really won't like to see that this effort creates the wrong
expectations.

	jaap

---

From: James Gould <[email-masked]>
Date: Fri, 19 Feb 2010 09:19:14 -0500

Daniel ,

It sounds like option #2 is an extension of option #1, where restoration of
the registry without impact to clients means that the data is sufficient to
facilitate takeover of the registry.  I believe that the goal of the escrow
is to deposit the critical sponsorship information so that another registry
could be created based on the data.  Items like business policies and other
features built into the software of the original registry I don¹t believe is
part of the data escrow.  Otherwise all of the source code and libraries
would have to escrowed as well, which I believe is out of scope.

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Daniel Kalchev <[email-masked]>
Date: Fri, 19 Feb 2010 02:21:00 -0500
To: <[email-masked]>
Subject: Re: [ire] High level requirements for Internet
RegistrationDataEscrow

Daniel Kalchev
Register.BG

---

From: "Marc Groeneweg" <[email-masked]>
Date: Fri, 19 Feb 2010 15:28:36 +0100

All,

I tend to incline with the statement of James. Only the data should be
escrowed, not the policies built into the software/processes. When one
wants to ensure this, separate Escrow agreements should be made,
regarding the software and procedures needed to support those policies.
So, it's the question of the data. You have the information necessary to
create a zonefile. No discussion on this I guess ;-) The sponsoring
information is also needed (who is the original source concerning the
domainname).

Extensible (or needed?) is other information like registrant, admin and
tech contacts (at least). I see a need for an extension for legal
attributes (or any other attributes a TLD has a need for)  within the
DataEscrow.

Regards,

Marc

From: [email-masked] [mailto:[email-masked]] On Behalf Of
James Gould
Sent: vrijdag 19 februari 2010 15:19
To: Daniel Kalchev; [email-masked]
Subject: Re: [ire] High level requirements for
InternetRegistrationDataEscrow

Daniel ,

It sounds like option #2 is an extension of option #1, where restoration
of the registry without impact to clients means that the data is
sufficient to facilitate takeover of the registry.  I believe that the
goal of the escrow is to deposit the critical sponsorship information so
that another registry could be created based on the data.  Items like
business policies and other features built into the software of the
original registry I don't believe is part of the data escrow.  Otherwise
all of the source code and libraries would have to escrowed as well,
which I believe is out of scope.   

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary
and/or Registry  Sensitive information intended solely for the recipient
and, thus may not be  retransmitted, reproduced or disclosed without the
prior written consent of  VeriSign Naming and Directory Services.  If
you have received  this e-mail message in error, please notify the
sender immediately by  telephone or reply e-mail and destroy the
original message without making a  copy.  Thank you.

________________________________

Daniel Kalchev
Register.BG

---

From: [email-masked]
Date: Fri, 19 Feb 2010 15:45:08 +0000

> not just "re-host the database."

So the first question seems to be "What are the minimum set of services 
(and level of services) that an organisation can offer and still be 
classed as a registry?".  From this we can derive the core data we need to 
store in escrow.

As a first step, focusing on what we can't do without may be easier than 
reaching a conclusion on what we could do with.

Stephen

---

From: Christopher Browne <[email-masked]>
Date: Fri, 19 Feb 2010 12:24:56 -0500

James Gould <[email-masked]> writes:
> It sounds like option #2 is an extension of option #1, where
> restoration of the registry without impact to clients means that the
> data is sufficient to facilitate takeover of the registry.  I believe
> that the goal of the escrow is to deposit the critical sponsorship
> information so that another registry could be created based on the
> data.  Items like business policies and other features built into the
> software of the original registry I don?t believe is part of the data
> escrow.  Otherwise all of the source code and libraries would have to
> escrowed as well, which I believe is out of scope.

I'm inclined to go even a little further than that.

I'm don't think that "without impact to clients" is particularly
plausible.  Nitpicking a little bit, if there's a new service provider,
then:

 - IP addresses will have changed for services.

 - authentication information will need to change so that clients are
   assured that they're dealing with "NewOperatorCo," and not
   "OldFailedOperatorCo."

 - clients are dealing with a different legal entity, and hence it is
   likely to be rather important for there to be *new* legal contracts
   and such.

In that there has been a catastrophic failure, clearly something
undesirable has happened, and it is undesirable to assume carriage of
*every* detail of business policy over to the new operator, as the
catastrophe may well have resulted from some aspects of those policies.

This isn't a "seamless" change - nay, it's pretty important to validate
that expected "seams" have been observed, otherwise there are risks of
fraud.

I don't imagine that much of the "legacy" billing information would be
able to apply to the new organization.  A new registry operator, being a
separate legal entity, needs to establish *new* contractual arrangements
with the clients.  In view of that, while it is essential for there to
be sufficient client data to be able to identify and contact the
clients, I would expect other sorts of "billing data" to effectively be
invalidated by a takeover.
-- 
(format nil "~S@~S" "cbbrowne" "ca.afilias.info")
Christopher Browne
Database Architect
Afilias Canada

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 22 Feb 2010 09:57:15 +0100

On Fri, Feb 19, 2010 at 09:21:00AM +0200,
 Daniel Kalchev <[email-masked]> wrote 
 a message of 36 lines which said:

> registry. With possible change in business practices.

Yes, this is what escrow is for.

> Apparently, the zonefile itself is not.

Of course not. It lacks info about the registrants, for instance.

> registry in case of failure,

I do not really understand the difference between the two. For me,
there is "escrow" (allowing a *different* organisation to restore the
registry in face of a *business* failure) and "backup" (allowing the
*same* organisation to restore the registry in face of a *technical*
failure). Only escrow is on-topic here.

Whether the takeover was because of a hostile redelegation or because
of a bankruptcy or alien invasion is immaterial: escrowing always
assume that the old registry won't be here to help so the new registry
has only the escrowed data. (And, of course, being the IETF, we should
work on technical issues, not on political ones such as "should the
law mandate an escrow for the local ccTLD?")

> I would like to point out, that in some countries there are laws
> that govern 'database ownership'. It may be unlawful to allow third
> party to obtain and operate whatever database, without prior consent
> (and what not else, according to the law).

I work in such a country but I do not see your point. Escrowing is not
stealing data, it is storing data at a trusted third-party, to allow a
future registry to resume service. It is a frequent requirment for
TLDs (for instance, for .FR, it is a legal obligation, so that the
governement can start a new .FR registry, should the AFNIC employees
leave with the money, settle in Cayman Islands and drop the service).

> No matter, how ICANN is trying to enforce it.

ICANN is irrelevant here.

---

From: Daniel Kalchev <[email-masked]>
Date: Mon, 22 Feb 2010 15:46:12 +0200

I think we should avoid mixing 'data' with 'business practices'. The 
escrow is about data.

Whatever the reasons for failure of entity A, it's operation should be 
restored by entity B 'fully'.

Here is the problem: we don't have any definition of what the particular 
registry does.

Therefore 'keep the database license' and 'we don't need any billing 
data' may be both valid, even at the same time.

either settle on the minimum necessary to operate an registry (whether 
DNS registry or other, doesn't matter)

On 19.02.10 19:24, Christopher Browne wrote:
> plausible.

This is what is most desirable. If it can be achieved, depends on not 
only having good enough specifications, but also on uncertain factors, 
such as good will and diligence.

>   - IP addresses will have changed for services.
These days people use domain names. So this might not be valid argument.

>     assured that they're dealing with "NewOperatorCo," and not
Yes, and no. It all depends on the 'business practice' of the new 
operator and should be outside of the scope of this working group.
>     likely to be rather important for there to be *new* legal contracts
Same as above. There might not be any legal contract in the first place 
at all. Or, like most mass services, the registry might operate under 
General Terms and Conditions.
> invalidated by a takeover.
Correct. But this does not mean we should eliminate the 'billing data' 
property. Whether or not the new operator will use this data is not 
important. They may no use (parts of) it even out of ignorance.

What worries me however, is we spend more time discussing non-technical 
issues. :)

Best Regards,
Daniel Kalchev
Register.BG Ltd

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Feb 2010 07:25:02 -0800

At 3:46 PM +0200 2/22/10, Daniel Kalchev wrote:
>I think we should avoid mixing 'data' with 'business practices'. The escrow is about data.

You can avoid mixing data with business practices, and still have both in an escrow object. Assuming that the object is encoded in a hierarchical format (JSON, ASN.1, XML, ...), you have one section be for data and one for business practices.

>From a spec standpoint, we can more tightly define the data part than the business practices part. Having said that, *both* parts should be fully extensible.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Vika Mpisane" <[email-masked]>
Date: Tue, 23 Feb 2010 09:50:08 +0200

Sorry for my late comments to this interesting discussion. See below.

> From: Stephane Bortzmeyer [mailto:[email-masked]]
> Sent: 22 February 2010 10:57 AM

> law mandate an escrow for the local ccTLD?")

I get your point here Stephane. As much as data escrow may be political,
depending on how you look at it, an entity like IETF would do well to
constrain itself to the technical how-tos & procedures. 

> leave with the money, settle in Cayman Islands and drop the service).

I fully agree here as well. Data escrow is purely about data protection.
Typically, whatever a country's law says about database ownership, data will
still need to be escrowed. I'm from South Africa & there's an electronic
communications law that classifies certain databases as critical. Assuming
that .za registry database is critical, the law itself encourages data
protection measures, and I see escrow as being such a measure.

Regards,

Vika Mpisane
.ZA Domain Name Authority
Johannesburg, South Africa
+27 11 275 0082

---

From: Edward Lewis <[email-masked]>
Date: Tue, 23 Feb 2010 12:25:34 -0600

At 21:49 -0500 2/18/10, Edward Lewis wrote:

>It might be that the "goal is to reconstitute the registry" is an
>overstatement of what we need to be able to achieve.

I think that the above statement might have caused us to miss something.

I do doubt that we want to escrow everything that is known by a 
registry (that includes policies and billing for examples).  What is 
misleading is that the applicability of the escrow "protocol" 
probably should be broader than registries - that is - including 
registrars (especially in thin models) and other involved parties.

So I'll throw the doors open on this, perhaps we want to look for the 
information needed to reconstitute the core knowledge of the 
registration entity elsewhere in case of failure.  It's not the 
replication of the entity (like one registry operator assuming the 
role for a registry who's operator has failed) but being able to keep 
stability in the Internet.

I'd also like to repeat that we might be looking outside of just the 
domain name registration activity on this.

OTOH, I am not saying that we want a universal vault that will hold 
RIR data and domain name registration data - just a format that is 
available.  And consider whether there are parallels between 
registrar/registry and LIR/RIR in all this.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Francisco Arias <[email-masked]>
Date: Wed, 24 Feb 2010 01:00:08 -0800

I fully agree with James, we should focus on what the current registry has
to escrow (as much as possible) and let conversions from thick to thin be a
problem for the successor registry.

__ 
Francisco

On 2/18/10 8:31 AM, "James Gould" <[email-masked]> wrote:

> requirements around additional information that needs to be deposited to make
> the data usable for reconstituting a system, but I want to ensure that the
> format is extensible, simple, and straight forward for a target operator to
> utilize.  For example, I wouldn¹t want to not include information in the data
> escrow because it is Registry specific and was not defined in the RFC.   The
> target operator should be able to count on at least an agreed upon subset of
> information to work with.

---

From: Francisco Arias <[email-masked]>
Date: Wed, 24 Feb 2010 01:10:20 -0800

I believe we first need to define our scope horizontally (Domain names, RIR
objects, routing objects, etc.) and vertically (registries, registrars/LIRs,
DNS zone administrators, IP address administrators, Internet route
administrators, etc.) and then work on defining the minimum set of services.

Without the scope definition it doesn't seem possible to define this set, if
ever will.

__ 
Francisco

On 2/19/10 7:45 AM, "[email-masked]"
<[email-masked]> wrote:

> So the first question seems to be "What are the minimum set of services (and
> level of services) that an organisation can offer and still be classed as a
> registry?".  From this we can derive the core data we need to store in escrow.
>