Good Afternoon, I completely agree with Sarah and Steve. Should the IRT have made this clearer, possibly, but as Sarah highlights it is clear that the ePDP WG did not intend to continue collecting (and therefor escrow) the Billing Contact as it was not discussed in the final report, it was not listed in Appendix D nor in the data elements matrix. The only other instance (outside of the charter reprint on pg 39) of "billing" was on pg 93 which stated "Note there are additional purposes for processing personal data, which the contracted parties may pursue, such as billing customers, but these are outside of what ICANN and its community should develop policy on or contractually enforce. It does not necessarily mean that such purpose is solely pursued by ICANN Org." I believe that this supports what both Sarah and Steve have said as well. Thanks Roger ________________________________ From: Steve Crocker via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Sent: Tuesday, July 2, 2024 12:56 PM To: Sarah Wyld <swyld@tucows.com> Cc: irt.regdatapolicy@icann.org <irt.regdatapolicy@icann.org> Subject: [IRT.RegDataPolicy] Re: [Ext] Re: Re: IRT Task 253: Review on Registrar Data Escrow Specification Update for the Registration Data Policy due 20240617 > 20240708 Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@. Sarah, No disagreement. That said, it seems to me registrars are permitted to continue collecting admin, tech and billing contacts if they wish to. Further, unless the policy speaks to this issue, each registrar can choose whether to collect each data element or to give the registrant the option. Steve [Sent by a Verified sender]<https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y> On Tue, Jul 2, 2024 at 1:52 PM Sarah Wyld via IRT.RegDataPolicy <irt.regdatapolicy@icann.org<mailto:irt.regdatapolicy@icann.org>> wrote: Hello, The Registration Data Policy lays out what data a registrar must and may collect for a domain name. It does not require registrars to collect Admin or Billing contact data, so it is reasonable to expect registrars to stop collecting and escrowing both of those sets of data. You refer to the Admin contact requirements of the RAA being specifically overridden by the Reg. Data Policy in contrast with how the Billing contact is handled, I disagree with that reading. Rec 29 only refers to the Admin contact in relation to ensuring that the Registered Name Holder data is complete, there is no other purpose for collecting an Admin contact. Similarly there is no purpose for collecting a Billing contact and no requirement in the Final Report to do so. I note that the Charter included a question "b1) What data should registrars be required to collect for each of the following contacts: Registrant, Tech, Admin, Billing?" - the absence of a requirement to collect any Billing contact data tells me that it is no longer required, not that the RAA requirement continues on. Thank you, Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com<mailto:swyld@tucows.com> On 2024-06-27 2:01 p.m., Dennis Chang wrote: Dear Sarah and IRT, Thank you for your timely review and questions. Please see our response to your questions below. Regarding Billing Contact: All requirements and obligations within a Registry Operator’s Registry Agreement and a Registrar’s RAA and consensus policies that pre-date the Registration Data Policy remain applicable and in force unless specifically modified by the Registration Data Policy (for example, the elimination of the Admin Contact). The Registration Data Policy addresses Registration Data as defined in Section 6 of the Policy, which does not include Billing Contact. Regarding Timing Changes: Registrar Data Escrow Agents (DEAs) use the ICANN interface and platform Registration Reporting Interface (RRI) to notify ICANN of deposits’ status as defined in Registrar Data Escrow Deposit Verification and Error Reporting (https://www.icann.org/en/system/files/files/registrar-data-escrow-deposit-verification-26may22-en.pdf).<https://www.icann.org/en/system/files/files/registrar-data-escrow-deposit-verification-26may22-en.pdf> We updated the text in Registrar Data Escrow Specification Section 3.1.1.4 to reflect the current practice between ICANN and DEAs. Please note that this is the responsibility of DEAs to notify ICANN, not registrars. Thanks, Dennis Chang From: Sarah Wyld <swyld@tucows.com><mailto:swyld@tucows.com> Organization: Tucows Date: Wednesday, June 26, 2024 at 11:01 AM To: Dennis Chang <dennis.chang@icann.org><mailto:dennis.chang@icann.org>, "irt.regdatapolicy@icann.org"<mailto:irt.regdatapolicy@icann.org> <irt.regdatapolicy@icann.org><mailto:irt.regdatapolicy@icann.org> Subject: [Ext] Re: [IRT.RegDataPolicy] Re: IRT Task 253: Review on Registrar Data Escrow Specification Update for the Registration Data Policy due 20240617 > 20240708 Hello all, I have reviewed the revised Escrow Spec, thank you Dennis for sharing that. I appreciate having both the redline and clean copy, that was helpful. I do have a couple questions. 1. Billing contact 1.2 In regards to their data escrow deposits, registrars (1) must include the data elements specified in Section 8.1 of the Registration Data Policy and Section 3.4.1.3 of the RAA; I went back to the RAA to see what 3.4.1.3 requires, and it is the domain's billing contact. I understand that since the Billing contact is not part of the Registration Data Policy we will no longer be collecting or maintaining that contact set. As such, I would think this should be removed from the escrow requirements? 2. Timing changes §3.1.1.4 of the updated escrow spec shows changes to the timing for various notices. This was unexpected as I dont recall anything in the Reg Data Policy that would prompt those changes. Please let us know where those originated from? Thank you, Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com<mailto:swyld@tucows.com> On 2024-06-12 3:35 p.m., Dennis Chang wrote: Dear IRT, First. Thanks to Sarah for making this request for an extension right away. And including me in the RrSG session to discuss Registration Data Policy implementation. It gave me a chance to speak with the Registrars and all agreed that extension is needed. Therefore, we are extending the review due date to 8 July 2024. (Noting that Sarah asked for 5 July at the earliest) I received feedback that this would provide sufficient time for a good review with your technical teams. 253 Registrar Data Escrow Specification (RDE Specification) Update Review<https://urldefense.com/v3/__https:/docs.google.com/document/d/1XAlTD0rTSWx0O...> [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1XAlTD0rTSWx0O...>
Redlined Document to show the changes. [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1h0gg8g5u5iva1DI-...>
20240617 20240708 Please note that there has been some updates to improve the readability and I included the link for the Redline to show the changes. While the due date is 8 July, we’d appreciate your comments as early as you can so that we can finalize the spec soon after the due date. FYI. I heard good conversations in many sessions regarding the implementation and expect that there will be increased collaborative activities coming. Registration Data Policy is a complex implementation that touches all parts of the business so it was good that we designed a 6-month preparations period. Thanks you for your continued supprt. Dennis Chang From: "Sarah Wyld via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org><mailto:irt.regdatapolicy@icann.org> Organization: Tucows Reply-To: Sarah Wyld <swyld@tucows.com><mailto:swyld@tucows.com> Date: Friday, June 7, 2024 at 8:48 PM To: "irt.regdatapolicy@icann.org"<mailto:irt.regdatapolicy@icann.org> <irt.regdatapolicy@icann.org><mailto:irt.regdatapolicy@icann.org> Subject: [IRT.RegDataPolicy] Re: IRT Task 253: Review on Registrar Data Escrow Specification Update for the Registration Data Policy due 20240617 Hi Dennis, With ICANN80 next week I will not be able to review this and provide feedback by the 17th. I see that the redlines are extensive and I would like to have enough time to fully consider them. Additionally I want to share this with my team who actually maanges our escrow deposits to ensure they have a chance to provide their perspective and flag any concerns. Can the deadline please be extended to July 5 at the earliest? Thank you, Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com<mailto:swyld@tucows.com> On 2024-06-04 12:18 a.m., Dennis Chang via IRT.RegDataPolicy wrote: Dear IRT, Please review and provide feedback on the draft Registrar Data Escrow Specification<https://urldefense.com/v3/__https:/docs.google.com/document/d/1XAlTD0rTSWx0O...> [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1XAlTD0rTSWx0O...> by 17 June 2024. 253 Registrar Data Escrow Specification (RDE Specification) Update Review<https://urldefense.com/v3/__https:/docs.google.com/document/d/1XAlTD0rTSWx0O...> [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1XAlTD0rTSWx0O...> 20240617 As the Registration Data Policy supersedes the registrar escrow requirements of Section 3.6 of the Registrar Accreditation Agreement, a new Registrar Data Escrow Specification (e.g., version 2024) was developed to account for such updates, in addition to include details about the deposit format, file naming convention, schedule, and technical details for registrar escrow operations. Please also see the redline doc<https://urldefense.com/v3/__https:/drive.google.com/file/d/1XtLvnYVccLnIoFzm...> [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1XtLvnYVccLnIoFzm...> between the draft RDE Specifications 2024<https://urldefense.com/v3/__https:/docs.google.com/document/d/1XAlTD0rTSWx0O...> [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1XAlTD0rTSWx0O...> and the current RDE Specification published in 2007<https://www.icann.org/en/system/files/files/rde-specs-09nov07-en.pdf> for your reference. You may make your comments directly to the shared document or reply to me. I look forward to seeing some of you next week in Kigali. We do not have an IRT session at ICANN80 but there are sessions where Registration Data Policy implementation is expected to be discussed. I’ll share any information I receive. Please share with the IRT if you are aware of any pertinent information as well. -- Kind Regards, Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<http://www.icann.org/> One World – One Internet _______________________________________________ IRT.RegDataPolicy mailing list -- irt.regdatapolicy@icann.org<mailto:irt.regdatapolicy@icann.org> To unsubscribe send an email to irt.regdatapolicy-leave@icann.org<mailto:irt.regdatapolicy-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ IRT.RegDataPolicy mailing list -- irt.regdatapolicy@icann.org<mailto:irt.regdatapolicy@icann.org> To unsubscribe send an email to irt.regdatapolicy-leave@icann.org<mailto:irt.regdatapolicy-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.