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

Lisa Phifer lisa at corecom.com
Tue May 23 21:11:32 UTC 2017


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>
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:
<https://community.icann.org/download/attachments/64078622/AnnotatedResults-
Poll-from-17MayCall.pdf> 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>
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
<https://community.icann.org/download/attachments/64078622/RDSPDP-Handout-Fo
r23MayCall.pdf> 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
<https://community.icann.org/download/attachments/64078622/RDSPDP-Handout-Fo
r23MayCall.pdf> 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-ThinDataPu
rposes-v1.pdf>
https://community.icann.org/download/attachments/64078512/Merged-ThinDataPur
poses-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  <https://community.icann.org/x/jBXfAw> newcomer
tutorial can remain in AC room when WG meeting ends

Meeting Materials (all posted at  <https://community.icann.org/x/HsPRAw>
https://community.icann.org/x/HsPRAw)

.
<https://community.icann.org/download/attachments/64078622/RDSPDP-Handout-Fo
r23MayCall.pdf?version=1&modificationDate=1495547541000&api=v2>
RDSPDP-Handout-For23MayCall.pdf

.
<https://community.icann.org/download/attachments/64078512/Merged-ThinDataPu
rposes-v1.pdf>
https://community.icann.org/download/attachments/64078512/Merged-ThinDataPur
poses-v1.pdf

.
<https://community.icann.org/download/attachments/56986791/KeyConceptsDelibe
ration-WorkingDraft-9May2017.pdf?version=1&modificationDate=1494372838376&ap
i=v2> KeyConceptsDeliberation-WorkingDraft-9May2017.pdf and
<https://community.icann.org/download/attachments/56986791/KeyConceptsDelibe
ration-WorkingDraft-9May2017.docx?version=1&modificationDate=1494372853897&a
pi=v2> doc

.        17 May Call Poll Results -

o   PDF of Poll Questions:
<https://community.icann.org/download/attachments/64078620/Poll-from-17MayCa
ll.pdf?version=1&modificationDate=1495026529000&api=v2>
Poll-from-17MayCall.pdf

o   Annotated Poll Results:
<https://community.icann.org/download/attachments/64078622/AnnotatedResults-
Poll-from-17MayCall.pdf?version=1&modificationDate=1495473776000&api=v2>
AnnotatedResults-Poll-from-17MayCall.pdf (for display during call)

o   SurveyMonkey Summary Poll Results:
<https://community.icann.org/download/attachments/64078622/SummaryResults-Po
ll-from-17MayCall.pdf?version=1&modificationDate=1495382647000&api=v2>
SummaryResults-Poll-from-17MayCall.pdf

o   SurveyMonkey Raw Data Poll Results:
<https://community.icann.org/download/attachments/64078622/RawDataResults-Po
ll-from-17MayCall.zip?version=1&modificationDate=1495382667000&api=v2>
RawDataResults-Poll-from-17MayCall.zip and
<https://community.icann.org/download/attachments/64078622/RawDataResults-Po
ll-from-17MayCall.xls?version=1&modificationDate=1495382724000&api=v2> XLS

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170523/92ae5fd4/attachment-0001.html>


More information about the gnso-rds-pdp-wg mailing list