[gnso-rds-pdp-wg] IMPORTANT: Notes from RDS PDP WG Meeting - 23 May

Wed May 24 00:38:46 UTC 2017

Hi there Farell,
I will note your apology from this meeting, thank you so much!

Kind regards,
Michelle DeSmyter

From: <gnso-rds-pdp-wg-bounces at icann.org<mailto:gnso-rds-pdp-wg-bounces at icann.org>> on behalf of Farell Folly <farellfolly at gmail.com<mailto:farellfolly at gmail.com>>
Date: Tuesday, May 23, 2017 at 6:58 PM
To: Lisa Phifer <lisa at corecom.com<mailto:lisa at corecom.com>>
Cc: RDS PDP WG <gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>>
Subject: Re: [gnso-rds-pdp-wg] IMPORTANT: Notes from RDS PDP WG Meeting - 23 May

Thanks Lisa for this update.

Dear all, apologies for being absent at the meeting. A delayed flight did not allow me to arrive on time in a connected area.

Regards
@__f_f__

PhD Candidate, Universität der Bundeswehr München
Computer Security | Internet of Things
https://www.linkedin.com/in/farellf
________________________________.
Mail sent from my mobile phone. Excuse for brievety.

Le 23 mai 2017 9:12 PM, "Lisa Phifer" <lisa at corecom.com<mailto:lisa at corecom.com>> a écrit :

Dear all,

Below please find notes from today’s RDS PDP WG meeting.

To recap action items from today’s call:

·        Action Item: Staff to add above WG Agreement to Working Draft

·        Action Item: Staff to develop poll to test one or more proposed alternatives for DoR definition. All WG members to participate in poll by COB Saturday 27 May.

·        Action Item: Rod Rasmussen and Vaibhav Aggarwal to complete action assigned during 17 May call and be prepared to discuss this at next WG call.

·        Action Item: Leadership team to develop question(s) for this week’s poll to further advance this discussion, including a rewording of EWG principle 41.

Best regards,
Lisa

Notes RDS PDP WG Meeting – 23 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/HsPRAw
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) Review poll results to finalize those WG agreements: AnnotatedResults-Poll-from-17MayCall.pdf<https://community.icann.org/download/attachments/64078622/AnnotatedResults-Poll-from-17MayCall.pdf>
Q2 - Rough consensus on WG Agreement: “gTLD registration "thin data" should be accessible without requestor identification, authentication, or stated purpose.”

·        85% supported this statement

·        Two comments from those who disagreed pertained to specification of purpose - see discussion on subquestion 5.4 below
Action Item: Staff to add above WG Agreement to Working Draft
Q3 - 80% support for reworded purpose and definition of Data of Record, with 5 comments from those who disagreed

·        Footnoted definition: "The data set at a given time relevant to a given registration object that expresses the data provided in the then-current registration for that object."

·        Concern expressed: DoR doesn't have the concept of authoritative source - if there are several places you can go to get data, this is the one you rely on as a trusted source

·        In a thin registry today, there are multiple places to get the data - some generated by registry, some supplied by registrar. We shouldn't build this architecture into RDS requirements - definition refers instead to "then-current registration for object" independent of location of storage, as it is not a statement about where data is stored or legal authority. Those are important things to consider but should be separated from the concept embodied by this definition.

·        Another concern: Couldn't there be more than one such data set meeting this definition?  E.g., the data held by registry may be different than data held by registrar? (and still be current)

·        This is the information we take to be correct data (not accurate, but correct when resolving differences between multiple/cached copies of data, or protecting against MitM insertion, etc.).

·        For example, DNSSEC provides integrity protection for DNS records (detects unintended or unauthorized modification, etc., but does not prove that DNS records are accurate). We way something here to provide something similar for registration data, to prove it is official.

·        Ultimately, Whois cannot be relied upon legally as it may be out of date, false, stolen, proxied, etc.

·        Proposed alternative: "information provided during the last update/create interaction"

·        Data provide by who? If the data exists at both registrar and registry, which is the DoR? Need to disambiguate which data is meant.

