Re: [Gnso-impl-thickwhois-rt] Transition - Your Input on Open Questions - Due Mon. 9 May
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@xs4all.nl] Sent: Tuesday, May 10, 2016 6:08 AM To: Jennifer Gore Standiford <JStandiford@web.com> Cc: Roger D Carney <rcarney@godaddy.com>; gnso-impl-thickwhois-rt@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@icann.org [mailto:gnso-impl-thickwhois-rt-bounces@icann.org] ON BEHALF OF Roger D Carney SENT: Monday, May 09, 2016 11:44 AM TO: gnso-impl-thickwhois-rt@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@icann.org [mailto:gnso-impl-thickwhois-rt-bounces@icann.org] ON BEHALF OF Fabien Betremieux SENT: Thursday, May 05, 2016 6:46 AM TO: gnso-impl-thickwhois-rt@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt
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@xs4all.nl] Sent: Tuesday, May 10, 2016 6:08 AM To: Jennifer Gore Standiford <JStandiford@web.com> Cc: Roger D Carney <rcarney@godaddy.com>; gnso-impl-thickwhois-rt@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@icann.org [mailto:gnso-impl-thickwhois-rt-bounces@icann.org] ON BEHALF OF Roger D Carney SENT: Monday, May 09, 2016 11:44 AM TO: gnso-impl-thickwhois-rt@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@icann.org [mailto:gnso-impl-thickwhois-rt-bounces@icann.org] ON BEHALF OF Fabien Betremieux SENT: Thursday, May 05, 2016 6:46 AM TO: gnso-impl-thickwhois-rt@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt
_______________________________________________ Gnso-impl-thickwhois-rt mailing list Gnso-impl-thickwhois-rt@icann.org https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt
participants (2)
-
gtheo -
Roger D Carney