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

[Dennis Chang]

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 <https://docs.google.com/document/d/1SVFkoI6RmrVVz--RrVLSOj1bmz1qLb7_JTuvt7At4Uo/edit>

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<https://www.icann.org/en/system/files/correspondence/fouquart-to-botterman-29jan21-en.pdf> letter.  As you know, there has also been a split<https://mm.icann.org/pipermail/council/attachments/20200914/489b3349/IRT.Rec7.GNSOCouncilLiaisonReport.20200914-0001.pdf> 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<http://www.icann.org> One World – One Internet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20211020/e07f91c9/attachment.html>