[gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from GNSO Next-Generation RDS PDP WG Call - 25 July 2017
Amr Elsadr
amr.elsadr at icann.org
Tue Jul 25 19:57:21 UTC 2017
Dear Working Group Members,
Please find the action items and notes from today’s WG call below. These are also posted on the WG wiki page, along with the call documents/materials here: https://community.icann.org/x/TmfwAw. Attendance, recordings and transcripts will be posted on the same page, when they are available.
Thanks.
Amr
Action Items:
1. WG members may suggest alternative wording for above key concepts by 18.00 UTC on-list for inclusion in this week's poll. Staff to include those permutations in this week's poll testing vi) and vi).
2. Staff to record WG agreement on Registrant Country in working draft.
3. Staff to produce poll to test agreement on proposed key concepts for Registrant Name/Org and Email Address, including proposed WG agreements enumerated above and any further options suggested through WG action .
4. For admin, technical, abuse, and privacy/proxy roles, all WG members encouraged to discuss on-list this week the questions at the top of slide 6: Are these roles needed? How do they differ from each other? How might they differ from the registrant's contact data?
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) Introductions and SOI Updates
* Attendance taken from AC
* SOI updates: None
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 poll results from 18 July and 28 June and call handout (below)
c) Develop key concepts related to Registrant Name/Org, Registrant Country, Registrant Email Address
Question 2: Registrant Name/Organization
* Options (a) and (d) received the most support; was possible to select more than one choice
* Need for a semantic definition for these data elements was identified in several comments
* Regardless of whether choice (a) or (d) was selected, need to agree on a key concept regarding identification of a registrant - can agree on the label of the data field later
* Poll analysis suggested two proposed key concepts shown on slide 2 of handout:
i) RDS policy must include a definition for every gTLD registration data element including both a semantic definition and a syntax definition
* Possible additional key concept might be to allow for registries to add data elements not required by policy
* What would happen if policy defining syntax conflicted with IETF protocol? Presumably that would be a consideration in developing policy for syntax, to avoid ICANN being in the position of defining protocols
* Should this (requirement on syntax being consistent with standards or based on standards) be included in the key concept or a separate key concept?
* Currently the RAA data element definitions refer to IETF RFCs and ISO standards as the source of syntax definitions
* Reference existing standards. DO NOT produce new syntax requirements.
* On the "syntax" issue, as a matter of policy, we could/should be looking at stating what standards should be used, for example for phone numbers or e-mail addresses. These exist and should be used for universal ability to make various contacts happen
* Alternative key concept supported by many on the call: 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
* Test the above revised proposed key concept as possible WG agreement, supported by those on today's call
Proposed WG Agreement (to be tested by poll):
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
ii) At least one element identifying the domain name registrant (i.e., registered name holder) must be collected and included in the RDS.
* Is ROID enough to identify registrant?
* Test the above proposed key concept as possible WG agreement, supported by those on today's call
Proposed WG Agreement (to be tested by poll):
At least one element identifying the domain name registrant (i.e., registered name holder) must be collected and included in the RDS.
Question 3: Registrant Country
* Strong support (79%) for option a)
* Accept option a) as a point of rough consensus
WG Agreement (to be recorded in working document):
Registrant Country must be included in RDS data elements; it must be mandatory to collect for every domain name registration.
Question 4: Registrant Email Address
* Options with greatest support were a) and c)
* Email list discussion on ability to provide a preferred contact, and to map contacts to roles
* There are policies that exist today that require email addresses to work -- whether that's the Registrant's email address or another contact's email address
* Think about this from a purely practical standpoint: Option a) indicates there may be different ways to contact the Registrant electronically, but email address is the one thing that is required right now -- if we go with a) there's a possibility that Registrants become harder to contact and they might prefer an obscure means of contact - we need a baseline that enables contact.
* Communication standards change, so limiting us to a potentially outdated means could spell problems for the future (e.g., fax is already arguably out-dated)
* Separate requiring an email address for contact -from- requiring the registrant's email address.
* As long as there is an ability to contact someone when you have a purpose to do so, we have met our goals.
* Poll analysis suggested two proposed key concepts shown on slide 4 of handout:
iv) Data enabling at least one way to contact the registrant must be collected and included in the RDS.
v) At minimum, the registrant’s email address must be collected and included in the RDS.
vi) Data enabling one alternative or preferred method of contact may also be optionally collected and included in the RDS.
* For iv) show of hands shows support, no opposition, will be tested as proposed WG agreement in poll
Proposed WG Agreement (to be tested by poll):
Data enabling at least one way to contact the registrant must be collected and included in the RDS.
* For v) not convinced - email address may be the most practical today but must the registrant's email be collected in all cases?
* If the RDS policy does not require email address, does it fail to support other ICANN policies that do? Does it require a change to other policies?
Proposed WG Agreement (to be tested by poll):
At minimum, the registrant’s email address must be collected and included in the RDS.
* For vi), is there a requirement that there be a primary method plus an alternative method (both mandatory to collect)?
* What problem is being solved by alternative method(s)?
* Alternative preferences, overcoming failure in primary method, etc.
* Green check if agree with requiring one alternative to email as a contact - many green checks, two red X's
Proposed WG Agreement (to be tested by poll):
In addition to email address, data enabling one alternative method of contact must be collected and included in the RDS.
* The kind of contact must somehow be part of that public, non-proprietary infrastructure
* Historically all of the contact methods in WHOIS are based on a public standard, to avoid potential of tying contact to proprietary contact infrastructures.
Proposed WG Agreement (to be tested by poll):
At least one element enabling contact must be based on an open standard and not a proprietary communication method.
* The purpose of the contact is partly to be able to solve problems related to operation of a domain. The registrant is ultimately responsible for that operation, and therefore the buck has to stop there, and therefore we need to be able to reach a registrant.
* Recall address book analogy from last week's call with many/variable data enabling contact for each
Action Item: WG members may suggest alternative wording for above key concepts by 18.00 UTC on-list for inclusion in this week's poll. Staff to include those permutations in this week's poll testing vi) and vi).
Action Item: Staff to record WG agreement on Registrant Country in working draft.
Action Item: Staff to produce poll to test agreement on proposed key concepts for Registrant Name/Org and Email Address, including proposed WG agreements enumerated above and any further options suggested through WG action item above.
d) Deliberate on other "contact" data elements that were broadly supported:
Admin, Tech, Abuse, Privacy/Proxy
* Refer to slide 6 in today's call handout for excerpt from EWG Report on above contact types (roles)
* Is Admin Contact needed? Perhaps replace this with roles that apply to each contact collected for a given domain name
* Roles stuff in EWG report - totally consistent with the EPP data model
* Frustration with existing model is that you must re-enter data multiple times, at least once for each contact and domain name
* May be result of user interface: .info allows for contact to be entered once and reused by other domains in the same registry
* EWG proposal also allowed for registrants to provide just one contact for all roles or separate contacts for different roles, at registrant's discretion
* Noted that businesses may wish to control contacts used as technical contact for all domain names
* EWG multiplied the number of contact types; maybe consider the roles without considering them as new contacts
* Support for this suggestion: Let's look at the full range of reasons for contact and potential "roles" to the extent EWG did so.
* Reuse: Cross registry issue is HUGE and we should be addressing it. As a contact, I want ONE AND ONLY ONE thing to update across all my domains regardless of TLDs - I don't care at all about TLD's, I care about making my life easy to administer all my domains. We should put a checkmark by this to discuss.
Action Item: For admin, technical, abuse, and privacy/proxy roles, all WG members encouraged to discuss on-list this week the questions at the top of slide 6: Are these roles needed? How do they differ from each other? How might they differ from the registrant's contact data?
e) Deliberate on deletion of data elements that are largely unwanted (deferred)
3) Confirm action items and proposed decision points
WG Agreement (to be recorded in working document):
* Registrant Country must be included in RDS data elements; it must be mandatory to collect for every domain name registration.
Proposed WG Agreements (to be tested by poll):
* 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.
* At least one element identifying the domain name registrant (i.e., registered name holder) must be collected and included in the RDS.
* Data enabling at least one way to contact the registrant must be collected and included in the RDS.
* At minimum, the registrant’s email address must be collected and included in the RDS.
* In addition to email address, data enabling one alternative method of contact must be collected and included in the RDS.
* At least one element enabling contact must be based on an open standard and not a proprietary communication method.
Action Items:
* WG members may suggest alternative wording for above key concepts by 18.00 UTC on-list for inclusion in this week's poll. Staff to include those permutations in this week's poll testing vi) and vi).
* Staff to record WG agreement on Registrant Country in working draft.
* Staff to produce poll to test agreement on proposed key concepts for Registrant Name/Org and Email Address, including proposed WG agreements enumerated above and any further options suggested through WG action .
* For admin, technical, abuse, and privacy/proxy roles, all WG members encouraged to discuss on-list this week the questions at the top of slide 6: Are these roles needed? How do they differ from each other? How might they differ from the registrant's contact data?
4) Confirm next meeting date: 1 August 16.00 UTC
Meeting Documents/Materials:
* Slides for display during call: RDSPDP-Handout-For25JulyCall.pdf<https://community.icann.org/download/attachments/66086734/RDSPDP-Handout-For25JulyCall.pdf?version=1&modificationDate=1500954665000&api=v2>
* 28 June Call Analysis of Survey Results: AnalysisResults-Poll-from-28JuneCall.pdf<https://community.icann.org/download/attachments/66086729/AnalysisResults-Poll-from-28JuneCall.pdf?version=1&modificationDate=1500320760000&api=v2>
* 18 July Call Poll (closed at COB 23 July)
* PDF of Poll Questions: Poll-from-18JulyCall.pdf<https://community.icann.org/download/attachments/66086729/Poll-from-18JulyCall.pdf?version=3&modificationDate=1500601940202&api=v2>
* SurveyMonkey Summary Poll Results: SummaryResults-Poll-from-18JulyCall.pdf<https://community.icann.org/download/attachments/66086734/SummaryResults-Poll-from-18JulyCall.pdf?version=1&modificationDate=1500861593000&api=v2>
* SurveyMonkey Raw Data Poll Results: RawDataResults-Poll-from-18JulyCall.zip<https://community.icann.org/download/attachments/66086734/RawDataResults-Poll-from-18JulyCall.zip?version=1&modificationDate=1500861605000&api=v2> and XLS<https://community.icann.org/download/attachments/66086734/RawDataResults-Poll-from-18JulyCall.xlsx?version=1&modificationDate=1500861616000&api=v2>
* Annotated Survey Results: AnnotatedResults-Poll-from-18JulyCall.pdf<https://community.icann.org/download/attachments/66086734/AnnotatedResults-Poll-from-18JulyCall.pdf?version=1&modificationDate=1500861640000&api=v2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170725/ebf422fb/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list