2017-08-22 Next Gen RDS PDP Working Group

Notes/ Action Items

Action Items:

1. Staff to record preliminary WG agreement concerning alternative contact method in key concepts deliberation document as follows: “To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field”.
2. Staff to record preliminary WG Agreement concerning PCBs in key concepts deliberation document as follows: “PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide”.
3. Staff to create a poll to gauge support on 5 remaining mostly agreed to data elements (per 28 June poll) being supported by the RDS: reseller, URL of complaint site (INTERNIC site), original registration date, registrar abuse contact email address and registrar abuse contact phone.

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

1) Roll Call/SOI Updates

• Nathalie Coupet: Appointed as the Executive Director of Opera Company Brooklyn

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

b) Review poll results for alternative contact requirements – see SummaryResults_poll_from_16AugustCall.pdf

Alternative contact method

• Poll statement: In order to provide resiliency to overcome communication failure, at least one alternative contact method (possibly multiple alternative contact methods) MUST be supported by the RDS as an optional field(s)
• 68% of WG members who participated in the poll agreed with the poll statement, 8% disagreed and 24% proposed alternative wording. Note, several of those proposing alternative wording did support the underlying concepts of the poll statement.
• Suggested rewording by Marc Anderson: To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field. Optional submission of alternative contact methods suggested supported by several WG members.
• Suggestion to declare rough consensus on suggested rewording.
• WG leadership team discussed the possibility of requiring alternative contact methods including phone and physical address, but decided to defer discussion to a later time - current proposed alternative rewording allows for "optional" alternative contact methods
• Some noted that not requiring alternative contact methods including phone and physical address may reduce resiliency of contactability.
• Key concept should focus on the capability of the RDS to support the collection of alternative contact methods, without defining what those alternative contact methods look like.
• Requiring alternative contact methods could be a business decision to increase resiliency of contactability. RDS could only require one validated contact method (such as email) - if a registrant is not contactable via the required contact method, could result in loss of the registration of a domain name.
• Don't have to have more than X contacts (currently 3 - e-mail/phone/physical - fax optional 4), but need to support the ability to handle things like social network contacts, SMS, chat, and future comms methods.  People can still make individual decisions on what to provide/support. Different contact methods work differently in different countries around the world - one contact method may work more effectively in one country, while another may be more effective as a communication method elsewhere.
• Proposed WG agreement in the poll requires that the RDS must support at least one alternative contact method (possibly multiple), without requiring their collection. The objection of a small number of WG member (5) on the call to the proposed WG agreement was noted during the call, with the majority of WG members on the call supporting the WG agreement as reworded: To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field. Objections to proposed rewording included that the statement lacks clarity, that alternative fields that must be supported should not be optional, and more than one alternative field must be supported by the RDS.

Preliminary WG Agreement: To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field.

ACTION ITEM: Staff to record preliminary WG agreement concerning alternative contact method in key concepts deliberation document.

 PBCs

• Poll Statement: PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide
• 65% of WG members who participated in the poll agreed with the poll statement, 17% disagreed and 17% proposed alternative wording. Of the latter, several put forward alternative wording similar to the statement in the poll - if added to 65% who support it, would indicate rough consensus.
• Suggestion of leadership team to declare rough consensus on the statement: PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide
• If the PBCs identified are optional, and not provided by the registrant, what other contacts would be provided as alternatives? If no PBCs are provided, and primary contact method (email) fails, then the result would be that the registrant would be in danger of losing the domain name.
• Future discussions, such as on gated access, could result in limited access to specific contacts depending on the accessibility of the requestor (example: UDRP provider may be granted access to legal contact) – could this mean that a blank field is returned if no info is entered for that specific contact? If a registrant decides not to provide PBCs it makes the registrant responsible for all queries so it would likely default to the registrant contact info. The additional roles are provided as a convenience to the registrant if he/she wants to make a distinction.
• The answer to "what is the value when it has not been provided" is that there must be a default value.  The default value is simply copied from something, perhaps the registrant information - the additional roles are provided as a convenience to the registrant who wants to make a distinction. In the absence of PBCs, the role will default to the registrant.
• Would adding a clarification like the following help: "Should a registrant decide not to provide a separate contact for these PBCs, the registrant contact is expected to deal with queries relating to these purposes identified.", or “Should a registrant decide not to provide a separate contact for these PBCs, the registrant contact will be provided as the default info for these PBCs”?
• Concerns raised should be noted for further/future discussion, but possibly not a good time to be prescriptive on specific PBCs at this time - need to consider various possible issues around this discussion
• 3/33 WG members on the call noted objection to accepting the statement: "PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide" as a WG agreement.
• It was pointed out that all WG agreements are labelled preliminary and will need to be considered in conjunction with all other recommendations which could result in changes / updates. WG agreements are part of an iterative process, and should not be perceived as a final conclusion - WG agreements may very well be revisited as the need arises.

Preliminary WG Agreement: PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide

ACTION ITEM: Staff to record preliminary WG Agreement in key concepts deliberation document: PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide.

c) Deliberate and consider next steps in relation to remaining data elements that most agreed should be in RDS (see AnalysisResults-Poll-from-28JuneCall.pdf)

• Focus of discussion on data elements (including mostly agreed data elements) is focused on possibility for collection in RDS, not access.
• Data elements already covered by previous WG agreements include Registrant Name/Organization, Registrant Country, Registrant Email, PBCs (Admin, technical and P/P) as well as PBCs discussed on today's call
• Remaining data elements in the mostly agreed category to be considered include reseller, URL of Internic complaint site (ICANN WHOIS Problem reporting site), original registration date, registrar abuse contact email address and registrar abuse contact phone
• URL of complaint site (INTERNIC site) is not distinct for individual registrants - not necessary to discuss in the context of collection of data to be included in the RDS. Not every data element is collected from the registrant (example: some data elements are generated)
• Registrar may not know the ultimate reseller, so may complicate collection of this data element. Dealing with collection of data of unknown resellers (such as chains of resellers) could be dealt with during implementation.
• No objection to the RDS supporting the 5 remaining data elements in the mostly agreed category – to be confirmed through poll.
• 5 data elements on which more WG members disagreed or were unsure: Registrant Fax + Registrant Fax Ext, Registrant SMS, Registrant IM, Registrant Social Media and Registrant Alt Social Media
  • Should the RDS support these 5 data elements?
  • Preliminary WG agreement from today regarding the RDS supporting at least one additional contact method (optional to collect) may cover the question of the RDS supporting these data elements - discussion on these 5 contacts provides further specificity on which alternative contact methods must be supported by the RDS, and may be collected. Some noted that it may not be necessary to provide this level of specificity with regards to alternative contact methods to accommodate new methods that may not exist yet. Alternative approach could be to consider optional "other" field that is free-form syntax. It could even be multi-valued (i.e., you can have more than one).
  • Some of these decisions are going to be influenced by the legal opinion on privacy considerations - The DPAs have pointed out in the past that over collection is an issue.  Does not mean the registrar does not have to collect it. But some elements might not be held in the RDS, let alone displayed or published.
  • Independent legal review on compliance with GDPR is expected to provide a final report soon, which may require some preliminary WG agreements to be revisited.
  • Faxes are sometimes used within certain legal contexts - this should be considered.

ACTION ITEM: Staff to create a poll to gauge support on 5 remaining mostly agreed data elements being supported by the RDS: reseller, URL of complaint site (INTERNIC site), original registration date, registrar abuse contact email address and registrar abuse contact phone

Confirm Action Items:

1. ACTION ITEM: Staff to record preliminary WG agreement concerning alternative contact method in key concepts deliberation document as follows: “To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field”.
2. ACTION ITEM: Staff to record preliminary WG Agreement concerning PCBs in key concepts deliberation document as follows: “PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide”.
3. ACTION ITEM: Staff to create a poll to gauge support on 5 remaining mostly agreed to data elements (per 28 June poll) being supported by the RDS: reseller, URL of complaint site (INTERNIC site), original registration date, registrar abuse contact email address and registrar abuse contact phone.

Preliminary WG Agreement: To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field.

Preliminary WG Agreement: PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide

d) Confirm next WG meeting (Tuesday 29 August at 16.00 UTC)