Saturday October 28, 2017 08:30 - 12:00 local time



REVISED AGENDA - SATURDAY 

Primary Goal: Shared understanding of existing purposes for gTLD registration data and directory services

1. Introductions and SOI Updates (Saturday 08:30-08:35)

2. PDP Background (Saturday 08:35-08:40) 

3. Meeting Goals (Saturday 08:40-09:00)

4. Purposes for gTLD registration data and directory services

  • Domain Name Control (Drafting Team #2, Saturday 09:00)
  • Domain Name Certification (Drafting Team #3, Saturday 09:30)
  • Legal Actions (Drafting Team #6, Saturday 10:00)
  • Regulatory or Contractual Enforcement (Drafting Team #5, Saturday 10:45)
  • Individual Internet Use (Drafting Team #2, Wednesday 11:15)

Teams to introduce their outputs for full WG discussion in the above order.
Approximate start times are subject to change as discussion progresses.

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


NOTES

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 here.

Primary Goal: Shared understanding of existing purposes for gTLD registration data and directory services

1. Introductions and SOI Updates

2. PDP Background 

3. Meeting Goals

4. Purposes for gTLD registration data and directory services

  • Clarify concept of purpose – difference between purpose and various uses. For example, research data isn’t a purpose for collection, it’s a purpose for disclosure
  • What do you mean by purpose – the WG has confused use cases with purposes. Many of the identified “purposes” may not be the purpose for collecting data (e.g.,,contactability)
  • Is this data required to perform your function? That’s a justification for collection. The next question is whether that is a legitimate reason for collection. If so, it is a “purpose.”

Domain Name Control (Drafting Team #2)

  • https://community.icann.org/download/attachments/69280635/RDS%20WG%20DT2%20Draft.pdf
  • Domain name registration creation, management, modification, transfer and contact for operational issues
  • Comments on Users:
    • Add URS where UDRP is listed,
    • Add gaining registrar (during transfer),
    • ICANN compliance should include audit staff and CTO office (“staff” too broad)
    • Should local law enforcement be added to users for this purpose?
    • Local = relevant to jurisdiction
    • Why should third parties have access for controlling changes to the DN record?
  • Should this be called Domain Name Management or Administration (not Control)
  • Definition includes registrant providing data to create registration, to manage registration, to modify that registration, to renew the registration, and to transfer the domain name
  • Is there overlap between this definition and the Contractual Compliance purpose?
  • Proposed purpose definition: ”Collecting information required to ensure DN remains under control of authorized user and to ensure no unauthorized changes are made”
  • Does the above capture the need for into to register the DN in the first place?

Domain Name Certification (Drafting Team #3)

  • https://community.icann.org/download/attachments/69280635/DraftingTeam3-DNCertification-Output.pdf
  • CAs often must bind TLS/SSL certificates to fully qualified DNs
  • DN-validated certs don’t use Whois today
  • Org and EV certs often use Whois to confirm enrolling org is listed as registrant of DN
  • Specified by CA Browser Forum Best Practices
  • Users: Employees/Systems of CA in pursuit of this purpose
  • Use RR/Ry ID, registrant, admin, and tech contacts
  • Question as to whether RDS is always used – Org and EV certs have been issued using alternative sources of data; you could have no RDS and still get such a certificate
  • EV certs must be explicitly validated by other means (such as Whois data)
  • Is there any data that CAs need that would not already be collected for DN control/management? Don’t think so
  • Not much reason to collect data just for this purpose, but if data exists, good reason to use it
  • Without independently obtained email address, how would this work?
  • Whois is easiest for consumer but there are alternative ways to reach CA requestor
  • If new data were collected for this purpose (e.g., CA Contact), the purpose would be information collected to facilitate the registrant being able to obtain a digital certificate
  • Even if not, could be a purpose for access to data collected for other purposes?

Legal Actions (Drafting Team #6)

  • https://community.icann.org/download/attachments/69280635/RDS%20WG%20DT6%20Draft%20-%20Revised%2010.26.2017%20v3.pdf
  • Assisting certain parties or their legal representatives or agents to investigate and enforce civil and criminal laws, protected legal rights, address online abuse or contractual compliance matters
  • Includes both third parties using data during investigation and registrants who might need to see data being used to defend themselves
  • Provisions in RAA to require disclosure of data to law enforcement
  • Data collected for contactability for <list of reasons, including legal actions>
  • For example, EWG proposed an (optional) Legal Contact to enable contact with the party responsible for handing Legal Actions, which may differ from your DN admin or your DN tech issues or the registrant – this data would be collected specifically for the purpose
  • Additional examples of blasphemy etc should be listed in the definition of the purpose
  • Suggest turning first paragraph into succinct statement

Regulatory or Contractual Enforcement (Drafting Team #5)

  • https://community.icann.org/download/attachments/69280635/DT5%20Deliverable%2026%20Oct%2017%20v2.pdf
  • Entities that have a remit to enforce obligations under contracts, industry best practices, or governmental regulation that relate to activities on the Internet
  • See comments made previously re: “staff” (too broad, be more specific)
  • Regulatory or contractual enforcers are separate from plaintiffs, because they are not at the same level in terms of what data they should have access to
  • What are the limits to this purpose?
  • For this purpose, often the WHOIS for IP is more important than the WHOIS for the DN
  • Noted that purpose/use case doesn’t distinguish between legitimate and non legitimate purposes – the boundaries of the use case
  • What does “best practices” refer to? Need to provide examples – such as, best practices for RRs/Rys which are not contractual mandates
  • Started with data that is available, which creates some interest in using the data, but that may not determine legitimacy of that use
  • How do IP owners fit into contractual enforcement? Some of the other users?
    Possible example – TM infringement for domain name (legal actions)
  • Which contracts? For example, ICANN’s contracts with contracted parties, contracts that RRs have with registrants, other contracts? Narrowing this down might help refine who the users are and what data is needed
  • Split apart contractual enforcement and regulatory enforcement to more clearly explain the two different cases and the users/data for each of those
  • Regulations to be enforce may include data protection and privacy laws
  • Ultimately purpose(s) may need to be renamed to more clearly indicate scope
  • May need to tease out what appear to be very different use cases (without deleting them) and to identify cases which may have overlap – which purpose(s) do they overlap?
  • Matrices might help pinpoint overlaps between purposes

Individual Internet Use (Drafting Team #2)

  • https://community.icann.org/download/attachments/69280635/RDS%20WG%20DT2%20Draft.pdf
  • Any Internet user, contacting the domain name registrant for information about their website/services –or- consumer protection where Internet user questions whether website is legitimate or wants to report malicious activity such as suspected phishing
  • Consumer protection could be divided into consumer themselves, vs. consumer protection agency which is covered elsewhere (regulatory enforcement)
  • May be the most complicated from a DP law perspective and what is legitimate
  • The average user who uses the Internet is not capable of using Whois
  • Concept of using Whois for consumer protection need to be unpacked from other uses
  • There are many spam reporting tools and other point-and-click tools that use WHOIS on the backend to provide reputation data to end users (eg Google report spam)
  • This purpose relates to ICANN Bylaws mandate to promote consumer trust in the DNS
  • Note this use case if for users other than Registrant (which is covered in DN Control)

5. Confirm action items and proposed agreements

  • Thanks for all for participating in session – broad participation very helpful
  • Further information about next steps to be discussed in Wednesday’s F2F session

Action Item: Drafting teams to take on-board the feedback received today and refine outputs.
Teams that presented today may still ask questions of WG at start of Wednesday session.
Teams that have not yet presented drafts may update draft outputs by Tuesday evening.


MEETING MATERIALS

  • Slides: ICANN60 RDS PDP F2F v3.pptx
  • List of Drafting Teams (includes team member lists & links to team email archives)
  • Drafting Team outputs:
    • DT1: Tech Issue Resolution [doc, PDF] and DNS Research (deferred, for discussion Wednesday)
    • DT2: Domain Name Control and Individual Internet Use [doc, PDF]
    • DT3: Domain Name Certification [doc, PDF]
    • DT4: Business Domain Name Purchase/Sale [doc, PDF]
    • DT5: Regulatory or Contractual Enforcement [doc, PDF]
    • DT6: Legal Actions [doc, PDF]
    • DT7: Criminal Investigation/DNS Abuse Mitigation [doc, PDF]
  • No labels