Thanks Marc for the detailed review and feedback. Thanks to all the IRT members and the implementation teams for the inputs for the implementation timeline. This is very much appreciated and exactly what we were looking for. We’ll study your inputs closely and come back to the IRT to discuss the timeline again. Thanks, Dennis Chang From: "Anderson, Marc" <mcanderson@verisign.com> Date: Wednesday, May 24, 2023 at 1:58 PM To: Dennis Chang <dennis.chang@icann.org>, "irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org> Subject: [Ext] RE: [IRT.RegDataPolicy] IRT Task 241 Review Implementation Timeline proposed at 10 May 2023 IRT meeting. Due 20230524 Dennis and IRT / IPT members, I am not supportive of the proposed change to the timeline and advocate sticking with the 18 month implementation window. The 18 month implementation window has been the plan going back many years now and is what contracted parties who need to do the implementation work are expecting and have been planning towards. This is a significant deviation from what I thought was a settled issue coming very late in the process (after public comments) and introduces uncertainty. The original 18 month implementation window was developed collaboratively within the IRT without objections or concerns raised. The rationale outlined don’t justify the change and would create more challenges then benefits. The Policy Change Calendar was the result of a CP ask to bundle implementations. Over a period of several months, three RDDS related items were published, one was the AWIP policy in July 2014 and another was the Whois advisory in Sep 2014 (I don’t remember the 3rd). Each caused expensive rework to ongoing development cycles which led to CPs approaching GDD staff to avoid this issue in the future. GDD staff was receptive and came up with the Policy Change Calendar, which has provided predictability and has served contracted parties and ICANN org well in the years since. I give this background to say that we shouldn’t be doing something unnatural to shoehorn this policy into a one month implementation window in Aug in 2025, that isn’t the problem the Policy Change Calendar was trying to address. The second rational is to provide a minimum 18 months to prepare for implementation as requested by CPH. That isn’t what CPs asked for though. We asked for an 18 month implementation window with the option to implement immediately once the policy has been published. The option to implement immediately is important enough to some CPs that it came up as a question during the CPH summit last year, and it was confirmed that once the policy is published, CPs could start implementing immediately. Obviously this change would contradict that. A two year window to “prepare” and a 1 month window to implement isn’t what we’ve asked for and I don’t see that as helpful. I want to echo what Sarah said in her response about extending the time period. It seems in everyone’s best interest to finish the policy and get it implemented sooner rather than later. There has been a lot of attention on this policy. I dislike the optics of pushing the implementation of this policy out essentially for over 2 years. In theory the idea of pushing implementation out past the sunset of Whois to avoid Whois development sounds good. My company is planning to operate Whois past the sunset date so at least for us, there is no advantage. While this may be attractive for some, the policy provides many benefits and improvements that shouldn’t be unnaturally delayed. If avoiding development of Whois just before it is going to be sunset is an important enough issue, it seems to me there are better ways of addressing that then to delay the implementation of the Registration Data Policy for over 2 years. I don’t agree with the fourth rational provided. I see this as creating more confusion and chaos (not reducing it). Forcing all registries and registrars for all gTLDs to hit the same 1 month window creates a lot of risk. I see the flexibility provided by an 18 month window as being preferable for all involved. I must admit I was surprised to “flag day” listed as a rational for this approach. In my experience, “flag day” has a negative connotation. It is an approach you take when you don’t have the option of making a smooth transition. Take the recent example of the TMCH flag day. The TMCH system didn’t have the ability to support two keys which would facilitate a seamless transition. The only realistic option was to have a “flag day”, shutting down the TMCH, removing the old key, adding the new key, after which CPs can only connect with the new key. This is a disruptive transition, not a smooth transition. This approach works in some circumstances, but isn’t an ideal option. I don’t want to align with a flag day concept. I would much rather have an 18 month window to manage a smooth transition minimizing impacts to all. I don’t see a lot in the way of upside to waiting 2 years to implement this policy and then cramming its implementation for all gTLDs for all registries and all registrars into a 1 month window. Instead I see it introducing risk and confusion. This would be a significant change to the long established plan of an 18 month window starting when the policy is published. Lets stick with the original plan of an 18 month window, as was shared with the community during public comment. Thank you, Marc From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> On Behalf Of Dennis Chang via IRT.RegDataPolicy Sent: Wednesday, May 10, 2023 7:20 PM To: Sarah Wyld via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Subject: [EXTERNAL] [IRT.RegDataPolicy] IRT Task 241 Review Implementation Timeline proposed at 10 May 2023 IRT meeting. Due 20230524 Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Dear IRT, Please review and provide your input on the implementation timeline presented at the IRT meeting today. 241 Review Implementation Timeline proposed at IRT meeting on 10 Mat 2023 20230524 To be clear, this is a departure from our original plan that provides several advantages and benefits, further outlined below.. We request your feedback after you’ve had a chance to discuss this approach with your technical implementation team. The timeline can be found in the IRT workbook under the tab called “Timeline.” [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1r8yMMEFIF...> 241 Review Implementation Timeline proposed at IRT meeting on 10 May 2023 20230524 The key dates to the timeline include: 1. Publication of the Registration Data Policy on 1 August 2023 2. Preparation: implementation development, coordination, testing for transition from 1 August 2023 to 1 August 2025 (2 yrs) - Stage 1 of Interim Registration Data Policy for gTLDs [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1l5e7F4GQjpa-9pnPHcN...>. 3. Enact Implementation Plan: Transition / cutover period from 1 August 2025 to 29 August 2025. (Stage 2 of Interim Registration Data Policy for gTLDs [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1l5e7F4GQjpa-9pnPHcN...>): may begin to implement measures consistent with the Registration Data Policy and/or Interim Registration Data Policy for gTLDs. 4. Policy Effective date on 30 August 2025. (Stage 3 of Interim Registration Data Policy for gTLDs [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1l5e7F4GQjpa-9pnPHcN...>): all parties have implemented measures consistent with the Registration Data Policy. Rationale for this timeline: 1. Follow the Policy Change Calendar [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/18YW1DzIdQKQKA-ilxIqDrCJHTUio1zoj5pYoNERD3IKuaUnkfYLIyLInS7cLu92zlFfGZetX9qhn4b8HA8mZ0rTYOuaMky_WRyArqkkiTzmMPah0GXPSRAAJXzoYYs7qd2XKSOy52BJjXXVvMWE3-D5_o7C5EYcKdW5HjhRHW-srCe6IeBPpSIZ0TZSvIQJFhIMq524RNdFJBx8QRvJH0Y_06D-wB0X9ha_TKcIQuEg2nJguMG2vEd3AV72KmsyAC7ZkLbpDSGiyMPvC-x5bHl-mDw-7rLk71_8ciwUcJ80/https*3A*2F*2Fwww.icann.org*2Fen*2Fsystem*2Ffiles*2Ffiles*2Fgdd-policy-change-calendar-18may15-en.pdf__;JSUlJSUlJSU!!PtGJab4!59HRIUTGLxFCAiFgtdd4amPX493fZaQ1-x3Oj8kIa8ptaWlFSY2KDA59-scJHuGBJddS7N46FvaioqgOv3bz1qR23ztWgA$>using the February and August cycle for major releases. 2. Provide a minimum 18 months to prepare for implementation as requested by CPH. Provides all implementers adequate time to coordinate and collaborate to be prepared to transition from the interim policy to the permanent policy. 3. Account for RDAP implementation timeline where the effective date of the Registration Data policy comes after the WHOIS Sunset date (Feb 2025.) This avoids development of WHOIS for those who plan to Sunset WHOIS, thus saving resources for all involved. 4. Minimize the transition period where the Interim and Registration Data Policies are both being used to 1 month (from 18 months in prior plan). This provides more predictability for a global transition from the Interim to the Permanent policy. An efficient way to make the transition that also reduces risks of confusion for RDDS users and disconnect between Registries and Registrars. 5. The short-term transition period aligns better with the “Flag Day” concept typically used in the technical community primarily responsible for implementing. The policy language to represent this timeline would be: This Policy is effective on 30 August 2025. The Interim Registration Data Policy for gTLDs will remain in effect until 29 August 2025. During the period of 1 August 2025 through 29 August 2025, Registry and Registrar may continue to implement measures consistent with the Interim Registration Data for gTLDs or this policy in its entirety, or elements of both. Please feel free to reply with suggestions to the policy language (Section 4) that matches your input. As always, I am grateful for your support through the end here. We are almost there. Let’s continue our excellent collaborative ways to finish this together. Kind Regards, Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org [secure-web.cisco.com]<https://urldefense.com/v3/__http:/secure-web.cisco.com/1Hmny3zSgi8LV0oaQbEI7...> One World – One Internet