Marika, Diana, et al, Thanks for providing these documents. I do not have comments on: - *NAMING SERVICES PORTAL - TERMS OF USE* - *TERMS & CONDITIONS, Access to and Use of Non-Public Registration Data* . (I did not see any notes in the margins of the NAMING SERVICES PORTAL - TERMS OF USE) Here are my comments on: *TERMS OF SERVICE, Access to and Use of the Registration Data Request Service* - Section 7, PRIORITY LEVELS OF REQUESTS, provides a way for requesters to indicate a request is Urgent, i.e., posing "an imminent threat to Life, serious bodily injury, critical infrastructure (online and offline), or child exploitation." Lawful Disclosure of Urgent Requests has also been included in the EPDPP Phase I report and in the recently concluded IRT report. SSAC is nearing completion on its report on this matter. SSAC's observation is that no method or timeline has been specified for *submitting* an Urgent Request. The RDRS will now be providing an explicit method for submitting an Urgent Request, but, in keeping with the limited role of the RDRS, provides no specification or requirement on how quickly a participating registrar will receive an Urgent Request. - SECTION 9, LOGGING, REPORTING AND SERVICE LEVELS TARGETS -- Jurisdiction One of the data elements is Jurisdiction where the non-public registration data will be processed. My first reaction when reading this was to wonder how the RDRS will know because it's up to the registrar to determine the jurisdiction.. I then realized this is referring to where the *requester* will be processing the data. I suggest making this clearer. Further, this document should tell the Requester that they are required to determine the relevant jurisdiction, and they should do so prior to making a request. - SECTION 9, LOGGING, REPORTING AND SERVICE LEVELS TARGETS -- Last four bullets These data elements necessarily come from the registrar, not the requester. There is no requirement for the registrar to supply these. - 10 RESPONSIBILITY OF REQUESTERS This paragraph ends with "You will give notice and, if applicable, obtain consent, from any individual whose personal data is submitted to the RDRS system, [sic] if this is required under applicable laws." The primary concern in obtaining non-public data is protection of the privacy of the registrant and/or other contacts in the registration data. However, the personal data referred to in this paragraph is submitted by the requester. Therefore, it must be information about the requester. Is there data about other individuals that is required in a submission? Thanks, Steve On Tue, Sep 12, 2023 at 12:12 PM Marika Konings <marika.konings@icann.org> wrote:
Dear All,
Please find below a message from our org colleagues in relation to the RDRS draft legal terms (see also documents attached). If you have any questions or comments, please feel free to share these in advance of the upcoming meeting which is scheduled for Monday 18 September at 17.30 UTC.
Best regards,
Caitlin & Marika
_____________________________________
Dear GNSO Small Team,
I am sending this email on behalf of the Yuko Yokoyama, your ICANN org liaison. Please find attached the following draft legal terms in relation to the access and usage of the Registration Data Request Service (‘RDRS’) and related data, which is expected to launch by the end of November 2023.
- *The redline of the Name Service portal (‘NSp’) Terms of Use* changes. There are notes in the margins that should help explain the intention with the changes. Revisions have been limited to accommodate the integration and usage of the RDRS data into NSp. - *The Terms of Service for Access and Use of the Registration Data Request Service*. These terms govern the relationship between ICANN and the requestor. These terms are coming as a supplement to the ICANN Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.com/v3/__https:/www.icann.org/privacy/tos__;!!Dahw-A9d0CA...>), which already cover the creation of an ICANN account. - *The Terms and Conditions for Access to and Use of Non-Public Registration Data*. These terms govern the relationship between the requestor and the registrar.
Please note that although the Terms of Service and the Terms and Conditions are separate legal documents, the 2 sets of terms have been put in the same Word document for ease of reference.
A fourth document, i.e. a Privacy Policy addendum (additional privacy policy specific to RDRS, as an addition to the existing ICANN’s Privacy Policy <https://www.icann.org/resources/pages/privacy-2012-12-21-en#:~:text=ICANN%20...>) is currently under final drafting stages and will be shared with the GNSO Small Team as soon as available.
Yuko will be back online tomorrow and will be attending next Monday’s meeting. Please don’t hesitate to reach out for questions or concerns.
Best,
Diana
*Diana Middleton (she/her)*
Senior Program Manager
*I*nternet *C*orporation for *A*ssigned *N*ames and *N*umbers (ICANN)
diana.middleton@icann.org
Mobile: (571) 329-8830
[image: cidimage001.jpg@01D693FE.E33B2A10]
*One World. One Internet.*
_______________________________________________ GNSO-EPDPP2-SmallTeam mailing list GNSO-EPDPP2-SmallTeam@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdpp2-smallteam
_______________________________________________ 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.
