2017-07-18 Next Gen RDS PDP Working Group

Notes/ Action Items

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

1. Introductions and SOI Updates 

• Attendance taken from AC
• SOI updates: Chuck Gomes has retired from Verisign, but will perform consulting services for Verisign involving chairing this PDP in a neutral capacity

2. Continue deliberation beyond "minimum public data set" 

• Charter Question: "What data should be collected, stored and disclosed?"
• See expanded handout and poll results: https://community.icann.org/x/SWfwAw

a. Review agreed approach and general comments: "Concentrate on the set of data elements that may be collected and possibly displayed in the RDS. That is, review the entire table of proposed elements, deciding what to delete/add." 

• Roll-up for all results of questions 2 - 39 are presented, except for question 40, which is addressed separately
• Color-coding and support column meant to assist in identifying level of support for each data element
• Numbers in Support column calculated by the sum of views expressed for each data element with weighted responses: Strongly Agree: 2, Agree: 1 Neutral/Unsure: 0, Disagree: -1 and Strongly Disagree: -2
• Results also displayed in graphical form on page 6 of the document, with color-coding displaying the levels of support, explained in a legend on the same page

b. Deliberate on rationale for data elements that are broadly supported: 

• The scope of registration data elements is those that ICANN defines and has control over
• Some comments indicated an assumption that inclusion implies display/access. That was not the intent. WG agreed to focus on the set of data elements to be included in the RDS first, before deliberating on display/access in subsequent discussions
• RDS is a repository of data elements that may or may not be accessible under yet-to-be-specified conditions (i.e., may result in multiple levels of access), but this is subject to further consideration and discussion by the WG 

• Registrant Name
  • Poll results: 27 Agree, 2 Neutral/Unsure, 6 Disagree
  • Registrant Name is a clearly-defined existing WHOIS data element.
  • Per 2013 RAA: Registrant is the entity that has acquired the right to use the Internet resource (here, Domain Name)
  • Registrant Name needs to be considered in a broader context than domain used by websites (example: use of a domain name for email, registrars need to know who their clients are, etc...)
  • Privacy is a policy consideration on how Registrant Name is processed (to be determined), but does not preclude the value of collecting it as a data element - need to disentangle the need for a data element in the database versus what will be collected (example: this data element may be populated by a Registrar, Privacy/Proxy (P/P) service provider, or the Registrant itself, depending on circumstances)
  • If Registrant Name data element is filled with the name of a Proxy service provider, does that create some overlap or redundancy with Privacy/Proxy Contact data elements? Note: P/P Contact contains contact details for the P/P, not just the provider’s name. Also, for Privacy-registered domain names, the Registrant Name does not carry the provider’s name.
  • Should data element be Registrant Name or Organization or P/P provider name?
  • Regardless of which actor's data is collected for this data element, it will be populated, whether by the name of a person registering the domain name, the name of an organization registering the domain name, or a Proxy service provider registering a domain name on behalf of someone else
  • Data element could collect data that does not identify a specific person (such as "domain admin"), connected to real contact data (such as an email address to reach the domain admin), but does not necessarily need to be a real person's name
  • Note there is also a Registrant Contact ID – a unique numeric value assigned to each Registrant by the Registrar – but it didn't have as strong support and so isn't displayed on this page of poll results
  • Knowledge of the identity of a domain name Registrant is necessary in scenarios such as disputes resulting during a domain name transfer, or if a registrar ceases its operation (data would be accessible via a data escrow provider)
  • Regarding comments from those who disagreed, we are starting with collection and not display. For many purposes, Registrant Name is necessary, even if it is not displayed
  • Suggestion to rename this data element to "Registrant Label" or simply "Registrant" - could be a name, a pseudonym, an organization, a P/P provider - whatever it is, this data element needs to be in the RDS, regardless of whether it will be displayed or not
  • Suggestion to rename the data element may require a definition of what the data element is meant to represent - will slow down the process, especially if renaming is repeated with other data elements
  • Suggestion to determine what contact information is required as data elements in the RDS, then associate roles for each contact data element. For example, the same email address might be used to contact the Registrant and to resolve technical issues – those would be two roles using that email address (or contact)
  • ACTION ITEM: Staff to develop a preliminary definition for "Registrant Name" (Registrant) based on existing definition in the RAA, as well as the discussion of this data element during today's call, which will be subject to review by the WG 

• Registrant Organization
  • Poll results: 27 Agree, 2 Neutral/Unsure, 6 Disagree
  • This data element may not be applicable to every domain name, if there is no Organization associated with the Registrant
  • According to the 2013 RAA: For the Registrant, Admin and Tech contact fields requiring a "Name" or "Organization", the output must include either the name or organization (or both, if available).
  • Collecting this data element may therefore be optional.
  • Another option may be to collect this data element, but not display it publicly 

