[gnso-rds-pdp-wg] IMPORTANT: Notes from RDS PDP WG Meeting - 23 May
Farell Folly
farellfolly at gmail.com
Tue May 23 23:58:55 UTC 2017
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> 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 <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
> <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
> <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
> 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/20170523/e114d411/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list