·        Another proposed alternative: "The data you would get for each datum if you were to ask the source of that datum"

·        Does the concept of "provenance" capture the concept intended?

·        Possible alternative terms: "definitive data" or data "considered as authoritative"

·        Could we live with "data of record" now and refine the definition during policy development, and then re-addressed during implementation of that policy?

·        See Greg Aaron's comments, further expanded on list: http://mm.icann.org/pipermail/gnso-rds-pdp-wg/2017-May/003189.html, including what objects are being referred to by this definition

·        We are trying to express the concept of integrity of data, as data moves from origin through system as a whole

·        Possible alternative: Data set that, at a given time, is asserted to match the data acquired at its point of origin

·        Possible WG Agreement (to be polled on): DoR = Data set that, at a given time, can be proven to match the data supplied at the origin for each data element
Action Item: Staff to develop poll to test one or more proposed alternatives for DoR definition. All WG members to participate in poll by COB Saturday 27 May.
3)  Complete deliberation on the charter question: What steps should be taken to control "thin data" access?
See RDSPDP-Handout-For23MayCall.pdf<https://community.icann.org/download/attachments/64078622/RDSPDP-Handout-For23MayCall.pdf>
a. Update from Rod Rasmussen and Vaibhav Aggarwal on what "unreasonably restrict legitimate access" means in the following WG Agreement:

·        There must be no RDS policies that prevent RDS operators from applying operational controls such as rate limiting and CAPTCHA, provided that they do not unreasonably restrict legitimate access."

·        Update not yet drafted.
Action Item: Rod Rasmussen and Vaibhav Aggarwal to complete action assigned during 17 May call and be prepared to discuss this at next WG call.
b. Review all of charter question 5 subquestions with goal to complete first pass deliberation on "thin data" access in May
·        Refer to slides 2-4 of RDSPDP-Handout-For23MayCall.pdf<https://community.icann.org/download/attachments/64078622/RDSPDP-Handout-For23MayCall.pdf>
Slide 3: Charter Subquestions 5.1 through 5.4

·        Leadership team has provided possible answers to the subquestions - answers based on rough consensus WG Agreements already reached via WG calls and poll results

·        Have all of these subquestions been sufficiently addressed by WG agreements for "thin data" access? If not, which subquestions need further deliberation?

·        Subquestion 5.2: Are queries consisting of a single look-up to be treated the same as bulk look-ups?

·        "Levels of access" is not meant to refer to access to a large or small quantity of records. It refers to tiered or differentiated access, as opposed to simply public access

·        Subquestion 5.4 requires further deliberation during next call
Slide 4: For Charter Subquestion 5.5

·        Subset of EWG principles on access were selected to assist in answering this question - other EWG principles on access are thought to be more relevant to questions to be addressed later

·        Principles highlighted in yellow may apply to "thin data" –  41, 44, and 45 first bullet only
Regarding principle 45 bullet one, concerns expressed about “stated purpose”

·        LEAs may be reluctant to state a purpose so as not to tip off someone to an active investigation

·        "Stated purpose" in first bullet of principle 45 is not meant to refer to the purpose of the requestor - as not to conflict with poll question/tentative WG agreement - the policy will be required to state a purpose for public access to "thin data"
Regarding principle 41, concerns expressed about phrase “most stringent privacy regime”

·        recommendations should be compliant with applicable laws

·        Proposed rewording of first bullet of principle 45: All data elements must be based on a purpose stated in policy

·        Should "most stringent privacy regime" be dropped  or replaced by "most stringent applicable privacy regime"

·        Issue of compliance with applicable privacy regimes should be addressed in its own principle, not mixed in with principles addressing other issues

·        Compliance with applicable stringent privacy regimes could be via exceptions to the policy instead of it being the norm

·        For context: The EWG added "most stringent privacy regime" to principle 41 to avoid conflict between this principle and privacy principles on compliance with applicable laws which recommended a rules engine to hide data elements that cannot be lawfully displayed in a given jurisdiction

