Subject: [ire] Separation of data sets / another aspect (testability)

From: Bernie Hoeneisen <[email-masked]>
Date: Sat, 20 Feb 2010 12:02:46 +0100 (CET)

Hi,

After reading all the emails another aspect crossed my mind:

- It is (hopefully) unlikely that we can properly test the
   restoration of a Registry in real life. So we can never
   conclusively proove what is the set of data absolutely needed in
   case of restoration. This means implementations will be based on
   assumptions, as we can never test them under real circumstances.

- As a consequence we should logically separate the set of data
   we believe is absolutely needed for restoring Registry
   operations and any additional data that might be of importance.
   The later should be escrowed too, although unlikely to ever be
   used.

Thus, there should be one set of data to be specified "both
ways" (tuned for fast restoration, primary usage), and another
set of data "one way" (tuned for storage/retrieval, secondary
usage).
[Whether of not the "tuning" matters at the end of the day is FFS.]

The former can be tested to a certain extent (at least I hope so... ;-) ), 
the latter might get too complex for proper testing.

cheers,
  Bernie

---

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

I agree with Bernie about the difficulty for testing but, maybe we could learn from slightly similar experiences. For example there have been a few cases of TLDs that have been transitioned from one operator to another; .ORG and .CO come to my mind at this moment.

I know the aforementioned cases are not strictly compared to a transition in which only escrowed data is available, but at least those who had the experience of rebuilding registry services of those TLDs may want to share their experiences about what data and policies (if any) were needed to rebuild.

__
Francisco

On 2/20/10 3:02 AM, "Bernie Hoeneisen" <[email-masked]> wrote:

Hi,

cheers,
  Bernie
_______________________________________________
ire mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ire

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 24 Feb 2010 17:33:04 +0000

Hi Francisco, folks,
 You could always ask Ed about the provider transition of .us and how smoothly that went.
all the best,
  Lawrence

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 24 Feb 2010 13:23:00 -0500

I managed the VeriSign side of the .org data transition from VeriSign to
Afilias.  The short answer is that we provided them with a database dump
that included the thin registry data and table structures.  There was no
formal exchange of policy information.
 
Someone from Afilias will have to describe what it took to reconstitute
things on their side.  They were up and running soon afterwards, and
both teams agreed that the transition went very well.
 
Scott

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Francisco Arias
	Sent: Wednesday, February 24, 2010 3:44 AM
	To: [email-masked]
	Subject: Re: [ire] Separation of data sets / another aspect
(testability)

	I agree with Bernie about the difficulty for testing but, maybe
we could learn from slightly similar experiences. For example there have
been a few cases of TLDs that have been transitioned from one operator
to another; .ORG and .CO come to my mind at this moment.
	
	I know the aforementioned cases are not strictly compared to a
transition in which only escrowed data is available, but at least those
who had the experience of rebuilding registry services of those TLDs may
want to share their experiences about what data and policies (if any)
were needed to rebuild.
	
	__ 
	Francisco

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 25 Feb 2010 14:46:57 +0100

On Wed, Feb 24, 2010 at 12:43:48AM -0800,
 Francisco Arias <[email-masked]> wrote 
 a message of 154 lines which said:

> those who had the experience of rebuilding registry services of
> those TLDs may want to share their experiences about what data and
> policies (if any) were needed to rebuild.

My colleague Olivier Guillard provided this summary about the
transition of .TF:

I have conducted the .tf migration from adamsnames
to AFNIC in 2004.

The information to read is here:

http://www.nic.tf/news/20041103.en.html
http://www.adamsnames.tc/tf.html

This is a report that Adamnames and AFNIC wrote together to
inform the community once the redelegation was done.

Be to be a bit more precise about operational actions, you first
have to consider the context :

Of course, .tf was not a very big zone (only several thousand
domains), so the operational pressure was relative : I had in
mind that, at the end, manual actions in the migration process
would be acceptable in such a situation.

I suspect that guys working on .org are not the same situation :)

Also, relations with adamsnames were very good, they were very
cooperative and since I was the beneficiary at the end, I considered
that it was my job to ensure the transition from the data structure
provided by adamsname to the data structure our data model.
We worked in real confidence with Martin and Sean from adamsnames,
at the end, that is in my view at least as important as anything
else to perform a good job.

Last main thing : there were no real AFNIC business plan behind the
.tf redelgation since AFNIC didn't plan to bill the domain name holders
at that time. I didn't have any constraint on that field.

My main focus in the process was really to ensure DNS continuity.

THIS BEING SAID, HERE IS A SUMMARY OF WHAT WE HAVE DONE AT THE END :
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

- Adamsnames has furnish three spread sheets with various
  administrative data :

  foreach domain : registration and invoice dates,
                   an "adamsnames-handle" for each domain contacs:
                              (registrants,admin,billing and tech)
                   authoritative servers

  foreach adamnames-handle : administrative data (adresse, etc.)

  Another spreadshhet was simply a combination of the two previous
  one, kindly provided by Martin for checking.

To ensure a smooth DNS migration, adamsnames also accepted to
provide AXFR access to an authoritative .tf DNS server.

The rest is simple :
^^^^^^^^^^^^^^^^^^^

We extracted data from the spreadsheet, rearranged information that
we needed into our db format for insertion (and whois generation).

We AXFR DNS data from adamsnames (and checked coherence with information
in the spredsheet) and coordinated together (Adamsnames and AFNIC) to
ensure a smooth transition when asking DNS changes to IANA (adamsnames
also stayed autoritative for several month after the redelegation).

Last thing :
^^^^^^^^^^^

An important issue was of course communication to the community and
to contacts.

Before the redelegation, we (AFNIC) sent a mail to all contacts to
tell them about what would happen and when. That also was a good
opportnity to evaluate if administrative data was correct.
We then also sent a snail mail to all registrant contacts for whic
mails had bounced.

After the work was done, Adamnames and AFNIC also wrote a common
text to inform the community:

http://www.nic.tf/news/20041103.en.html
http://www.adamsnames.tc/tf.html

Shortly after this job was done, I stopped to be involved in .tf
issues (.tf management and issue was reorganised with other people).

So I can't tell you what was/had to be done after 2005.

Hope this helps,

Kindest Regards,

---
Olivier Guillard

---

From: Christopher Browne <[email-masked]>
Date: Thu, 25 Feb 2010 11:27:16 -0500

"Hollenbeck, Scott" <[email-masked]> writes:
> I managed the VeriSign side of the .org data transition from VeriSign
> to Afilias.  The short answer is that we provided them with a database
> dump that included the thin registry data and table structures.  There
> was no formal exchange of policy information.
>  
> Someone from Afilias will have to describe what it took to
> reconstitute things on their side.  They were up and running soon
> afterwards, and both teams agreed that the transition went very well.

I was the "technical guy" on the other side of that, and I'd consider
Scott's comments to be a fair assessment.

There were some limited discussions of the meanings of status data, but
that sort of thing was generally assessed via data analysis without
engaging in exchanges of "meta" policy information.  

That seems similar to the thinking about escrow in a pretty relevant
fashion.

There is a distinction worth noting, though.  In the dealings between
Verisign and Afilias, there *was* opportunity for interactive exchange
of information, and as the participants behaved in a professional
fashion, the interaction helped the transition to take place quite
smoothly.

Unfortunately, in a situation where there has been a failure requiring
the exercise of escrow, there can't be any expectation of being able to
interact usefully with the previous operator.  They may be unavailable,
or intractably adversarial, and it's not self-evident which might be
worse.

As to Scott's comments on reconstitution...  We obviously needed to go
through some efforts to reconstitute it into a form suitable for our
use; I'm not sure there is anything about that which is useful to
discuss here.  I worked on later transitions of other TLDs, which
provided some parallel observations - we received data in a number of
formats, frequently less-well-defined and more painful to work with than
the data used for the .org transition.

The data structures presented in the document Francisco presented to
this list bear intentional resemblance to the database dumps used for
the .org transition, which is a credit to how well that worked.
-- 
select 'cbbrowne' || '@' || 'ca.afilias.info';
Christopher Browne
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"