[gnso-rds-pdp-wg] IMPORTANT: Notes from RDS PDP WG Meeting - 11 April
Lisa Phifer
lisa at corecom.com
Tue Apr 11 18:38:55 UTC 2017
Dear all,
Below please find notes from today's RDS PDP WG meeting.
To recap action items:
* Action #1: WG members to review answers from privacy experts
participating in ICANN58 summit in preparation for next week's WG call
* Action #2: Staff to submit request for ICANN59 cross-community
session
* Action #3: WG members to participate in this week's poll, which
will include input of a couple of privacy expert question answers as well as
one proposed agreement
In addition, ccTLD Questions and Authoritative Definition Actions carry over
from last week's WG call
This week's poll link to be circulated separately.
Best regards,
Lisa
Notes RDS PDP WG Meeting - 11 April 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/CcPRAw>
https://community.icann.org/x/CcPRAw
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: Andrew Sullivan: Officially now an Oracle employee;
Maxim Alzoba: Now a member of the GNSO SSC
2. Updates on in-progress tasks:
a. Response from privacy experts who participated in the ICANN58 privacy
summit to questions from the working group:
. See
<https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-P
anel-Responses-Draft-7April2017.docx>
https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-Pa
nel-Responses-Draft-7April2017.docx
. Poll questions will be circulated on the first two questions asked,
and answers provided.
. WG members expected to individually go over the responses from the
privacy experts within the next week.
. WG expected to discuss/go through the answers in detail, starting
during next week's WG call.
. Key concepts identified as a result of responses from privacy
experts, IP interests, LE, etc... (all competing interests), will all be
taken into account to develop solutions (RDS requirements)
. The privacy experts are not RDS experts. The questions sent to them
were developed by the WG for further our education on privacy/data
protection law requirements, but this Q&A can be a two-way opportunity for
the WG to also educate privacy experts on registration data and RDS.
Action #1: WG members to review answers from privacy experts participating
in ICANN58 summit in preparation for next week's WG call
b. ccTLD Questions:
. Small team continuing work on developing the questions
. 4 - 5 questions already identified
. More questions will be identified by next week
c. Definition of "Authoritative"
. Small team working on definition, but not yet finished
. Looking at definition in RFC documents, but proving unhelpful for
the WG's purpose
. From AC Chat: Andrew Sullivan's suggestion to the team is that we
just pick a different term. I wonder whether that would be acceptable to
people?
. Refer to chat archive for further dialog on possible definitions
d. Meeting request for ICANN59
. In addition to our regularly-scheduled F2F WG meeting, the
leadership team is submitting a request for a 3 hours cross-community
session to solicit feedback on WG's key concepts and points of rough
consensus so far
. As this focus of ICANN59 is policy, this is an opportunity to
obtain feedback from everyone to inform our work post-ICANN59 - including
first initial report
Action #2: Staff to submit request for ICANN59 cross-community session
3) Start deliberation on the charter question/subquestion 3.1 (rephrased):
What are the purpose(s) of each existing gTLD thin registration data
element? Do they sufficiently meet the needs of purposes identified as
legitimate?
. 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
. This document reflects a merge of Andrew Sullivan's proposed
approach for defining the purpose of each thin data element with the EWG's
Annex D listing permissible purposes
. When EWG crafted its list of permissible purposes, it examines
existing uses of registration data - explained in detail in Section III of
EWG Report. Then took use cases for each purpose and related purposes to
data elements involved in each purpose. That led to mapping of data elements
to purposes in Annex D (reflected in the merged doc here). Considered mostly
"permissible" or legitimate purposes, although the EWG also examined
impermissible purposes.
. Suggestion: replace "All" with actual list of EWG purposes to make
this document self-standing for reading by those not familiar with EWG's
report
. List seems to be technical and inclusive. The WG should consider
whether every data element is really needed or whether something could be
accomplished in an easier or less intrusive way.
. Note that the EWG was not tasked with making policy - it explored
issues and suggest ways forward, including alternative ways of doing things
(e.g., validators concept, secure protected credentials, other processes to
accomplish goals/use cases). EWG Report was not therefore limited to the
standard thinking or old ways of doing things. It is up to this WG to take
that information and other inputs and decide what are legitimate purposes
and how do we accomplish the goals those purposes represent.
Domain Name
. Is there any disagreement that the domain name will be necessary
for every legitimate purpose that the WG recommends? None expressed
Proposed WG Agreement: The domain name will be necessary for every
legitimate purpose.
Registrar Name and IANA ID
. Should Registrar Name be a registration data element?
. That is, does anyone disagree that the Registrar Name should be
(collected/derived) included as a registration data element for the purposes
listed?
. Rational for opposing: If Registrar Name can be obtained by looking
up the Registrar ID in IANA, does it really need to be in the RDS as well?
Minimalist approach argues for collecting Registrar IANA ID not name
. Minimalist approach for publication is a separate question (someone
may choose to display/send data not collected)
. Registrar Name only doesn't help because more than one IANA ID can
bind to the same Registrar Name
. Note that these aren't really "collected" from a registrant and are
populated by looking up the "friendly name" from the ID. Name isn't pushed
from registrar to registry over EPP - it is derived during a transaction,
ultimately pulled from another place (e.g., IANA)
. Should we discuss adding Reseller to thick or thin data? (discuss
when we get to possible additions, for now focus on existing thin data
elements)
. Do all of the listed EWG purposes apply to each data element as
listed?
. Andrew Sullivan in his proposal Grouped Registrar and Sponsoring
Registrar IANA ID together because they are similar and both needed for the
same purpose(s)
. Refer to Chat archive for detailed discussion of how IANA ID and
Registrar Name are related, derived, and used during a transaction
Comments about purposes listed
. Note that purposes deliberated upon thus far by this WG are already
listed in our working document, section 2.2.2, where we started from the
purposes listed in the EWG Exec Summary. However, this WG only deliberated
on these as purposes for thin data collection, and this WG still needs to
more fully examine and define each purpose at some point - including looking
at purposes from a privacy and data protection law perspective
. Have purposes been discussed in accordance with ICANN's remit? Not
yet - but we need to
. For example, academic research may or may not be within ICANN's
remit (or contrary to that remit) to support this purpose through an RDS
(may depend on research goal). Need to watch out before drawing bright lines
that divide some purposes into legitimate or not.
. Chat comment: In respect of the remit issues: this is why not
everything discussed in Andrew Sullivan's email reflected EWG purposes,
because once I had a single reason why everyone needed the data, other
purposes didn't matter?
. Chat comment: For data collection, one "legitimate" purpose is
probably sufficient (ignoring retention and other ancillary issues). Full
debate on the legitimacy of all purposes becomes much more important for
discussions around what data is provided to data requestors and under what
conditions (e.g. gated vs. open)
. Within the EWG's work, we tried to look at why people were using
registration data and why, then categorize that into legitimate vs
illegitimate - but we didn't look at this as does this fall within ICANN's
remit at this purpose by purpose level
. It is also important to differentiate between purposes for
collection and access - EWG's purposes may focus more on access (based on
use cases) and not purposes for collection in the first place
. Chat comment: The "academic" question is actually quite nuanced and
layered given ICANN's commitments to transparency and other responsibilities
around competition, access, etc. One of the ways you *can* do that is by
providing data to researchers working under well-defined (and it is in the
world today) academic guidelines and oversight to do studies on these
various topics. For example, can people in developing countries get access
to domain registration services or are they priced out of the market, or do
they not have local registrars available that provide local language
services? This kind of important question needs RDS-style data at scale to
answer. So one or our jobs may well be to answer that question.
. For example, is using data collected for one legitimate purpose for
another purpose such as fighting child abuse legitimate and within ICANN's
remit? May be legitimate given certain conditions, but need to raise these
questions as we look at the purpose for each data element.
Action #3: WG members to participate in this week's poll, which will
include input of a couple of privacy expert question answers as well as one
proposed agreement
4) Confirm action items and proposed decision points
Proposed WG Agreement: The domain name will be necessary for every
legitimate purpose.
. Action #1: WG members to review answers from privacy experts
participating in ICANN58 summit in preparation for next week's WG call
. Action #2: Staff to submit request for ICANN59 cross-community
session
. Action #3: WG members to participate in this week's poll, which
will include input of a couple of privacy expert question answers as well as
one proposed agreement
. In addition, ccTLD Questions and Authoritative Definition Actions
carry over from last week's WG call
.
5) Confirm next meeting date: 18 April, 2017 at 05:00 UTC
Meeting Materials (all posted at https://community.icann.org/x/CcPRAw)
.
<https://community.icann.org/download/attachments/56986791/KeyConceptsDelibe
ration-WorkingDraft-4April2017.pdf?version=1&modificationDate=1491335255000&
api=v2> KeyConceptsDeliberation-WorkingDraft-4April2017.pdf and
<https://community.icann.org/download/attachments/56986791/KeyConceptsDelibe
ration-WorkingDraft-4April2017.docx?version=1&modificationDate=1491335268000
&api=v2> doc
.
<https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-P
anel-Responses-Draft-7April2017.pdf?version=1&modificationDate=1491837560000
&api=v2> ICANN58-Privacy-Panel-Responses-Draft-7April2017.pdf and
<https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-P
anel-Responses-Draft-7April2017.docx?version=1&modificationDate=149183975600
0&api=v2> doc
.
<https://community.icann.org/download/attachments/64078512/Merged-ThinDataPu
rposes-v1.pdf?version=1&modificationDate=1491326385000&api=v2>
Merged-ThinDataPurposes-v1.pdf (initial rough draft displayed during call)
.
<https://community.icann.org/download/attachments/64076964/Sullivan-Suggesti
onForPurposeInDetail.pdf?version=1&modificationDate=1490583766000&api=v2>
Sullivan-SuggestionForPurposeInDetail.pdf and
<https://community.icann.org/download/attachments/64076964/Sullivan-Suggesti
onForPurposeInDetail.docx?version=1&modificationDate=1490583779000&api=v2>
doc
.
<https://community.icann.org/download/attachments/64078512/EWG-AnnexD-ThinDa
taOnly.pdf?version=1&modificationDate=1491328937000&api=v2> Annex D of the
EWG final report (thin data only) - excerpted from full
<https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf>
EWG Final Report
.
<https://community.icann.org/download/attachments/56986784/RDS%20PDP%20WG%20
Work%20Plan%20-%20Clean%203%20April%202017.docx?version=1&modificationDate=1
491239583533&api=v2> Latest RDS PDP WG Phase 1 Work Plan - as of April 2017
(posted 3 April 2017)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170411/0d3403aa/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list