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

Wed May 11 10:48:46 UTC 2016

Hi Roger,

Thank you for the clarification and I am actually fine with the 
proposal, not that I had major problems with it to begin with, I also 
cautioned flexibility at the start of this IRT.

Regarding the grandfathered data (let's keep using this term) and the 
burden of correction issue.
I regard it now as a non-issue.

This morning I ran through the most likely scenarios how grandfathered 
domains with missing data could slip into our systems but it seems we 
are blocking all transfers that are missing the RAA 2013 WHOIS specified 
fields.
For IRTP-C, we were going to make things a tad easier transfer wise, 
that plan has been canceled now since it is not worth the effort to 
correct data with such low-profit margins.

Regarding bulk transfers or as Verisign used to call it BTAPPA, is just 
a matter of contracts I guess. The losing and the gaining registrar both 
have to agree on such a transfer for starters.

Most logical step (I am not a lawyer), the Registry operator adds an 
addendum regarding grandfathered and missing data in the BTAPPA/bulk 
data transfer contract.
Or involved Registrars enter into an agreement there regarding 
grandfathered data themselves.

Problem solved.

Theo Geurts

Roger D Carney schreef op 2016-05-10 09:28 PM:
> 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
> 
> _______________________________________________
> Gnso-impl-thickwhois-rt mailing list
> Gnso-impl-thickwhois-rt at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt