[Gnso-impl-thickwhois-rt] Open Items 5/6 - Inter-registrar Transfers

[Jody Kolker]

Fabien,

My preference would be that during this transitional period, the contacts are automatically removed by the registry when the domain is transferred.  It is then up to the registrar to attach the contacts to the domain when the transfer is completed. 

When a domain is transferred from a thick registry, the first thing that we do is create new contact ROIDs for the domain at the registry and replace the current contact ROIDs of the domain with the newly created contact ROIDs.  

The registrars would need the validation rules to be relaxed until all domains have been updated to have contacts at the registry.


Thanks,
Jody Kolker

-----Original Message-----
From: gnso-impl-thickwhois-rt-bounces at icann.org [mailto:gnso-impl-thickwhois-rt-bounces at icann.org] On Behalf Of Fabien Betremieux
Sent: Monday, August 08, 2016 4:46 PM
To: gnso-impl-thickwhois-rt at icann.org
Subject: [Gnso-impl-thickwhois-rt] Open Items 5/6 - Inter-registrar Transfers

Dear IRT Members, 

In his recent email below, Theo is raising a number of questions related to the use case where a loosing registrar has transitioned to thick and the gaining registrar is still thin and not ready to handle thick
registrations:
- would registries support the proposal that registry-level contacts be deleted if a gaining registrar is not yet ready to handle thick registrations ?
- are other registrars foreseeing issues such at those presented below by Theo ?

In addition to the above questions, our scorecard includes an open question related to the validation of contact data upon transfers during or after the transition: what validation rules should apply to transfers requiring the creation of new contacts (registrar-based ROIDs needed) when data is missing for these contacts ?

We are seeking IRT members input to determine if there should be specific requirements in the policy language to account for these situations.

Thank you in advance for your discussion of these topics.

Best Regards
Fabien


-----Original Message-----
From: theo geurts <gtheo at xs4all.nl>
Date: Saturday, August 6, 2016 at 10:16 PM
To: Fabien Betremieux <fabien.betremieux at icann.org>, "gnso-impl-thickwhois-rt at icann.org" <gnso-impl-thickwhois-rt at icann.org>
Subject: Re: [Gnso-impl-thickwhois-rt] The thing that should not be

>One of the Metallica tracks i never liked much. Anyways.
>
>Domain transfers with contacts at the registry to a registrar that 
>cannot deal with it.
>It would create two different sets of contacts, one at the registry, 
>one at the registrar. When the registrant updates the data it would be 
>updated at the registrar level but not at the registry level.
>
>This will create issues, or to be more precise, this is going to be a 
>train wreck.
>
>FRANCISCO's solution: if a registrar is not yet ready to manage 
>contacts in the registry, one thing they could do if they are the 
>gaining registrar in transfer when they accept the transfer, they 
>immediately remove the contacts from the registry so that you don¹t 
>have stale contacts in the registry.
>Question: if the contact is no longer at the registry, but only at the 
>registrar, are we going to reverse the issues? There is some rather 
>specific language in IRTP C, will this create issues?
>
>Our dev team thinks they can implement the above solution, however, we 
>did not discuss the amount of time involved.
>The solution works if it is allowed at the Registry level.
>
>Assuming this is allowed (still, an if) then we do not know how it will 
>affect registrars. Up till now, we assumed this was some simple 
>migration. With the above in mind, not so much in my opinion. To give 
>you guys an example, we used to be a wholesale registrar nowadays we 
>make our money from our registrar gateway platform.
>So if we gonna make a few changes, it will affect not just us as a 
>registrar but a boatload more. So we have a different architecture than 
>other registrars. This just being an example on how registrars set up 
>their backends, we are not unique.
>
>Thanks for reading this.
>
>Theo
>
>
>
>
>
>
>
>
>
>
>
>
>