[Gnso-impl-thickwhois-rt] Transition - Your Input on Open Questions - Due Mon. 9 May

Tue May 10 19:28:21 UTC 2016

Good Afternoon,

Thanks Theo and I agree on the "burden of correction" that you bring up. I was hoping to bring this up on the call today but we had a full productive call on the other items so I will respond here.

Maybe I can clarify what I was suggesting in these last two points on treatment of existing data and transfers. I think existing data (including transfer of existing data) should be treated differently than new registration data. I believe that this data should be grandfathered (not required to meet today's ICANN/Registry policies) until such time that these contacts are explicitly updated post transition/transfer.

Thanks
Roger

-----Original Message-----
From: gtheo [mailto:gtheo at xs4all.nl] 
Sent: Tuesday, May 10, 2016 6:08 AM
To: Jennifer Gore Standiford <JStandiford at web.com>
Cc: Roger D Carney <rcarney at godaddy.com>; gnso-impl-thickwhois-rt at icann.org
Subject: Re: [Gnso-impl-thickwhois-rt] Transition - Your Input on Open Questions - Due Mon. 9 May

Sorry for the late reply.

I think Roger and Jen are on the correct track.

Two things though.

2 Should there be a minimal set of validation parameters?

This will depend on the fields and the parameters. Multibyte or non-ASCII support is required.

4&5 I do not mind this, but and this is a big but, could we end up in a situation where a gaining Registrar ends up after a transfer or bulk-registry transfer with X amount of domain names with zero or partial data and the burden of data correction will fall upon the gaining Registrar? If the answer is yes, then I am against option 2.

In my experience data correction is a painful and a very costly procedure and in my opinion, the gaining Registrar should not take the brunt for the missing data for the losing Registrar.

So is the above scenario, something that can happen? Or if we do not know how can we prevent it from happening or can we add some safeguards that if the above scenario unfolds the losing Registrar must supply the missing data?

Thanks,

Theo Geurts

Jennifer Gore Standiford schreef op 2016-05-09 06:06 PM:
> Hello All,
> 
> I agree with Roger and would just like to include the following.
> 
> Thank you,
> 
> Jennifer Gore
> 
> FROM: gnso-impl-thickwhois-rt-bounces at icann.org
> [mailto:gnso-impl-thickwhois-rt-bounces at icann.org] ON BEHALF OF Roger 
> D Carney
> SENT: Monday, May 09, 2016 11:44 AM
> TO: gnso-impl-thickwhois-rt at icann.org
> SUBJECT: Re: [Gnso-impl-thickwhois-rt] Transition - Your Input on Open 
> Questions - Due Mon. 9 May
> 
> Good Morning,
> 
>  	* What would the a bulk transfer be under option 2 (proposal that 
> registries do not impose checks or validation parameters on the 
> registration data being transitioned from thin to thick)  ?
> 
>  	* [RDC] I think that having two options would be best, a file option 
> and a dedicated EPP connection(s) option. File Option should have 
> defined specifications i.e. format, size,etc (JGore)
> 
> 	* How can we minimize the amount of "throw away code" ?
> 
>  	* [RDC] Allowing bulk through dedicated EPP connection will reuse 
> the create and update code paths. If Registries would agree on a 
> uniformed SDK that would be appreciated (JGore)
> 
> 	* Should there be a minimal set of validation parameters ? For
> example: Numerical/Alphanumerical/UTF8 constraints on phone fields, 
> requirement to provide Contact ID and Auth Info, a maximum length of 
> fields
> 
>  	* [RDC] Max length, contact id, auth info. Minimum length (JGore)
> 
> 	* Should we aim to synchronize implementation of the new and existing 
> registrations tracks ?
> 
>  	* [RDC] I think that we should keep these going down separate paths, 
> mitigating any possible delay in one path from the other path. Keep 
> them separate. Focus on New Registrations first (JGore)
> 
> 	* Once data is migrated, what rules should apply ? Should new and 
> existing registrations be treated differently based on their creation 
> date and the applicable RAA ?
> 
>  	* [RDC] New and existing should be treated differently. Current 
> rules (ICANN and Registry policies) should only apply to existing 
> registration contacts once the contact update date is greater than the 
> transition date, exception on transfers see below.
> 
> 	* Is the potential impact of option 2 on future transfers of 
> registration acceptable ?
> 
>  	* [RDC] Yes, same experience as today, except that it should improve 
> over time. There will be bad contacts on transfers and this should be 
> allowed. This data will cleanse organically over time. Do not prohibit 
> the transfer if data contact information is incorrect or not complete 
> (JGore).
> 
> Thanks
> 
> Roger
> 
> FROM: gnso-impl-thickwhois-rt-bounces at icann.org
> [mailto:gnso-impl-thickwhois-rt-bounces at icann.org] ON BEHALF OF Fabien 
> Betremieux
> SENT: Thursday, May 05, 2016 6:46 AM
> TO: gnso-impl-thickwhois-rt at icann.org
> SUBJECT: [Gnso-impl-thickwhois-rt] Transition - Your Input on Open 
> Questions - Due Mon. 9 May
> 
> Dear IRT members,
> 
> In preparation for our next IRT meeting on Tue. 10 May, during which 
> we would like to focus our discussion on the implementation of the 
> transition from thin to thick, we would like to gather your thoughts 
> on the open questions below.
> 
> A you may recall, these questions emanate from prior discussions on 
> the mailing list regarding proposals for the transition of existing 
> registration from thin to thick. For more background, please refer our 
> presentation earlier this week (available at:
> https://community.icann.org/display/TWCPI/IRT+Meetings).
> 
> Open questions :
> 
>  	* What would the a bulk transfer be under option 2 (proposal that 
> registries do not impose checks or validation parameters on the 
> registration data being transitioned from thin to thick)  ?
> 	* How can we minimize the amount of "throw away code" ?
> 	* Should there be a minimal set of validation parameters ? For
> example: Numerical/Alphanumerical/UTF8 contraints on phone fields, 
> requirement to provide Contact ID and Auth Info, a maximum length of 
> fields
> 	* Should we aim to synchronize implementation of the new and existing 
> registrations tracks ?
> 	* Once data is migrated, what rules should apply ? Should new and 
> existing registrations be treated differently based on their creation 
> date and the applicable RAA ?
> 	* Is the potential impact of option 2 on future transfers of 
> registration acceptable ?
> 
> Please provide your input in response to this email by Mon. 9 May COB 
> in your time zone.
> 
> Best Regards
> 
> --
> 
> Fabien Betremieux
> 
> Sr. Registry Services & Engagement Manager
> 
> Global Domains Division, ICANN
> _______________________________________________
> Gnso-impl-thickwhois-rt mailing list
> Gnso-impl-thickwhois-rt at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt