Wednesday 14 March from 15.15 - 18.30 local time

Results

Draft Agenda  -  UPDATED, SUBJECT TO REVISION

Primary Goal: Apply Saturday F2F results in order to converge on purpose definitions and complete deliberation on purposes and associated data.

1. Introductions and SOI Updates (Wednesday 15:15-15:20)

2. Quick review of Meeting Goals and Saturday progress (Wednesday 15:20 – 15:30)

3. Review remaining DT answers on entities to be identified or contacted for each possible purpose for processing gTLD registration data 

4. Deliberate on remaining possible purposes for processing gTLD registration data (16:50-18:15, tentative)

5. Confirm action items and proposed agreements (last 15 minutes of both F2F sessions)


Materials

Notes/Action Items

Action Items and Notes from RDS PDP WG Call – 14 March 2018

These high-level notes are designed to help PDP WG members navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki.

1. Introductions and SOI Updates

  • Kathy Kleiman is now president of Domain Name Rights Coalition

2. Quick review of Meeting Goals and Saturday progress – Slides 7-8

  • Having finished four of the seven Drafting Team Reports, today’s session will begin by covering the remaining reports, beginning with Regulatory Enforcement.
  • Summary table to be drafted to consolidate answers produced by all drafting team members.  One example to be included in chart – Is there a need to identify a need to contact the domain name owner or registrar in this particular purpose?
  • Table may show commonality of needs, as input to deliberation.  Similar to the 10 March meeting, the WG is not deliberating on purposes during this meeting.  Instead, the WG is reviewing the DT answers in attempt to broaden its thinking before it returns to deliberation.
  • Summarizing DT answers does not imply that all purposes or data needs are legitimate
  • No assumption that all data listed in table would be provided through an RDS
  • Following the DT reports, the WG will discuss ICANN Contractual Enforcement as a purpose

3. Review remaining DT answers on entities to be identified or contacted for each possible purpose for processing gTLD registration data 

DT5 Regulatory Enforcement  – Slide 9

  • DT5 answers introduced by Farell
  • DT disagreed over whether contact with registrant was required for this purpose
  • Questions regarding legitimacy of this purpose to be addressed during deliberation
    • ICANN isn’t a regulatory agency – not within ICANN’s mission
    • Is the WG wasting time discussing these answers when important discussions are on the interim compliance model are being held in parallel? 
    • The DT answered these questions, but did not imply that some of the information regulatory authorities may request would be publicly available. It may be hidden behind a gate.
    • Third party agencies use WHOIS for this purpose & may have legitimate interest
    • Examples: consumer protection agencies (e.g., FTC), anti-fraud industry regulators
      • Do these examples overlap with criminal investigation?
      • Not necessarily – for example tax agencies (e.g., IRS)
      • After ICANN60, DT5 made an effort to eliminate overlap with DT7’s definition
      • Can you provide access to third parties to data collected for another legitimate purpose?
        • This question was previously asked and answered – see exceptions in GDPR Art 6
        • Regarding expectations, after contact, the recipient of a notification or question can do anything they want – use of registration data for contact does not obligate response
        • Why is Registry listed? It is not in WHOIS today.
          • Answer: Identifies need; no assumption need must be met through RDS
          • Suggestion: Also identify which data is available from other sources

DT6 Legal Actions  – Slide 10

  • DT6 answers introduced by Griffin – Slide 11
  • Focus is on contracts between private parties (i.e., not contracts with ICANN)
  • Possible to accomplish 2d) using IP addresses associated with domain names or Nameservers
    • DT6 had agreed to replace “hosting provider” by “DNS operator” throughout answers
    • Nameserver does not always lead to responsible party – investigative value
    • Why does DT6 (3) refer to “Legal Authority” is communication is between private entities?
      • Answers cover both cases where private entities initiate communication (e.g., a private corporation pursuing a legal action), and also cases where legal authorities have gotten involved in investigating allegations
      • Contacted entity may be more likely to respond to a legal authority than private party – see last bullet under question 3
      • Contacted entity may be under no obligation to respond
      • Some feel that “Legal Action” is too broadly defined

DT7 Criminal Investigation/DNS Abuse Mitigation Investigation, Notification, and Reputation

  • Answers introduced by Marc, noting limited participation of DT7 members in drafting answers
  • Overall there are two paths: investigate a possible criminal or contact a possible victim
  • During investigation, the entity to be identified is whomever is controlling the DN – that may not be the rightful owner of the DN
  • During investigation, may also be appropriate to contact the registrar, reseller, or privacy/proxy provider to identify the possible criminal engaged in the activity or abuse
  • During notification, the primary objective is to inform the possible victim; the secondary objective is enabling mitigation of the activity/abuse
  • Page 1 Question 2 of DT7 answers: Objective should include reputation?
  • How is Question 3 helpful for this purpose? May describe any obligation on response (or lack thereof). May also describe possible benefits to data subjects.
  • Were these definitions informed by jurisdiction and limitations imposed by laws in certain jurisdictions? No – application of purposes would depend on jurisdiction and policy, which the drafting team considered outside its remit when simply describing the purpose
  • Criminal activities should also include hate crimes, infringement of civil liberties, etc. – these should be noted to ensure consideration during deliberation of this purpose
    • What constitutes criminal activity varies from one jurisdiction to another
    • For example, blasphemy vs. freedom of speech
    • What kinds of activities should be pursued through this purpose vs. who should have access to data for this purpose vs. consent given to collect data for this purpose
    • This purpose should focus on providing a mechanism to be used in jurisdictions, for activities, where it is appropriate
    • What do we do when law enforcement is “bad” and criminal activity is “good”?
      • Being able to notify a registrant that their DN has been compromised is clearly useful
      • Being able to use reputation scores to deter abuse and crime is good
      • Where we disagree is in use of registration data to investigate criminal activity
      • Legal processes for accessing data for this purpose will be determined by laws, not policy
      • For clarity, this purpose should be titled “Criminal Activity Mitigation and DNS Abuse Mitigation” (or Investigation of Criminal Activity and DNS Abuse, Notification of…, etc.) 

DT5 ICANN Contractual Enforcement – Slide 12

  • DT5 answers introduced by Beth
  • WG was joined by ICANN compliance staff Selim Manzak, Jennifer Scott, and Maguy Serad
  • Compliance staff confirmed that:
    • ICANN does NOT use registrant data to initiate contact with registrants – as ICANN does not have contractual relationship with registrants, ICANN notifies the contracted party instead (e.g., Registrar)
    • ICANN DOES use registrant data to investigate complaints and enforce compliance with contractual obligations – for example, to investigate unauthorized use of another’s name or address in a registration
    • Compliance cannot at this point make any assumptions about how the GDPR compliance model will impact their procedures or use of registration data

4. Deliberate on remaining possible purposes for processing gTLD registration data


Deliberation on ICANN Contractual Enforcement as a possibly legitimate purpose (beginning on p. 25 of PT2 of transcript; 02:18:25 in the recording)

  • Is this a legitimate purpose for whom? ICANN doesn’t have a contract with the registrant, so is this a legitimate purpose for registrars or for registries or for ICANN (as a third party with a legitimate interest in the data)?
  • ICANN is the data controller for escrowed data, so it by definition it has the data
  • Doesn’t ICANN still need to define a legitimate purpose for processing the data?
    • ICANN will have a defined purpose for collecting data to be escrowed (i.e., to provide for registration data restoration in the event of failure or de-accreditation)
    • That differs from accessing and processing the data to ensure compliance
    • Access to non-public data to verify that data is provided as contractually required
    • Shouldn’t assume that escrow contracts will remain the same in the future – cross-border data transfer restrictions may change where escrowed data can be stored
    • Can there be differences between escrowed data and current registration data? Yes
    • Is escrow out of scope for registration data policy? No – it is a processing activity applied to registration data collected for other purposes
    • ICANN doesn’t collect the data for the purpose of enforcing contracts (circular logic)
      • It accesses the data for this purpose
      • Deliberation to be continued on next WG call 

5. Confirm action items and proposed agreements

Action: Staff to append notes from F2F meetings and the DT answers to each DT’s original output, as input to deliberation on each purpose

Action: Staff to draft summary table of answers provided by DTs for all purposes, as input to deliberation

Action: Staff to identify sections of recording and transcript covering ICANN Contractual Enforcement, to help WG members not in attendance catch up in advance of 3/27 WG Call.

Action: Staff to relay 3/27 WG Call details to ICANN Compliance, with invitation to attend remainder of deliberation on this purpose.

Meeting Materials: https://go.icann.org/2FC9CdW


  • No labels