• Registrant Country
  • Poll results: 28 Agree, 2 Neutral/Unsure, 5 Disagree
  • Comments indicating that data should not be collected due to privacy concerns should be addressed as agreements whether or not to display/access this data - does not obviate the need to collect it
  • Several comments cite “Registrant Country” as important to identify jurisdiction
  • "Registrant Country" may be useful in the context of multinational corporations with operations in different countries or TLDs which are not permitted in certain jurisdictions
  • For example, location of technical staff registering a domain name in a multinational corporation may be what determines the Registrant Country – or the multinational corporation’s head office location may determine Country 

• Registrant Email Address
  • Poll results: 28 Agree, 3 Neutral/Unsure, 4 Disagree
  • Email address is the primary method of contact between a Registrar and Registrant - necessary for collection
  • Email address also necessary for a dispute provider to contact a Registrant
  • Is it necessary to collect email addresses, or should choice of preferred contact method be optional? Should it only be necessary to have the ability to contact the Registrant (possible qualifier during future consideration/discussion)?
  • Useful to consider what the preferred method of contact for each Registrant is, however need to consider how that would affect existing policies in place
  • Whois accuracy reporting focuses on the ability to contact a Registrant
  • Proposed Question: Is collection of Registrant contact information required for the RDS? (as opposed to collecting specific types of contact information)
  • Important to consider contact redundancy solutions, when one contact does not work - alternative options may be required
  • Qualification of context of collection of Email Address to be clarified
    • Should collection of Email Address be optional if other means of contact are more preferable by the Registrant?
    • Do other methods of contact provide redundancy solutions in the event of a failure to contact a Registrant using primary preferred method?
    • How will existing policies be affected? 

• Admin Contact and Contact ID (deferred) 

• Technical Contact and Contact ID
  • Do WG members understand what purpose this contact in meant to serve? Hasn't been useful in the past, and has often been a redundant element, which mirrors the Admin Contact and/or Registrant details
  • Members of the IPC indicated that this is one of the data elements that they use - IPC members should clarify how this data element is useful during the discussion
  • The WG needs to define (provide consistent definitions) for what is intended for each data element, and provide guidance on collection and disclosure requirements for each defined data element
  • WG members to develop consistent definitions for the various data elements, which are to be collected, generated or displayed (this is part of our charter)
  • In addition to defining data elements, it should be clear what each element is referring to. For example, some resellers have default setting that populate Technical Contact data elements with the reseller’s own data
  • Potentially less useful data elements might need to be optional for collection - other contacts, such as hosting provider, could be more useful 

• Privacy/Proxy Provider Contact and Contact ID (deferred) 

• Reseller (deferred) 

• Registrar Abuse Contact Email Address (deferred) 

• Registrar Abuse Contact Phone (deferred) 

• URL of Internic Complaint Site (deferred) 

• Original Registration Date
  • Does this data element refer to the first time this domain name was ever registered, or does it refer to the date on which the current registrant registered it - different contexts may have different uses, or create incorrect assumptions
  • This date element was proposed by the EWG with the following definition: “The date on which this domain name was first registered. This is different than the creation date since the creation date picks up the latest time the domain name was registered; it is possible that the domain name was previously registered and subsequently deleted multiple times. The Original Registration Date denotes the first date that the domain name was ever registered.”
  • This may be useful for copyright and trademark issues; purposes listed in the EWG report included DN control, business DN purchase/sale, DNS research, regulatory and contractual enforcement, and criminal investigation/DNS abuse mitigation 

c. Deliberate on deletion of data elements that are largely unwanted (time permitting) (deferred) 

d. Deliberate on remaining data elements (time permitting) (deferred) 

e. Deliberate on new data elements (deferred)

• Continue discussion of new data elements suggested in Q40, possibly using a poll for input on viability of these new elements being collected for inclusion in the RDS

3. Confirm action items and proposed decision points 

ACTION ITEM: Chuck Gomes to send discussion topics to list, including remaining green (mostly-agreed) elements in preparation for next week's call. All WG members are invited to participate in focused on-list discussion of these topics.

ACTION ITEM: Leadership to develop poll for next week to confirm understandings reached during this call on the data elements discussed (Registrant Name, Registrant Organization, Registrant Country and Registrant Email Address), to reveal level of agreement following clarification of intent for collection (not display) of each data element. Staff to implement poll; all WG members encouraged to participate in poll.

ACTION ITEM: Staff to develop a preliminary definition for "Registrant Name" (Registrant) based on existing definition in the RAA, as well as the discussion of this data element during today's call, which will be subject to review by the WG

ACTION ITEM: Staff and/or Rod Rasmussen to provide an overview of the EWG's contact paradigm to help the WG delve into this concept

4. Confirm next meeting date: 25 July 16.00 UTC

Meeting Materials:

• Expanded Handout on Poll for Data Elements – 28 June
• Analysis of Survey Results