[gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from Next-Generation gTLD RDS PDP Working Group Call - 2 May 2017

[Amr Elsadr]

Dear Working Group Members,

Below are the action items, notes and materials from today’s call. As per today’s discussion, please keep an eye out for an email regarding the poll on the suggested reworded charter sub-question 5.1. Also, please read the Working Group List Discussion Rules, also discussed during today’s call. I’ve attached a copy to this email.

Thanks.

Amr


ACTION ITEMS:


1.       Staff to number bullets and distribute list of rules with meeting notes and post on wiki for future reference. Completed: RDS PDP WG List Discussion Rules.pdf<https://community.icann.org/download/attachments/64078608/RDS%20PDP%20WG%20List%20Discussion%20Rules.pdf>

2.       Working Group members are expected to read and follow the RDS PDP WG List Discussion Rules

3.       Staff will send an email to the WG mailing list to ask WG members' feedback on a possible webinar or call to bring new WG members up to speed on Working Group issue background, issue report, and charter. This will be followed up by a doodle poll in the event that the webinar/call is found to be desirable

4.       Staff to set up a poll of the suggested rewording of sub-question 5.1

Notes RDS PDP WG Meeting – 2 May 2017:
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/EMPRAw


1.       Roll Call/SOI Updates:

·         Attendance will be taken from AC

·         Please remember to state your name before speaking and remember to mute your microphones when not speaking

·         SOI updates: none

2.       WG mailing list discussion rules

·         Leadership team considered recent email list exchanges and suggestions made

·         In addition to following GNSO Working Group Guidelines and ICANN Expected Standards of Behavior, the following rules are intended to help this WG deliberate effectively, both on-list and during WG calls:

o    Discussion topics must be narrowly defined - leadership team will strive to do this

o    Responses must be narrowly focused on defined topics - ok to note dependencies and assumptions but try to remain focused on narrow topic of discussion

o    Members should be as brief as possible - say what you have to say but try to be brief, the group is too large for everyone to participate if comments are verbose

o    Repetition of points already made should be minimized

o    Members must identify themselves in message text (for example, prefacing your inline response with initials) to help others follow dialog - trimming can also help

o    Deliberation must follow the terms of the WG charter - we have and will vary order as needed but we will follow charter

o    Unless otherwise decided, we'll start with discussion of relevant elements of the EWG Report. That report isn't policy - that's our WG's job. But we should not duplicate effort that's already been done in EWG Report. Everyone should read the EWG Report; this is essential

o    Proposed WG agreements (points of rough consensus) are to be determined by the WG as a whole - finalized during a WG call and using polls for confirmation. You don't have to win the argument on the mailing list - make your points and all inputs will be considered as WG makes rough and ultimately final decisions.

o    If you start a new topic (or fork into a different topic), start your email message fresh - give a new appropriate title, don't just reply to old thread. Where possible tag charter question in the Subject.

·         Questions/Suggestions:

o    When thread drifts into different topic, "fork" using a new subject/thread to help original thread stay on topic and follow new topics of discussion

o    Trimming quoted messages to only what is necessary would help as well

o    Some threads evolved into mean-spirited attack; need to avoid this by avoiding personal attacks and also being thick-skinned/not overly sensitive. Respectful communication is expected - see ICANN Expected Standards of Behavior: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en

·         Action Item: Staff to number bullets and distribute list of rules with meeting notes and post on wiki for future reference. Completed: RDS PDP WG List Discussion Rules.pdf<https://community.icann.org/download/attachments/64078608/RDS%20PDP%20WG%20List%20Discussion%20Rules.pdf>

·         Action Item: Working Group members are expected to read and follow the RDS PDP WG List Discussion Rules

·         Action Item: Staff will send an email to the WG mailing list to ask WG members' feedback on a possible webinar or call to bring new WG members up to speed on Working Group issue background, issue report, and charter. This will be followed up by a doodle poll in the event that the webinar/call is found to be desirable

3.       Continue deliberation on the charter question/subquestion 5.1:

·         Should gTLD registration "thin data" be entirely public or should access be controlled?

·         See https://community.icann.org/download/attachments/64078608/Charter%20Question%205%20-%20Handout%20-%20For2MayCall.pdf

·         Currently, discussion on gated access will focus on "thin" data elements (working definition of "thin" data is as it was defined in the "thick" WHOIS PDP WG Final Report<https://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf>)

·         Answer to 5.1 given by the EWG is summarized in the EWG Report on Page 58: “The EWG recommends that a new approach be taken for registration data access, abandoning entirely anonymous access by everyone to everything in favor of a new paradigm that combines public access to some data with gated access to other data.”

·         EWG recommended that unauthenticated access to public data would be limited to a minimum public data set which includes today’s "thin" data along with other data elements such as a registrant ID

·         EWG recommendation on access to gated data, which includes remaining "thick" data elements, is that access should be controlled via authentication/accreditation of person conducting query, and purpose-driven authorization (collectively referred to as “gated access” in the EWG Report)

·         Access to gated data would be based on accreditation and authentication of requestor conducting query. Gated data might include personal registrant information, made accessible based on purpose (that is, only authenticated requestors authorized for a given purpose would have access to gated data elements required for that purpose).

·         Requestor would need to comply with terms of service for RDS access and for each purpose

·         From AC Chat: Data elements to be accessible depend on authentication, purpose, and policy that defines what data is authorized for each purpose

·         Public access does not necessarily mean anonymous access - this needs to be determined by this PDP Working Group

·         Data elements in EWG split into two subsets: Minimum Public Data Set and Gated Data

·         Minimum Public Data Set is still accessible without stating a purpose and still accessible in a way similar to today's WHOIS (that is, without requestor identification or authentication)

·         Gated Data elements would be accessible based on conditions set by policy, which in turn would be set based on each policy-defined permissible purpose. In the EWG’s model, there is not one “gate” – there are many gates, each gate reflecting a subset of data needed by a given purpose.

·         Access to Gated Data would require identification, authentication, and authorization, and subject to applicable law

·         In order to authenticate themselves, requestors must be accredited for one or more purposes, in advance of completing first RDS query. Accreditation could mean several things, and may vary by purpose, and may be carried out by different portions of the community - EWG recommended further work/elaboration on this. For example:

o    Self-accreditation for purposes authorized to access to low-risk data

o    Third-party accreditation for purposes with access to higher-risk data

o    Anti-abuse measures (such as rate-limiting) would apply to every level of access to data

·         EWG recommended rules engine be developed that takes into consideration applicable laws for each RDS query, based on jurisdiction(s) involved in a given transaction. That is, just because a gated data element is defined by policy as accessible for a given purpose, whether or not it can be retrieved by an authenticated and authorized requestor for that purpose is still limited by applicable law

·         The EWG defined access criteria for data elements that reflect (among other things) level of risk. Risk level was determined for different data elements being accessed, with those considered lower risk being public while those considered higher risk (e.g., PII for most contacts) being gated

·         Page/Slide 6 of Charter Question 5 Handout has a flowchart illustrating the process for applicable access control to data as per the EWG final report and recommendations - purposes in the bottom row of this slide are the ones identified by the EWG as permissible, but may be expanded/refined by this PDP WG. This WG determines the policy as to which purposes are legitimate and which gTLD registration data elements are accessible for each purpose


Working Group to now deliberate on the question "Should gTLD registration "thin data" be entirely public or should access be controlled"?



·         Suggestions welcome on how to modify the question (example: all "thin data" is fit for all purposes of access) - should this also imply that public access does not require any authentication/authorization (i.e. is anonymous)?

·         Public to some implies no access controls - requiring knowing who someone is (authentication) is a form of access control

·         Since "thin" data does not include any personal identifiable information, why is anonymous access to this data, and association with purpose an issue?

·         Suggestion: Change "entirely public" with "without authentication" in sub-question 5.1 to decrease ambiguity on question of public access being anonymous - possible to also remove "or" --> Should access to gTLD registration "thin data" be controlled in any way?

·         Distinction/clarification in question between public access and non-anonymous public access is necessary to clarify the question - non-anonymous public access still implies a level of gating of access to the data (subject to a requirement of identification)

·         From AC Chat: There are multiple concepts embodied in that recommendation: splitting data elements into the min public data set and gated data, and the access controls applied to each of those subsets of data

·         If there is a technical reason to limit access (such as limiting access to volume of data), this is unrelated to a requirement of identification and purpose of requesting the data

·         There is a difference between personally identifiable information and personal information - some personal information exists in "thin data" (example: Expiration Date)

·         Another suggestion for rewording the question: Should access to gTLD registration "thin data" be completely unauthenticated? - Does unauthenticated mean that identity is not verified despite a requirement to provide unverified identification?

·         If information is available/accessible without any conditions or restrictions, this should be stated clearly - avoid using adjectives to describe this

·         Suggested rewording of question: Should access to gTLD "thin data" be permissible without regard to the identity of the enquirer or the purpose of the enquiry?

·         From AC Chat: friendly amendment then: "except as necessary for normal Internet service operation" to permit rate limiting and so on

·         "without regard to the identity = without a requirement for the requestor to identify him/herself"

·         New suggested rewording: gTLD registration "thin data" should be accessible without requiring enquirers to identify themselves or state their purpose

·         ACTION ITEM: Staff to set up a poll of the suggested rewording of sub-question 5.1

4.       Brief updates on in-progress tasks

·         ccTLD questions

o    Small team will take into account feedback provided by WG members on list, and welcomes more input before Friday, 5 May - Small team will proceed to reach out to ccTLD registries

·         Definition of authoritative

o    Active and interesting discussion taking place on the Working Group mailing list right now

o    Small team needs to facilitate closure of this topic, hopefully by the end of this week

5.       Confirm action items and proposed decision points

·         ACTION ITEM 1: Staff to number bullets and distribute list of rules with meeting notes and post on wiki for future reference. Completed: RDS PDP WG List Discussion Rules.pdf<https://community.icann.org/download/attachments/64078608/RDS%20PDP%20WG%20List%20Discussion%20Rules.pdf>

·         ACTION ITEM 2: Working Group members are expected to read and follow the RDS PDP WG List Discussion Rules

·         ACTION ITEM 3: Staff will send an email to the WG mailing list to ask WG members' feedback on a possible webinar or call to bring new WG members up to speed on Working Group issue background, issue report, and charter. This will be followed up by a doodle poll in the event that the webinar/call is found to be desirable

·         ACTION ITEM 4: Staff to set up a poll of the suggested rewording of sub-question 5.1

·         WG AGREEMENT 1 (to be confirmed by polling): gTLD registration "thin data" should be accessible without requiring enquirers to identify themselves or state their purpose

6.       Confirm next meeting date: 9 May 2017 at 16:00 UTC

·         Next week's call coincides with closure of GDD summit - keep call as scheduled

Meeting Materials (all posted at https://community.icann.org/x/EMPRAw):


·         RDS PDP WG List Discussion Rules.pdf<https://community.icann.org/download/attachments/64078608/RDS%20PDP%20WG%20List%20Discussion%20Rules.pdf?version=1&modificationDate=1493747136000&api=v2>

·         Charter Question 5 - Handout - For2MayCall.pdf<https://community.icann.org/download/attachments/64078608/Charter%20Question%205%20-%20Handout%20-%20For2MayCall.pdf?version=1&modificationDate=1493658666000&api=v2>

·         NewSection5-Intro-KeyConcepts-21April2017.pdf<https://community.icann.org/download/attachments/64078605/NewSection5-Intro-KeyConcepts-21April2017.pdf?version=1&modificationDate=1492802791000&api=v2> - excerpted from
KeyConceptsDeliberation-WorkingDraft-21April2017.pdf<https://community.icann.org/download/attachments/56986791/KeyConceptsDeliberation-WorkingDraft-21April2017.pdf?version=1&modificationDate=1492966757152&api=v2> and doc<https://community.icann.org/download/attachments/56986791/KeyConceptsDeliberation-WorkingDraft-21April2017.docx?version=1&modificationDate=1492966735704&api=v2>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170502/79cec49a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RDS PDP WG List Discussion Rules.pdf
Type: application/pdf
Size: 237227 bytes
Desc: RDS PDP WG List Discussion Rules.pdf
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170502/79cec49a/RDSPDPWGListDiscussionRules-0001.pdf>