[gnso-rds-pdp-wg] IMPORTANT: Notes from RDS PDP WG Meeting - 6 June
Lisa Phifer
lisa at corecom.com
Wed Jun 7 03:42:51 UTC 2017
Dear all,
Below please find notes from today's RDS PDP WG meeting.
To recap Action Items from today's call:
. Staff to add above-noted WG agreements to working document.
. Rod Rasmussen and Vaibhav Aggarwal to complete action assigned
during 17 May call and distribute in advance of next WG call.
. Staff to develop poll to test above-noted proposed WG agreements.
All WG members to participate in poll no later than COB Saturday 10 June.
. All WG members to plan to attend ICANN59 Cross Community and F2F WG
sessions (see links above), either in-person or via remote participation.
. All WG members encouraged to share the
<https://community.icann.org/download/attachments/59644409/Next%20Generation
%20RDS%20PDP%20-%20Newsletter%20-%20April-May%202017.pdf?version=1&modificat
ionDate=1496694757000&api=v2> GNSO Next-Generation RDS PDP WG April/May 2017
newsletter with their own SG/Cs and SO/ACs in preparation for the
cross-community discussion at ICANN 59 in Johannesburg.
Best regards,
Lisa
Notes RDS PDP WG Meeting - 6 June 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/IsPRAw>
https://community.icann.org/x/IsPRAw
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) Complete deliberation on the charter question: What steps should be taken
to control "thin data" access?
a) Review poll results
. Annotated Results:
<https://community.icann.org/download/attachments/64078626/AnnotatedResults-
Poll-from-30MayCall-v2.pdf?version=1&modificationDate=1496683026000&api=v2>
AnnotatedResults-Poll-from-30MayCall-v2.pdf
. Q2: Rough consensus support at 91%
WG Agreement: At least a defined set of "thin data" elements must be
accessible by unauthenticated RDS users.
Q3: Majority support at 75%
. Comments from 4 participants who disagreed with this agreement from
last week's call
. Concern expressed that thin data should be freely available without
stating a purpose, as stating purpose has implications
. We can enumerate broad reasons that thin data should be made
available rather than narrowly defined purposes
. Need to avoid defining purpose for collection in such a way that is
limiting purpose for access - purpose for which data might be disseminated
later must be disclosed at time of collection and gaining consent
. The data elements must be provided for certain purposes - for
example, a simple purpose for thin data may be anti-abuse
. Not stating that the registrant had to state the purpose for which
their data could be accessed. Rather expressing concern that the
registrant's knowledge of the purpose for collection and/or access may limit
the purpose for which the data will be accessed down the road.
. Accepting this WG agreement as rough consensus for now, subject to
refinement during continuing deliberation
WG Agreement: RDS policy must state purpose(s) for public access to "thin
data."
Q4: Support at 61% but unclear how many disagreed with non-discriminatory
concept
. Several comments expressed concern about the phrase "legitimate
purposes"
. Proposed alternative from leadership team: RDS policies for access
to "thin data" must be non-discriminatory (i.e., RDS policies must not be
designed to give anyone preferential access).
. Comment #4 - Does this add much given previous agreements? What
else could you do to discriminate, given that access is unauthenticated?
. In last week's poll, 10 participants responded this agreement
didn't apply to thin data, while a similar number supported an agreement
that evolved into this text.
. Note that operational controls (such as anti-DoS throttling) are
addressed by a separate WG agreement - see agenda item 2(c), which is
pending inputs before a proposal can be provided to the WG mailing list
. Should "non discriminatory" be "non-preferential"?
. Note this applies to RDS policies and not user interface design or
operational controls
. Conclusion: Put the proposed agreement on hold, pending resolution
of action item 2(c)
Action Item: Staff to add above-noted WG agreements to working document.
b) Consider possible principle on proportionality
. See
<https://community.icann.org/download/attachments/64078626/RDSPDP-Handout-Fo
r6JuneCall.pdf?version=2&modificationDate=1496710904000&api=v2>
RDSPDP-Handout-For6JuneCall.pdf slide 2
. Consider tests of proportionality for public access to "thin data"
. Could this four-part test be applied to "thin data" access, for
example:
. Is there at least one legitimate purpose for providing public
access* to "thin data"?
. Is public access to "thin data" suitable to achieve those
legitimate purpose(s)?
. Is public access to "thin data" necessary to achieve those
legitimate purpose(s), that there cannot be any less onerous way of doing
it?
. Is public access to "thin data" reasonable, considering the
competing interests of different groups at hand?
. Could the WG consider that principles agreed to so far on "thin
data" meet the proportionality requirements (or will meet the requirements)?
. The proportionality principle is relevant to PII, so does it need
to be applicable to access to "thin data"?
. Can the 4 tests on the principle of proportionality apply to access
to "thin data" without acknowledging that the principle itself is applicable
to "thin data" access?
. Proportionality principle should be broadly applicable - "thin
data" that MUST be publicly accessible against the 4 tests should be
examined
. Some argue that thin data elements could be treated in some cases
as personal data because it can be linked to an individual, and so passing
the proportionality test allows making this data public even in those cases
. Conclusion: Put this possible principle aside for now, pending
further deliberation
c) Action item proposal from Rod Rasmussen and Vaibhav Aggarwal
. Deferred to next call
Action Item: Rod Rasmussen and Vaibhav Aggarwal to complete action assigned
during 17 May call and distribute in advance of next WG call.
3) Resume deliberation on Data Elements for "thin data" only
* Handout:
<https://community.icann.org/download/attachments/64078626/RDSPDP-Handout-Fo
r6JuneCall.pdf?version=2&modificationDate=1496710904000&api=v2>
RDSPDP-Handout-For6JuneCall.pdf
* Deliberation to date has been focused on "thin data" as defined by
the Thick WHOIS Report:
. "A thin registry only stores and manages the information associated
with the domain name. This set includes data sufficient to identify the
sponsoring registrar, status of the registration, creation and expiration
dates for each registration, name server data, the last time the record was
updated in its Whois data store, and the URL for the registrar's Whois
service."
* Resume deliberation by trying to answer this question: Which gTLD
registration data elements should be included in "thin data"?
* Are today's gTLD WHOIS registration data elements classified as
"thin" sufficient at this time?
* Are any elements listed here NOT required as "thin data" accessible
through an RDS?
* Are any NEW elements required as "thin data" elements to be
accessible through an RDS?
* Why is the WG trying to answer to these questions?
* The working definition of "thin data" from the Thick WHOIS Report
was used to enable deliberation on other questions
* However, this WG never agreed upon specific data elements that are
required
* We are now addressing that by returning to the Data Elements charter
question
* We are now trying to determine what data elements are included in
"thin data"
* Note: "Thin data" elements in this context does not mean today's
"thin data" but rather the set of data elements to be made available without
authentication, accessible publicly to all
* Feedback from the WG in answer to these questions:
* Why do "status" and "date(s)" information need to be included in
"thin data"?
* Should DNSSEC information be included in "thin data"? DNSSEC
provides useful information to confirm what's in the DNS, and does not
include any PII
* Additional fields defined in 2013 RAA include Registrar Abuse
Contact Email and phone number, DNSSEC, and URL of the ICANN WHOIS Data
Problem Reporting System
* However, those additional 2013 RAA fields may not be "thin data"
* Expiration date might be considered PII, if associated with a
registrant's choice of when to renew during the registration process
* Suggestion to remove the expiration date from "thin data", and at
least examine it against the 4 tests of the proportionality principle
* Is there an overwhelming need to have expiration date accessible via
an RDS? Not because it might be personal data, but because of its use in
abuse
* There are many reasons why "thin data" is useful for legitimate
purposes, including the expiration date - if not linked to PII, it should
remain in the "thin data" set
* Comment from Chat: I'm not sure yet that I agree the status
information needs to be there
* Should a distinction be made between "thin data" for natural persons
and legal persons?
* NORC Registrant Identification Study Report examined percentage of
domains registered by natural persons and legal persons:
<http://gnso.icann.org/en/issues/whois/registrant-identification-summary-23m
ay13-en.pdf%5bgnso.icann.org>
http://gnso.icann.org/en/issues/whois/registrant-identification-summary-23ma
y13-en.pdf
* Same study examined percentage of domains used for commercial
purposes (note: user of domain name may not be registrant)
* If the WG is going to be making conclusions on what is included in
"thin data", then developing a definition for "thin data" might be required
Proposed WG agreement (to be tested by poll): Expiration Date should be
removed as a "thin data" element accessible without authentication.
Proposed WG agreement (to be tested by poll): DNSSEC should be added as a
"thin data" element accessible without authentication.
Action Item: Staff to develop poll to test above-noted proposed WG
agreements. All WG members to participate in poll no later than COB Saturday
10 June.
4) Brief updates on:
a) Legal analysis
. Leadership Team is starting the process to retain a legal analysis
in time to take advantage of the FY17 budget
b) ICANN59 plans: 26 June Cross-Community session, 28 June WG F2F
session
. Check <https://schedule.icann.org/grid/>
https://schedule.icann.org/grid/ for dates/times of WG face-to-face meeting
and cross-community discussion
. WG F2F Session Wednesday 28 June
. Agenda: <https://community.icann.org/x/lATfAw>
https://community.icann.org/x/lATfAw
. Abstract: <http://sched.co/B49L> http://sched.co/B49L
. Adobe Connect <https://participate.icann.org/jnb59-ballroom>
https://participate.icann.org/jnb59-ballroom
. Cross-Community Session Monday 26 June
. Agenda: <https://community.icann.org/x/ygffAw>
https://community.icann.org/x/ygffAw
. Abstract: <http://sched.co/B3oo> http://sched.co/B3oo
. Adobe Connect <https://participate.icann.org/jnb59-ballroom1>
https://participate.icann.org/jnb59-ballroom1
Action Item: All WG members to plan to attend ICANN59 Cross Community and
F2F WG sessions (see links above), either in-person or via remote
participation.
Action Item: All WG members encouraged to share the
<https://community.icann.org/download/attachments/59644409/Next%20Generation
%20RDS%20PDP%20-%20Newsletter%20-%20April-May%202017.pdf?version=1&modificat
ionDate=1496694757000&api=v2> GNSO Next-Generation RDS PDP WG April/May 2017
newsletter with their own SG/Cs and SO/ACs in preparation for the
cross-community discussion at ICANN 59 in Johannesburg
5) Confirm action items and proposed decision points
. WG Agreement: At least a defined set of "thin data" elements must
be accessible by unauthenticated RDS users
. WG Agreement: RDS policy must state purpose(s) for public access to
"thin data."
. Proposed WG agreement (to be tested by poll): Expiration Date
should be removed as a "thin data" element accessible without
authentication.
. Proposed WG agreement (to be tested by poll): DNSSEC should be
added as a "thin data" element accessible without authentication.
. Action Items:
. Staff to add above-noted WG agreements to working document.
. Rod Rasmussen and Vaibhav Aggarwal to complete action assigned
during 17 May call and distribute in advance of next WG call.
. Staff to develop poll to test above-noted proposed WG agreements.
All WG members to participate in poll no later than COB Saturday 10 June.
. All WG members to plan to attend ICANN59 Cross Community and F2F WG
sessions (see links above), either in-person or via remote participation.
. All WG members encouraged to share the
<https://community.icann.org/download/attachments/59644409/Next%20Generation
%20RDS%20PDP%20-%20Newsletter%20-%20April-May%202017.pdf?version=1&modificat
ionDate=1496694757000&api=v2> GNSO Next-Generation RDS PDP WG April/May 2017
newsletter with their own SG/Cs and SO/ACs in preparation for the
cross-community discussion at ICANN 59 in Johannesburg.
6) Confirm next meeting date: 13 June 2017 at 16:00 UTC
. Meeting Materials (all posted at
<https://community.icann.org/x/IMPRAw>
<https://community.icann.org/x/IsPRAw> https://community.icann.org/x/IsPRAw)
.
<https://community.icann.org/download/attachments/64078624/KeyConceptsDelibe
ration-WorkingDraft-31May2017.pdf?version=1&modificationDate=1496287681798&a
pi=v2> KeyConceptsDeliberation-WorkingDraft-31May2017.pdf and
<https://community.icann.org/download/attachments/64078624/KeyConceptsDelibe
ration-WorkingDraft-31May2017.docx?version=1&modificationDate=1496287698364&
api=v2> doc
.
<https://community.icann.org/download/attachments/64078626/RDSPDP-Handout-Fo
r6JuneCall.pdf?version=2&modificationDate=1496710904000&api=v2>
RDSPDP-Handout-For6JuneCall.pdf and
<https://community.icann.org/download/attachments/64078626/RDSPDP-Handout-Fo
r6JuneCall.pptx?version=2&modificationDate=1496710935000&api=v2> ppt
30 May Call Poll Results -
. PDF of Poll Questions:
<https://community.icann.org/download/attachments/64078624/Poll-from-30MayCa
ll.pdf?version=1&modificationDate=1496201558292&api=v2>
Poll-from-30MayCall.pdf
. Annotated Poll Results:
<https://community.icann.org/download/attachments/64078626/AnnotatedResults-
Poll-from-30MayCall-v2.pdf?version=1&modificationDate=1496683026000&api=v2>
AnnotatedResults-Poll-from-30MayCall-v2.pdf (for display during call)
. SurveyMonkey Summary Poll Results:
<https://community.icann.org/download/attachments/64078626/SummaryResults-Po
ll-from-30MayCall.pdf?version=1&modificationDate=1496585511000&api=v2>
SummaryResults-Poll-from-30MayCall.pdf
. SurveyMonkey Raw Data Poll Results:
<https://community.icann.org/download/attachments/64078626/RawDataResults-Po
ll-from-30MayCall.zip?version=1&modificationDate=1496585522000&api=v2>
RawDataResults-Poll-from-30MayCall.zip and
<https://community.icann.org/download/attachments/64078626/RawDataResults-Po
ll-from-30MayCall.xls?version=1&modificationDate=1496585537000&api=v2> XLS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170606/999a3482/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list