·        Also let’s not assume the future RDS will be full of personal domain name registrations and personal contact data. It will contain commercial domain name registrations also with contact data that are not subject to data protection laws defined by "stringent privacy regimes"

·        When commercial registrations are made, some contacts (such as tech contact) may still constitute personal data

·        Are there privacy regimes stringent to the extent that they would prohibit public access to "thin data" or a minimum set of data elements?

·        A scenario of an extreme privacy/data protection regime that would prohibit publication of a minimal set of data elements required in order for a domain name to resolve (such as "thin data") could prevent the domain name from actually working?

·        When considering privacy regimes, the regime needs to be considered in its entirety, including not only constraints on publication, but also exceptions that may be applicable
Action Item: Leadership team to develop question(s) for this week’s poll to further advance this discussion, including a rewording of EWG principle 41
4) Resume deliberation on the charter questions on Purpose and Data Elements for "thin data" only (time permitting):

·        See https://community.icann.org/download/attachments/64078512/Merged-ThinDataPurposes-v1.pdf

·        Deferred to 30 May Call: Examine purposes for each "thin data" element
5) Confirm action items and proposed decision points

·        WG Agreement: “gTLD registration "thin data" should be accessible without requestor identification, authentication, or stated purpose.”

·        Action Item: Staff to add above WG Agreement to Working Draft

·        Action Item: Staff to develop poll to test one or more proposed alternatives for DoR definition. All WG members to participate in poll by COB Saturday 27 May.

·        Action Item: Rod Rasmussen and Vaibhav Aggarwal to complete action assigned during 17 May call and be prepared to discuss this at next WG call.

·        Action Item: Leadership team to develop question(s) for this week’s poll to further advance this discussion, including a rewording of EWG principle 41.
 6) Confirm next meeting date: 30 May 2017 at 16:00 UTC
Note: Those attending newcomer tutorial<https://community.icann.org/x/jBXfAw> can remain in AC room when WG meeting ends

Meeting Materials (all posted at https://community.icann.org/x/HsPRAw)
·        RDSPDP-Handout-For23MayCall.pdf<https://community.icann.org/download/attachments/64078622/RDSPDP-Handout-For23MayCall.pdf?version=1&modificationDate=1495547541000&api=v2>
·        https://community.icann.org/download/attachments/64078512/Merged-ThinDataPurposes-v1.pdf
·        KeyConceptsDeliberation-WorkingDraft-9May2017.pdf<https://community.icann.org/download/attachments/56986791/KeyConceptsDeliberation-WorkingDraft-9May2017.pdf?version=1&modificationDate=1494372838376&api=v2> and doc<https://community.icann.org/download/attachments/56986791/KeyConceptsDeliberation-WorkingDraft-9May2017.docx?version=1&modificationDate=1494372853897&api=v2>
·        17 May Call Poll Results -
o   PDF of Poll Questions: Poll-from-17MayCall.pdf<https://community.icann.org/download/attachments/64078620/Poll-from-17MayCall.pdf?version=1&modificationDate=1495026529000&api=v2>
o   Annotated Poll Results: AnnotatedResults-Poll-from-17MayCall.pdf<https://community.icann.org/download/attachments/64078622/AnnotatedResults-Poll-from-17MayCall.pdf?version=1&modificationDate=1495473776000&api=v2> (for display during call)
o   SurveyMonkey Summary Poll Results: SummaryResults-Poll-from-17MayCall.pdf<https://community.icann.org/download/attachments/64078622/SummaryResults-Poll-from-17MayCall.pdf?version=1&modificationDate=1495382647000&api=v2>
o   SurveyMonkey Raw Data Poll Results: RawDataResults-Poll-from-17MayCall.zip<https://community.icann.org/download/attachments/64078622/RawDataResults-Poll-from-17MayCall.zip?version=1&modificationDate=1495382667000&api=v2> and XLS<https://community.icann.org/download/attachments/64078622/RawDataResults-Poll-from-17MayCall.xls?version=1&modificationDate=1495382724000&api=v2>

_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170524/7e196c8c/attachment-0001.html>