Yuko, et al, Thanks. The answer seems to be a pro forma recitation that applies to any use of any ICANN system. I was asking what behaviors *specific to the use of the RDRS* might trigger corrective action. One possible example is: - Flooding the system with inappropriate requests. (This leaves open the question of what an inappropriate request might be, but as a start let's assume they are requests that a registrar finds objectionable because it's predictable the registrar will not honor them, and that should be obvious to the requester.) I'm having trouble thinking of other examples as I type this; perhaps others can add some. Steve On Wed, Oct 4, 2023 at 10:22 AM Yuko Yokoyama <yuko.yokoyama@icann.org> wrote:
Dear Steve,
Thank you for your patience while we collected all feedback on the Terms. Please see ICANN org’s response in-line below, in blue.
As for your question regarding *“what would qualify as a breach of the terms and more specifically what would cause a requestor to be kicked out of the system”: *the ICANN Terms of Service <https://www.icann.org/privacy/tos>, which are the general terms for all the ICANN Services and to which the RDRS Terms of Service are a supplement, are the terms where you can find the “Responsibility of the Contributors” (Section 3) as well as other obligations and requirements (Sections 5-6 for example). In case of a breach of their obligations under the Terms of Service, ICANN would have the right (though not the obligation) to terminate or deny access to and use of the Platform (Section 4). Without quoting the whole text of the Terms of Service, Section 3 of the Terms of Service provide a non-exhaustive list of the core obligations. In practice, and as mentioned during the Small Team meeting, cases of malicious behavior to damage or corrupt the system, non-respect of the ICANN Expected Standards of Behavior <https://www.icann.org/resources/pages/expected-standards-2012-05-15-en> and ICANN Community Anti-Harassment Policy and Terms of Participation and Compliant Procedure <https://www.icann.org/resources/pages/community-anti-harassment-policy-2017-...>, user being under age would be examples that would request ICANN org to assess whether the user’s access needs to be revoked.
I hope this answers your question.
Thank you,
Yuko
*From: *GNSO-EPDPP2-SmallTeam <gnso-epdpp2-smallteam-bounces@icann.org> on behalf of Steve Crocker <steve@shinkuro.com> *Date: *Wednesday, September 13, 2023 at 8:09 PM *To: *Marika Konings <marika.konings@icann.org>, Diana Middleton < diana.middleton@icann.org> *Cc: *"gnso-epdpp2-smallteam@icann.org" <gnso-epdpp2-smallteam@icann.org> *Subject: *Re: [GNSO-EPDPP2-SmallTeam] FW: RDRS Draft Legal Terms
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.
*Response from ICANN org: The RDRS in itself does not set any new requirements - but anything that is already required through other policies remains in place and will be applicable. It will be up to the registrar’s discretion to determine how quickly they can/want to respond until phase 1 enters into force which at this rate may not happen until RDRS completes.*
- 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.
*Response from ICANN org: This means the jurisdiction where the data will be ultimately processed is a question of the RDRS intake form. We can make it clearer in the RDRS terms too.*
- 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.
*Response from ICANN org: Although collected through the RDRS, it is correct that this data is inputted by the registrars. We will add a * to these data fields to specify their origin.*
- 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?
*Response from ICANN org: It concerns the scenarios where a requestors would log a request on someone else's behalf (a client for example) and would enclose personal data of that third party.*
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
*Error! Filename not specified.*
*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.