2017-08-08 Next Gen RDS PDP Working Group

Notes/ Action Items

Action Items:

1. WG members to continue discussion on the topic of the distinction between Registrar Data and RDS Data over the WG mailing list over the coming week, and possibly during the next WG call.
2. Staff to record in working document the revised WG Agreement #30: For resiliency, data enabling alternative or preferred method(s) of contact should be included in the RDS; further deliberation to determine whether such data element(s) should be optional or mandatory to collect.
3. WG members to provide suggestions on key concepts over the mailing list, based on today’s call discussion of alternative/preferred contact methods - Suggestions to be submitted by COB Friday, 11 August.
4. Leadership Team to discuss points covered in today’s call to identify any questions suitable for polling this week; Staff to develop poll at Leadership’s direction – WG members encouraged to participate in this week's poll no later than COB Saturday 12 August.

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.

1) Roll Call/SOI Updates

• Margie Milam has joined this WG as a member, and is now an employee of Facebook and a member of the Business Constituency

2) Continue deliberation on Data Elements beyond MPDS

a) Charter Question: "What data should be collected, stored and disclosed?" focusing first on set of data required in RDS

• See RDSPDP-Handout-8AugustCall.pdf
• Slide 1: Review of recently reached tentative agreements (#25 --> #29 and #31)
• Proposed WG Agreement #30 was unpacked for further deliberation as part of the 1 August poll, and will be discussed during this call
• All WG agreements are recorded in our working document, the latest version of which is https://community.icann.org/download/attachments/66086741/KeyConceptsDeliberation-WorkingDraft-1August2017.pdf

b) Deliberate on key concepts for alternative contact requirements - see AnnotatedResults-Poll-from-1AugustCall.pdf

• Slide 2 - Question 2 from the 1 August poll: Should alternative or preferred contacts be required in the RDS?
  • Split poll result between options a. For resiliency, data enabling alternative or preferred method(s) of contact should be included in the RDS and optional to collect (52%) and c. Same as a, except must be included and mandatory to collect (48%)
  • Distinction between two options is optional to collect in a. and mandatory to collect in c.
  • "data enabling...contact" means "data element(s) that enable contact through alternative or preferred methods" -- subsequent questions drill down on what data elements that might be
  • If "should be" is used then "mandatory to collect" is obviously not possible?
  • As noted in the poll, all poll questions focus only on collection of data; display/disclosure of data will be addressed separately
  • In reference to email from Michele Neylon and Andrew Sullivan to the WG mailing list, use of the phrase “in the RDS” in the poll questions should be clarified
  • ACTION ITEM: WG members to continue discussion on the topic of the distinction between Registrar Data and RDS Data over the WG mailing list over the coming week, and possibly during the next WG call.
  • ACTION ITEM: Staff to record in the working document the revised WG Agreement #30: For resiliency, data enabling alternative or preferred method(s) of contact should be included in the RDS; further deliberation to determine whether such data element(s) should be optional or mandatory to collect.

WG Agreement: For resiliency, data enabling alternative or preferred method(s) of contact should be included in the RDS; further deliberation to determine whether such data element(s) should be optional or mandatory to collect.

• Slide 3 - Question 3: If so, how many alternative or preferred contact values should be required?
  • Support split across choices c. At least two (and possibly more) alternative or preferred contact values must be required in the RDS (33.3%) and f. There should be no specific requirement for a minimum or maximum number of alternative or preferred contact values (41%)
  • Responses to this question to be discussed in conjunction with question 4
• Slide 4- Question 4: If so, what type(s) of alternative or preferred contact method(s) should be required?
  • Support split across choices b. Alternative or preferred contact data must include additional email addresses (41%), c. Alternative or preferred contact data must include telephone number(s) to receive voice calls (41%), f. Alternative or preferred contact data must include postal address(es) (37%) and h. There should be no specific requirement for alternative or preferred contact methods (41%)
  • Selecting more than one choice was possible, so percentages add up to more than 100%
  • This question discussed in conjunction with question 3 because the WG appears to be divided between those who prefer not to state a specific requirement for number or method, and those who prefer to see two or more alternative or preferred method(s) to include some combination of email, voice, and postal address
• Discussion on benefit or disadvantage of stating each specific requirement:
  • Postal addresses are not a reliable method to achieve contact-ability in some countries - postal address may be an optional method of contact, however, flexibility to provide other reliable alternatives for methods of contact should be permissible
  • Some jurisdictions require that legal notices be sent to a physical address - Does this create a requirement to collect postal addresses to be included in the RDS?
  • Other ICANN policies require use of postal mail to contact domain name registrants, such as UDRP providers, who are required to prove, for due process purposes, that they have sent a notice to registrant via postal services
  • Different jurisdictions and policies have different requirements on contact-ability - should WG step back and consider at a higher level why postal addresses need to be collected? – What is the identified requirement that mandates collection of postal address, and does it fulfill the need for contact-ability?

• Slide 5 – Question 5: If you support requirements for alternative or preferred contact method(s), what is the purpose of collecting this data?
  • Refer to the 8 August handout for comments submitted by WG members, which were categorized by staff into 5 categories including Contactability, Resiliency, Preference, Abuse Reporting, and Other
  • Discussion is indicating the need for a plurality of contact methods, such as email, phone and postal address - a requirement to collect all three should assist in ensuring that at least one of them is a reliable/preferred method of contact
  • Street addresses exist and are applicable to almost everyone, regardless of whether or not it is a reliable method of contact - may serve as a method of identification
  • If the WG recommends that contact methods such as postal address are not mandatory, then the WG must also note in recommendations that revision to existing policies that require use of these methods of contact would also be needed
  • Most registrants have structured postal addresses, which provide a method of contact-ability - exceptions to this do not eliminate it as a generally reliable form of contact - any policy arguments against collection of postal address must be compelling
  • Policy changes that conflict with others, such as the UDRP, may be problematic as these include due process requirements, including the requirement to contact a registrant via postal mail - need expert input on this
  • RDS PDP WG not restricted in its recommendations due to implications on other policies, however, these implications at a minimum must be noted and taken into consideration
  • Here we are discussing contact methods, not individual points of contacts (such as contacts taking on admin or tech contact roles) - we will discuss roles later in the agenda, to which each method may apply
  • Specifying which contact data/methods should be collected is important to take place now during policy development, to avoid it taking place during implementation of the policy in the absence of discussion
  • Concept of due process on legal proceedings that a person may be party to is broad - not limited to UDRP, which is only an example in which use of postal addresses is required
  • Collection of data does not imply public access - methods available to restrict/gate access to data, which may be granted to parties for whom legitimate purposes are identified
  • Data protection laws may require the purposes for collecting this data to be defensible
  • WG will need to discuss over-collection of data, and consider implications concerning practicality and applicable laws, but not now
  • Desire for privacy by some should be balanced against desire for due process by others
  • Summarizing some of the benefits given in chat: ability for sender to confirm receipt, ability to support policies and laws that require postal delivery., ability to determine jurisdiction Summarizing disadvantages: postal address not reliable in some locations and criminals may give fraudulent addresses anyway.  
  • It seems that comments are identifying underlying requirements (not specific to contact method itself) such as: at least one contact must be accurate, at least one contact must be trustworthy, at least one contact must be suitable for use in legal proceedings for due process

• Slide 6 - Based on discussion and comments provided by respondents to 1 August poll Question 5, are there key concepts that the WG can agree on?

Note: The purpose of the following informal show of hands is probing the level of support for concepts suggested in poll responses, so that poll questions can be constructed to test possible key concepts that may emerge from discussion

• Show of hands: "Do you support improved contactability as a purpose for collecting alternative contact methods?":
  • 11/29 WG members on call supported, 2/29 WG members disagreed
  • Contact-ability is binary, one can be contact-able or not - text of discussion question needs to be improved
  • If multiple contact methods are provided, the target may be reached faster or more easily, thus “improving contactability”
  • One suggestion: Alternative/preferred methods of contact may be limited to 2 methods - in the event of failure to contact a registrant using these methods, may contact the registrant via the registrar
  • Data in the RDS must allow for retrieval of contact data, and not require a subpoena to the registrar as only option to enable contact
• Show of hands: "Do you support resiliency to communication failure as a purpose for collecting alternative contact methods?":
  • 14/29 WG members on call supported, none disagreed
  • Several agreed with chat comment: Yes but it should be voluntary by the registrant
• Show of hands:"Do you support providing contacts with a choice of contact method as a purpose for collecting preferred contact methods?":
  • Question is trying to establish the reasons for collecting either alternative or preferred contact methods, based on comments given in the poll
  • 8/28 WG members on call supported, 3/28 WG members disagreed
  • Question needs revision, clarification on whether the registrant has the choice of what contact methods may be submitted/collected, or used to contact him/her
• Show of hands:"Do you support enabling reporting of domain name abuse as a purpose for collecting alternative contact methods?":
  • 10/28 WG members on call supported, 3/28 WG members disagreed
  • Several poll respondents indicated that a purpose for alternative or preferred methods of contact(s) might be to contact the registrant to alert them to domain name abuse or to report abuse
  • Domain name abuse can be reported, even if no contact methods are available
  • Might be helpful to have a domain name abuse role, but may not be a good enough reason to have alternative contact methods for the registrant
• ACTION ITEM: WG members to provide suggestions on key concepts over the mailing list, based on today’s call discussion of alternative/preferred contact methods - Suggestions to be submitted by COB Friday, 11 August
• ACTION ITEM: Leadership Team to discuss points covered in today’s call to identify any questions suitable for polling this week; Staff to develop poll at Leadership’s direction – WG members encouraged to participate in this week's poll no later than COB Saturday 12 August

• c) Deliberate on key concepts for role-based contacts - see PBC slides from 1 August call (Deferred to next call)

3) Confirm action items and proposed decision points

• WG Agreement #30: For resiliency, data enabling alternative or preferred method(s) of contact should be included in the RDS; further deliberation to determine whether such data element(s) should be optional or mandatory to collect.

Action Items: 

1. WG members to continue discussion on the topic of the distinction between Registrar Data and RDS Data over the WG mailing list over the coming week, and possibly during the next WG call.
2. Staff to record in the working document the revised WG Agreement #30: For resiliency, data enabling alternative or preferred method(s) of contact should be included in the RDS; further deliberation to determine whether such data element(s) should be optional or mandatory to collect.
3. WG members to provide suggestions on key concepts over the mailing list, based on this call’s discussion of alternative/preferred contact methods - Suggestions to be submitted to the mailing list by COB Friday, 11 August.
4. Leadership Team to discuss points covered in today’s call to identify any questions suitable for polling this week; Staff to develop poll at Leadership’s direction.

4) Confirm next meeting date: 16 August 05.00 UTC