Page History

Notes/ Action Items

Action Items and Notes from RDS PDP WG Call – 5 September 2017

Action Items:

1. Staff to add the three WG Agreements from this call to the Key Concepts Deliberation Working Draft Document
2. Staff to circulate recommendations in which the EWG leveraged Registrant Type as an illustration of the many ways it can be used, and to launch a poll with an open-ended comment box on how identification of "Registrant Type" might be useful

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: https://community.icann.org/x/YmfwAw

1) Roll Call/SOI Updates

• No updates to SOIs declared

 2) Brief updates: Legal analysis project, Action item(s) from last week, ICANN60 plans

•  Independent legal counsel (WSGR) was engaged to perform legal analysis on the impact of data protection laws on registration data and directory services. Counsel requested clarifications on WG questions sent to them, which have now been addressed. Final report from WSGR will be circulated to the WG once it is delivered, which is currently expected before the end of September.
•  WG F2F meetings at ICANN 60:
  • First meeting will be on Saturday, 28 October: 08:30 - 12:00 local time
  • Second meeting will be on Wednesday, 1 November: 16:00 - 18:30 local time
  • WG members are asked to plan ahead to attend these meetings, whether in person or remotely
• Action Item on "Original Creation Date"
  • Discussion underway in small group of volunteers, per action assigned in last week’s call
  • A few proposals on WG agreements have been suggested and are being discussed
  • Small group is aware of the required schedule to provide proposed agreement(s) text for deliberation back to the WG Leadership Team as well as to the broader WG

3) 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

b) Reach agreement(s) based on poll results: AnnotatedResults-Poll-from-29AugustCall.pdf 

• Question 2: Reseller

• Poll results:
  • Reseller Name MUST be supported by the RDS, and MAY/MUST be provided for inclusion in the RDS by Registrars. Note: There may be a chain or Resellers identified by Reseller Name.
  • 62% (b) – MAY be provided and 28% (a) – MUST be provided.
  • Confirms last week’s agreement on the first half of the statement, but demonstrates lack of consensus on MUST vs MAY be provided.
  • Decision to adopt this option as a tentative WG agreement, and defer discussion of MAY vs. MUST be provided to second pass deliberation in Phase 1 or Phase 2/3. 

WG Agreement: Reseller Name MUST be supported by the RDS. Note: There may be a chain or Resellers identified by Reseller Name

• Question 3: Registrar Abuse Contact(s)

• Poll results:
  • Per recently-approved consensus policy on consistent labeling and display (https://www.icann.org/resources/pages/rddslabeling-policy-2017-02-01-en), BOTH the Registrar Abuse Contact Email and Registrar Abuse Contact Phone must be supported for inclusion in the RDS, and MUST be provided by Registrars: 75% Support this statement
  • Question on why 25% of WG members objected to including the abuse contacts in the RDS, since a requirement to make them accessible exists in the RAA today - what is the reason to objecting to including these contacts in the RDS?
  • 3 of the poll respondents not supporting this statement do support one abuse contact being required, but do not support both abuse contact methods being required.
  • Re: question about distribution of responses across SGs, Leadership Team does regularly review poll results to ensure that all SGs are appropriately represented in the poll responses, but does not necessarily make a distinction on how SG responses are distributed across each individual poll question’s answers
  • Objection is the requirement to provide two abuse contacts for inclusion in the RDS - one should be enough
  • 2013 RAA requires that two abuse contacts be provided for inclusion in the RDS - other contacts (such as LEA contacts) might be more objectionable
  • Note that last week we had good support for abuse contact email address and slightly less support for abuse contact phone number - but we decided to try to be consistent with the recently adopted CL&D policy and support collection of both
  • Concerns about burden on smaller registrars to provide a 24/7 abuse hotline; however, a requirement to provide an abuse phone number doesn’t imply a 24/7 hotline
  • Registrars should be able to provide both email and phone contacts for abuse purposes, regardless of size of the registrar 
  • Discussion on publication of abuse contacts deferred until access requirements are on the WG agenda for deliberation
  • Registrars may not want abuse complaints over the phone. May need a paper trail for every complaint to cover liability. So if someone calls, registrars may tell them to send an email. In this case, a phone number helps no one, wastes registrars’s time
  • Communication via phone does not preclude an audit or paper trail, and could potentially be an efficient and more timely method of communication

WG Agreement: Per recently-approved consensus policy on consistent labeling and display (https://www.icann.org/resources/pages/rddslabeling-policy-2017-02-01-en), BOTH the Registrar Abuse Contact Email and Registrar Abuse Contact Phone must be supported for inclusion in the RDS, and MUST be provided by Registrars. 

• • Question 4: Alternative Contact Method(s)

• • No clear consensus on this question, however about 75% of choices involved either ALL or an open-ended list of alternative methods of contact
  • "Optional for registrants to provide" was helpful in the text of the answer choices as opposed to only "Optional"
  • Some ambiguity in the question: Are these alternative contact methods being suggested as option in addition to mandatory email/phone contacts? Yes, these are intended to be optional methods in addition to any that may be explicitly required by other WG agreements.
  • Open ended list of alternative contact methods could be implemented by including both the method of contact and the value in two separate fields (both optional to provide). For example, identifying SMS as an alternative contact method type and providing the SMS-capable phone number as the alternative contact method value.
  • Concern raised on implementation of open-ended alternative methods of contact without specifying standards - ambiguous, and may create implementation difficulties
  • Phase 2 will address specific policy and phase 3 implementation guidance - now we need to identify info required and why
  • Informal show of hands to indicate whether WG members agree with collection of an open-ended list of optional alternative contact methods: Broad support shown in the AC room with no objection
  • Previous WG agreements included rough consensus on a requirement to collect contact information such as email, but no WG agreement thus far on collection of fax and physical address as contact methods
  • Fax is just one "additional" method - some organizations still use if for "official" correspondence.
  • Fax may be a means to provide notice during legal correspondence - may indicate a need to collect fax as a contact method
  • RDS should support fax as an alternative contact method that is optional to provide
  • Proposed clarification: This WG agreement on alternative contact methods does not preclude agreements on requirements to include other contact methods.
  • Informal show of hands on Revised WG agreement (see below): 11 agree, none disagree
  • Requirements for phone and physical address will be deliberated on a future WG call

(Revised) WG Agreement: In the interest of maximizing contactability, additional contact methods MUST be supported by the RDS as an open-ended list and be optional for Registrants to provide. This does not preclude agreements on requirements to include other contact methods.

ACTION ITEM: Staff to add the three WG Agreements from this call to the Key Concepts Deliberation Working Draft Document.

 c) Deliberate on remaining data elements to reach additional agreements: 29AugustCall-Handout

 Registrant Type (see definitions by EWG on slide 11 of the RDSPDP-Handout-For29AugCall)

• Are there other Registrant Types that WG members would like to propose?
• Should registrants have the option to declare which Registrant Type they are? Can this be gamed?
• Why is the Natural Person the default registrant if field is left blank - this might provide undue protection to Legal Persons that they may not qualify for
• Note that definitions P/P Provider and Legal Person, Registrant Types include implications for collection of additional registration data – if the Registrant Type is a P/P Provider that is accredited by ICANN, Contact ID of the accredited Privacy/Proxy Provider must also be supplied to enable relay/reveal request escalation to the PP PBC (or designated Business PBC in the case of a Legal Person for consumer inquiries and complaints) – has implication on collection as well as display of data elements
• One significance of the choice between natural and legal persons is privacy laws, which give higher levels of privacy to natural persons
• Nominet policy for .uk includes a verification step to ensure that those who declare themselves as natural persons indeed are natural, not legal persons - not clear how this can be done in the RDS, but worth noting
• Nominet has many different classification options for Registrant Type, but validation of contact information is not associated with these options
• Extensive discussions took place on the PPSAI PDP on commercial use of a domain name - would not be advisable to repeat that discussion on this PDP. (Note that the EWG declined to specify Commercial Use as a data element; Registrant Type does not imply the domain name is used for commercial activity.)
• With the evolving privacy law environment, it is helpful to know if a registrant is a natural or legal person - legal persons should wish for their contacts to be publicly available
• Processes may exist to resolve disputes on gaming when a legal person self-identifies as a natural person
• "Undeclared" may be an appropriate option, even for legal persons, if the domains registered are not used at all (such as being parked)
• Possible to add an extension to EPP to allow for a Registrant Type to be declared, however extensions to the protocol is optional - needs to be standardized from an implementation perspective, and must be uniform across all registry operators and registrars - this will require a great deal of work, and not clear that the benefit is worth the effort (time and money) required to implement - Evaluation of value vs benefit should be made
• Discussing Registrant Type is a solution to a problem that the WG does not completely have an understanding of yet - need to first understand the privacy law context before offering a solution, such as Registrant Type – suggestion to defer the decision until after the WG receives the final legal analysis report on the implications of data protection laws on registration data and directory services
• Might be helpful to include a poll question with an open-ended comment box on how "Registrant Type" might be useful, then revisit the discussion following the delivery of the final legal analysis report regarding implications of data protection laws such as the EU GDPR

ACTION ITEM: Staff to circulate recommendations in which the EWG leveraged Registrant Type as an illustration of the many ways it can be used, and to launch a poll question with an open-ended comment box on how identification of "Registrant Type" might be useful

4) Confirm Action Items and WG Agreements:

ACTION ITEM: Staff to add the three WG Agreements from this call to the Key Concepts Deliberation Working Draft Document

ACTION ITEM: Staff to circulate recommendations in which the EWG leveraged Registrant Type as an illustration of the many ways it can be used, and to launch a poll question with an open-ended comment box on how identification of "Registrant Type" might be useful

WG Agreement: Reseller Name MUST be supported by the RDS. Note: There may be a chain or Resellers identified by Reseller Name.

WG Agreement: Per recently-approved consensus policy on consistent labeling and display (https://www.icann.org/resources/pages/rddslabeling-policy-2017-02-01-en), BOTH the Registrar Abuse Contact Email and Registrar Abuse Contact Phone must be supported for inclusion in the RDS, and MUST be provided by Registrars.

(Revised) WG Agreement: In the interest of maximizing contactability, additional contact methods MUST be supported by the RDS as an open-ended list and be optional for Registrants to provide. This does not preclude agreements on requirements to include other contact methods.

5) Confirm next WG Meeting: Tuesday, 12 September at 16:00 UTC