Versions Compared

Old Version 18

changes.mady.by.user Lisa Phifer

Saved on

compared with

New Version 19

changes.mady.by.user Michelle Desmyter

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Apologies: Holly Raiche, Marc Anderson Anderson, Farell Folly
Transcript


Notes RDS PDP WG Meeting 

Notes:

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

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

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

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):

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 can remain in AC room when WG meeting ends


Meeting Materials