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

Jennifer Gore Standiford JStandiford at web.com
Mon May 9 16:06:40 UTC 2016


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,


  1.  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)

  1.  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)
  2.  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)
  3.  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)
  4.  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.
  5.  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> [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<mailto: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 :

  1.  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)  ?
  2.  How can we minimize the amount of "throw away code" ?
  3.  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
  4.  Should we aim to synchronize implementation of the new and existing registrations tracks ?
  5.  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 ?
  6.  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-impl-thickwhois-rt/attachments/20160509/fa796b57/attachment.html>


More information about the Gnso-impl-thickwhois-rt mailing list