[gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from RDS PDP WG Call - 1 August 2017
Amr Elsadr
amr.elsadr at icann.org
Tue Aug 1 21:05:23 UTC 2017
Dear Working Group Members,
Below are the action items and notes from today’s WG call. The action items, notes and meeting documents have been posted on the meeting’s wiki page here: https://community.icann.org/x/VWfwAw. The recordings and transcripts will be posted to the same page as soon as they are available.
Thanks.
Amr
Action Items:
1. Leadership to develop new poll question(s) based on Q6 discussion to re-poll on concepts raised. All WG members encouraged to participate in the poll by COB Saturday.
2. Staff to redistribute slides from Marrakech meeting drawn from SAC054, to kick off on-list discussion of what it means to be "in the RDS."
3. Staff to incorporate the following WG agreements in the working document:
* WG Agreement #26: RDS policy must include a definition for every gTLD registration data element including both a semantic definition and (by reference to appropriate standards) a syntax definition.
* WG Agreement #27: At least one element identifying the domain name registrant (i.e., registered name holder) must be collected and included in the RDS.
* WG Agreement #28: Data enabling at least one way to contact the registrant must be collected and included in the RDS.
* (Revised) WG Agreement #29: At a minimum, one or more e-mail addresses must be collected for every domain name included in the RDS, for contact roles that require an e-mail address for contactability
* WG Agreement #31: At least one element enabling contact must be based on an open standard and not a proprietary communication method.
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
* SOI Updates:
* Alan Greenberg is now a member and interim Chair of the RDS-WHOIS2 Review Team
* Volker Greimann, Stephanie Perrin, Carlton Samuels, and Susan Kawaguchi are also now members of the RDS-WHOIS2 Review Team
2) Continue deliberation beyond "minimum public data set"
a) Charter Question: "What data should be collected, stored and disclosed?" focusing on identifying set of data required in the RDS first
b) See annotated poll results from 25 July call
* Question 2
* Proposed WG Agreement #26 - rough consensus (82%)
* Results: 82.61% Agree, 17.39% Unsure/No Opinion
* There was no objection on the call to accepting this key concept as a WG agreement
WG Agreement #26: RDS policy must include a definition for every gTLD registration data element including both a semantic definition and (by reference to appropriate standards) a syntax definition.
* Question 3
* Proposed WG Agreement #27 - rough consensus (82%)
* One WG member participating in the poll disagreed - WG members who disagree are encouraged to provide rationale
* Agree: 82.61%, Disagree: 4.35% (1 member), 13.04% (Unsure/No Opinion)
* In Question 3, “registrant” could also be referring to a proxy provider - WG has accepted consensus policy that proxy provider may be identified as the registrant on previous WG calls
* If proxy provider or legal representative of registrant are listed as the registrant, they assume responsibility of the domain name registration, unless they disclose the identity of the customer actually using the domain name (see 2013 RAA and PPSAI Final Report for further information)
* Distinction should be made between privacy and proxy registration – for a domain registered with a privacy service, the privacy provider is not the registrant, while for a domain registered with a proxy service, the proxy provider is the registrant
* From RAA: The Registrant is the entity that has acquired the right to use the Internet resource. A Domain Name Registrant is the person or organization who has registered the domain name, also referred to as a Registered Name Holder.
* After discussion, there was no objection on the call to accepting this key concept as a WG agreement.
WG Agreement #27: At least one element identifying the domain name registrant (i.e., registered name holder) must be collected and included in the RDS.
* Question 4:
* Agree: 78.26%, Disagree: 4.35% (I WG member), Unsure/No opinion: 17.39%
* Proposed WG Agreement #28 - rough consensus (78%), (c) Disagree: 8.70%
* It was noted that “at least one way” does not preclude more than one way; further discussion under Question 5
* After discussion, there was no objection on the call to accepting this key concept as a WG agreement.
WG Agreement #28: Data enabling at least one way to contact the registrant must be collected and included in the RDS.
* Question 5:
* Answer choices (a) 53.17% and (b) 39.13% cumulatively agree, (c) 8.70% disagree
* Proposed WG Agreement #29 - split a/b (52%/39%)
* Rationale for disagreement in poll: Problems with email access may create impediments to following up with correspondence regarding domain name registrations
* Requiring email as a contact does not preclude other forms of contact methods being collected/used - language of poll question includes "at minimum"
* Concern expressed about requirement to have/use an email address to register a domain name - there are other legitimate methods to contact domain name registrants
* Registrants don't necessarily have to be the recipient of email sent to that address - may be entities serving in other roles - but care should be taken in terms of other processes/policies where email contact is a cross-cutting requirement - key concept worded specifically to reflect this understanding
* Login for the registrar’s web-based services may be tied to the email address
* Some customers use an email address while registering for a service, and may stop/use a different email or contact method without updating their contact information
* "At minimum" is not "At most" - option a) states that email address to reach the Registrant is mandatory to collect and include in the RDS
* option b) states that one or more email address(es) to reach contact(s) serving in certain roles is mandatory to collect and include in the RDS
* Registrants who use the domain being registered as part of the contact address create a risk if the domain stops working - contact method stops working - WG might want to consider whether it wishes to allow this
* Alan Greenberg to propose a reworded key concept to be discussed on-list to address overlap between email address used to register a domain name, and email address used for email contact thereafter
* No objections by WG members on the call to accepting option (b) as the rough consensus WG agreement for this key concept
(Revised) WG Agreement #29: At a minimum, one or more e-mail addresses must be collected for every domain name included in the RDS, for contact roles that require an e-mail address for contactability
* Question 6:
* (a) 21.74% and (b) 56.52% indicate agreement
* Distinction between options (a) and (b) include "must" vs "may" - option (a) requires an alternative method of communication
* Current status quo requires at least two other contact methods - useful to have other methods of communication in the event that email fails
* Another Proposed alternative: In addition to email address, data enabling two alternative methods of contact must be collected and included in the RDS.
* Several concepts are reflected within these three alternative phrasing, including whether to require alternative/preferred contacts, how many should be required, what alternative contact methods should be required, etc.
* See further discussion under agenda item 2c) below
ACTION ITEM: Leadership to develop new poll question(s) based on Q6 discussion to re-poll on concepts raised
* We need to clarify that the data currently collected, disclosed, and escrowed as provided by the RAA may be surplus to what is permissible under the GDPR
* Question 7:
* Agree: 86.96%, 13.04: Unsure/No Opinion
* Proposed WG Agreement #31 - rough consensus (87%)
* There was no objection on the call to accepting this key concept as a WG agreement.
WG Agreement #31: At least one element enabling contact must be based on an open standard and not a proprietary communication method.
Action Item: Staff to incorporate the above WG agreements in the working document:
c) Deliberate on key concepts for Registrant Email Address and other contact methods
* What risks is the WG trying to manage - is it associated with security/stability of the DNS?
* WG not considering publication/display of this data at this time - only considering collection and inclusion in the RDS
* Alternative methods of communication may be required by the registrar to be able to contact registrants/customers, but not necessarily include them in the RDS
* WG cannot address all forms of risks, however email is a contact method that does carry risk, so practical to have alternative methods of contact available in the RDS
* Not clear if within ICANN's mandate to require registrars to collect data that is not included in the RDS - should ICANN mandate registrar business practices?
* Some data is collected by registrars to assist them in meeting their contractual obligations, without including them in the RDS, as well as information outside of the purview of ICANN and domain name registration (such as data collected for the purpose of provision of web hosting services)
* Recall a year or so ago when we discussed SAC054, Report on Domain Name Registration Data Model (June 2012) and noted some data is collected that is beyond the scope of RDS data: https://www.icann.org/en/system/files/files/sac-054-en.pdf
* Some data collected for RDS purposes, others collected to meet contractual obligations in the RAA (but not to be included in the RDS), while others are collected by registrars for unrelated reasons altogether
* In developing countries and rural areas in developed countries, communication methods are not reliable or constant - there are legitimate purposes to contact registrants in these areas at times, so alternative methods of communication are necessary, and should be made available via the RDS
* Discussion of this point to be continued on-list in the coming week
Action Item: Staff to redistribute slides from Marrakech meeting drawn from SAC054, to kick off on-list discussion of what it means to be "in the RDS."
d) Overview of EWG Report Contacts Concepts: PBC-Overview-1August.pdf
* https://community.icann.org/download/attachments/66086741/PBC-Overview-1August.pdf
* Rod Rasmussen prepared and presented this overview, at the request of leadership
* Slides drawn from EWG presentations made on Purpose Based Contacts, to introduce concepts as input to this WG
* Slide 2: Concept is to define a set of roles and concepts around how roles are collected and displayed. Apply concepts consistently for all roles that are eventually agreed.
* Slide 3: Each role is tied to a contact - block of data enabling contact with someone serving in that role. Each contact has an ID (ROID), allowing the contact to be linked to domain names that are using that contact in some role. This allows reuse of contacts in many domain names, across all DNs someone may register.
* Slide 4: Some registrars create objects for contacts and allow reuse of that contact, within a registrar or registry (e.g., Network Solutions NIC handles long ago). Today those contacts don't have to be reusable and cannot be shared across registries. (Note slide illustrates that some (most) contact data is to be gated in the EWG Report, but that is a separate point of deliberation). Importantly, entities that create contacts are allowed to manage their own contact data, separately from domain name registrations that use them - and also must give permission to be designated as serving in a role for each DN that does so.
* Slide 5: Two examples of roles - here, P/P Provider and Business Contact - but the idea is that every role can be linked (via ID) to a contact where the data can be found when appropriate to display
* Slide 6: Three examples of DN registrations: individual using own data for contact data in all roles, individual using a proxy provider as contact in many roles, business using third party contacts that differ for each role.
* Slide 7 - How do contacts get created? The idea the EWG proposed is that an entity that wants to be a contact for at least one DN creates a contact using a "validator." Registrars could be validators if they choose, but so could others - this unlinks registrars from the function of collecting contact data. (Note that slide touches on validation, but accuracy is to be deliberated separately) Then when you register a domain name, you use contacts for certain roles by referring to ID. Registrars could automate some of this behind the scenes if they choose.
* Slide 8: Illustrates the benefits of allowing entities to create and manage their own contacts and (when needed) update contacts to fix obsolete or inaccurate data - fix once, fixes apply to all DNs that refer to the contact
* Slide 9: For background reference, to see how all the pieces fit together.
* Question: If contact data is associated with ROIDs, does this require identity validation of contact? Does it require a single database of persons associated with ROIDs? [Repository Object IDentifier in EPP]
* Answer: There is nothing saying you cannot create multiple contacts for yourself, with different ROIDs - but this allows for creation of reusable contacts by those who want to (e.g., businesses with many DNs) to reduce effort and inaccuracy. Enables more efficient validation.
* Question: Worried about the Registrant ID field. That being public would allow anyone to figure out the complete set of domains owned by a registrant. And that may allow cross-referencing detective work
* Answer: Yes, this can be helpful for anti-abuse. However, registrants/contacts can choose not to reuse contacts if they wish to avoid.
* Question: Does this force any registrant to go through a registrar or validator?
* Answer: This WG still needs to decide what's in or out of the MPDS - slide 9 just shows the EWG's take on that, which relied on public IDs and gated access to contact data. We still need to discuss these concepts in the PDP WG.
* Question: Admin and Business seem similar, did the EWG consider combining? Yes, Admin is contact about the DN itself, versus optionally publishing a contact for customers to use to reach the business itself.
e) Deliberate on "roles" that were broadly supported: Admin, Tech, Abuse, Privacy/Proxy (deferred, pick up next week)
3) Confirm action items and proposed decision points
Action Items:
* Action Item: Leadership to develop new poll question(s) based on Q6 discussion to re-poll on concepts raised. All WG members encouraged to participate in the poll by COB Saturday.
* Action Item: Staff to redistribute slides from Marrakech meeting drawn from SAC054, to kick off on-list discussion of what it means to be "in the RDS."
* Action Item: Staff to incorporate the following WG agreements in the working document:
Working Group Agreements:
* WG Agreement #26: RDS policy must include a definition for every gTLD registration data element including both a semantic definition and (by reference to appropriate standards) a syntax definition.
* WG Agreement #27: At least one element identifying the domain name registrant (i.e., registered name holder) must be collected and included in the RDS.
* WG Agreement #28: Data enabling at least one way to contact the registrant must be collected and included in the RDS.
* (Revised) WG Agreement #29: At a minimum, one or more e-mail addresses must be collected for every domain name included in the RDS, for contact roles that require an e-mail address for contactability
* WG Agreement #31: At least one element enabling contact must be based on an open standard and not a proprietary communication method.
4) Confirm next meeting date: 8 August 16.00 UTC
Meeting Materials:
* KeyConceptsDeliberation-WorkingDraft-25July2017.pdf<https://community.icann.org/download/attachments/56986791/KeyConceptsDeliberation-WorkingDraft-25July2017.pdf?version=1&modificationDate=1501027940000&api=v2> and doc<https://community.icann.org/download/attachments/56986791/KeyConceptsDeliberation-WorkingDraft-25July2017.docx?version=1&modificationDate=1501027924000&api=v2>
* PBC-Overview-1August.pdf<https://community.icann.org/download/attachments/66086741/PBC-Overview-1August.pdf?version=1&modificationDate=1501602782000&api=v2>
* 25 July Call Poll
* Link to participate: Closed@ COB Saturday 29 July
* PDF of Poll Questions: Poll-from-25JulyCall.pdf<https://community.icann.org/download/attachments/66086734/Poll-from-25JulyCall.pdf?version=1&modificationDate=1501027105639&api=v2>
* SurveyMonkey Summary Poll Results: SummaryResults-Poll-from-25JulyCall.pdf<https://community.icann.org/download/attachments/66086741/SummaryResults-Poll-from-25JulyCall.pdf?version=1&modificationDate=1501445918000&api=v2>
* SurveyMonkey Raw Data Poll Results: RawDataResults-Poll-from-25JulyCall.zip<https://community.icann.org/download/attachments/66086741/RawDataResults-Poll-from-25JulyCall.zip?version=1&modificationDate=1501445931000&api=v2> and XLS<https://community.icann.org/download/attachments/66086741/RawDataResults-Poll-from-25JulyCall.xlsx?version=1&modificationDate=1501445942000&api=v2>
* Annotated Survey Results: AnnotatedResults-Poll-from-25JulyCall.pdf<https://community.icann.org/download/attachments/66086741/AnnotatedResults-Poll-from-25JulyCall.pdf?version=2&modificationDate=1501610982521&api=v2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170801/12240142/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list