[GNSO-EPDPP2-SmallTeam] FW: RDRS Draft Legal Terms

Wed Oct 4 14:29:57 UTC 2023

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 at 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-03-24-en>,
> 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 at icann.org>
> on behalf of Steve Crocker <steve at shinkuro.com>
> *Date: *Wednesday, September 13, 2023 at 8:09 PM
> *To: *Marika Konings <marika.konings at icann.org>, Diana Middleton <
> diana.middleton at icann.org>
> *Cc: *"gnso-epdpp2-smallteam at icann.org" <gnso-epdpp2-smallteam at 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 at 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!zTETASCyB8GvXYhjjOkZoTYuleQ-AdQEpQiIVdnxAHIYCwnYUX0VEQf-Eh3kV-bnnoUulfzRP3PLTH81dO-RJISwIa4wKg$>),
>    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%20will%20provide%20personal%20information,contracted%20services%20or%20use%20of>)
> 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 at icann.org
>
> Mobile: (571) 329-8830
>
>
>
>
>
> *Error! Filename not specified.*
>
>
>
> *One World. One Internet.*
>
>
>
>
>
>
>
> _______________________________________________
> GNSO-EPDPP2-SmallTeam mailing list
> GNSO-EPDPP2-SmallTeam at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdpp2-smallteam/attachments/20231004/0d76171c/attachment-0001.html>