[IRT.RegDataPolicy] IRT Task 176 Review RedDoc Section 8 forsuggested changes for Rec 7 - 20211109

[Sarah Wyld]

Hi Dennis and team,

The CPH members of the IRT have now had a chance to review the proposed changes to section 8 (transfer of data from registrar to registry). 

Many of us do quite like the outcome (suggested removal of 8.3-8.6) but we are not sure that it faithfully implements the Recommendation as written or the guidance from the GNSO Council’s January 29 letter to the Board, which recommended that the Recommendation #7 language, “must be transferred from registrar to registry provided an appropriate legal basis exists and data processing agreement is in place” should be included in the new Policy. If we’re missing something, we’re of course open to hearing what and discussing the right next steps. 

Otherwise, we think the correct course of action is to keep the section 8.3-8.6 language and return to the discussion from the Nov. 2019 comment threads (example), ensuring that “provided an appropriate legal basis exists and data processing agreement is in place” is used in 8.3 and 8.4 (which were section 7 when the comment was left). 

We also do still need to revisit Section 5; there was a CPH comment that had been resolved back in August but the issue remains open. 

Thank you,


-- 
Sarah Wyld, CIPP/E

Policy & Privacy Manager
Pronouns: she/they

swyld at tucows.com 
+1.416 535 0123 Ext. 1392



From: Dennis Chang via IRT.RegDataPolicy
Sent: October 20, 2021 3:57 PM
To: Dennis Chang via IRT.RegDataPolicy
Subject: [IRT.RegDataPolicy] IRT Task 176 Review RedDoc Section 8 forsuggested changes for Rec 7 - 20211109

Dear IRT,

Please review the suggested changes for Rec 7 implementation in Section 8.0 Transfer of Registration Data from Registrar to Registry Operator.

176
Review RedDoc Section 8 for suggested changes for Rec 7 
20211109
This topic will be the priority item on our next IRT meeting and we’ll be providing a detailed explanation for your discussion. As a reminder, here is some background information and some of the rationale to better prepare for our discussion.

The suggested approach carefully considered the guidance provided by the GNSO in its 29 January 2021 letter.  As you know, there has also been a split among IRT members based on the interpretation of whether an appropriate legal basis exists to require the transfer of data elements from registrars to registry operators. The core issues are the contracted parties’ discretion about transferring registrant contact data from the registrar to the registry, and the extent to which the recommendation changes the Thick Whois Transition Policy.  

Resolving this difference is a dependency for completion of the draft policy language for public comment. To find a path forward, we considered several questions about how to apply the GNSO guidance. We read the guidance, along with the rationale, to specify that registry operators have discretion to determine what elements they require for transfer from registrars, depending on their own determination of legal basis and whether data protection agreements are in place. “The requirements set out in the Temporary Specification supersede and replace the contractual requirements in the Registrar Accreditation Agreement and the Registry Agreements, which incorporate by reference all ICANN consensus policies. There is a conflict between the data processing principles under the Temporary Specification and the requirements under existing gTLD Registry Agreements as well as the Thick Whois Transition Policy. In other words, the Thick Whois Transition Policy was modified by the Temporary Specification and further modified by Recommendation #7 in the EPDP Phase 1 Final Report, as the EPDP Team was mandated to do.”

Considering these questions, we suggest that the policy covers only requirements for the registration data elements that must be transferred from registrar to registry in all cases. This approach provides the contracted parties the discretion to determine whether there is legal basis for transfer of optional contact data elements amongst themselves, as this activity would fall outside the scope of policy requirements. The Registration Data Policy can specify requirements for transfer of the required data elements (in section 8.1 and 8.2) and these requirements would be enforced by ICANN org. Transfer of other data elements, should contracted parties choose to do so, would be at their discretion and not an area of policy enforcement. Therefore, sections (8.3, 8.4, and 8.5) would not be needed in the policy language.  If more information would be helpful for the implementers, we could add to the Implementation Notes or the Educational Material.  

Requiring transfer of only the mandatory registration data elements remains consistent with the approach taken by the EPDP Phase 1 working group, phasing out the dichotomy of “thick” and “thin” registrations and focusing the Registration Data Policy only on the enforceable transfer of data elements. The mandatory registration data includes only those elements required to ensure that an end user can find the technical details of the Registration Data Directory Service (RDDS) provided by the Registrar, and only the information pertaining to the DNS is transferred. The data set as reflected in our OneDoc section 8.1 and 8.2 includes the following data elements: Domain Name, Registrar WHOIS Server, Registrar URL, Registrar, Registrar IANA ID, Registrar Abuse Contact Email, Registrar Abuse Contact Phone, Domain Status(es), Name Server(s); Name server IP Address(s) DNSSEC Elements. 

This policy requirement then allows contracted parties to create data processing agreements, as necessary, that reflect their determination of legal basis and what data elements are required for transfer. ICANN will not be a party to these agreements, and will have no role in negotiating or enforcing such agreements.
 
In reviewing the updated OneDoc to show how this proposal would work, note that the OneDoc does not include the language provided by the Council guidance for inclusion in the Registration Data Policy, “must be transferred from registrar to registry provided an appropriate legal basis exists and data processing agreement is in place.” However, given our understanding that this language is not intended to create requirements to be enforced by ICANN, we believe the end result is consistent with the intent of the policy recommendation and the guidance provided by the GNSO Council in terms of providing the registry operator with discretion. 
 
We’ll spend some quality time together going over this approach at our meeting next week.  It will be an ICANN72 Public Session for us and will be a good opportunity for the community to get an inside view of the IRT’s challenging but collaborative teamwork.

Thank you always for your support and dedication to this policy implementation.  I look forward to seeing you all next week; let’s use our videos for this meeting.
Please don’t forget to register for the session.

-- 
Kind Regards,
Dennis S. Chang
GDD Programs Director
Phone: +1 213 293 7889
Sykpe: dennisSchang
www.icann.org One World – One Internet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20211101/9ca62b72/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C198D2C57EB5430DA291925A0091CA47.png
Type: image/png
Size: 14051 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20211101/9ca62b72/C198D2C57EB5430DA291925A0091CA47.png>