[gnso-rds-pdp-wg] IMPORTANT: Notes from RDS PDP WG F2F Meeting - 28 June
Lisa Phifer
lisa at corecom.com
Fri Jun 30 19:05:33 UTC 2017
Dear all,
Below please find notes from Wednesday's RDS PDP Face-to-Face WG meeting at
ICANN59. Cross-Community session notes will be provided separately.
NOTE: The next RDS PDP WG meeting has been rescheduled to 18 July at 16.00
UTC.
This date change was made after the F2F session concluded. Upon reviewing
action items below, WG leadership concluded that time allocated for the 11
July meeting would be better spent by each WG member individually reviewing
the listed data elements and then providing rationale for or against each
data element in response to this week's longer-than-usual poll. Rationale
gathered through this poll will then be used to inform data element
deliberation on-list and during the 18 July meeting.
To recap action items from the meeting:
Action: Staff to document cross-community feedback for WG consideration
during second pass on fundamental charter questions. For links to session
recordings, scribe feed, and notes from the cross-community session, visit:
<https://community.icann.org/x/ygffAw> https://community.icann.org/x/ygffAw
Action: Staff to distribute an expanded version of the data elements table
reviewed during this F2F session (
<https://community.icann.org/download/attachments/64947348/Data%20Elements%2
0Handout.pdf?version=1&modificationDate=1498639126213&api=v2> Data Elements
Handout.pdf) to include a description of each new data element and further
information about each element, extracted from the EWG Final Report, for WG
member review in preparation for participating in this week's poll and our
next meeting.
Action: Leadership team to draft poll to gather WG member rationale for or
against each data element, to inform on-list discussion and continued
deliberation in our next meeting. Staff to implement this poll on data
elements as directed by the leadership team. All WG members are encouraged
to respond to the poll no later than 15 July COB.
Best regards,
Lisa
Notes RDS PDP WG F2F Meeting at ICANN59 - 28 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/lATfAw>
https://community.icann.org/x/lATfAw
1. Introductions and 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: Maxim Alzoba
2. Background
a) Brief overview of WG charter
<https://community.icann.org/display/gTLDRDS/WG+Charter> and work plan
<https://community.icann.org/x/oIxlAw>
. See slide deck: ICANN59-RDS-PDP-WG-F2F-Slides-v3.pdf
<https://community.icann.org/download/attachments/64947348/ICANN59-RDS-PDP-W
G-F2F-Slides-v3.pdf?version=1&modificationDate=1498525841000&api=v2>
. GDPR session yesterday - Theresa Swinehart announced formation of a
task force to examine existing contract requirements with respect to data
protection and privacy. Michele Neylon is our WG's representative to that
task force. The task force will do their best to not duplicate our efforts,
and their findings may even contribute to our work.
b) WG rules
<https://community.icann.org/download/attachments/64078608/RDS%20PDP%20WG%20
List%20Discussion%20Rules.pdf> and expectations of PDP WG members
<http://gnso.icann.org/council/annex-1-gnso-wg-guidelines-08apr11-en.pdf>
. History of WHOIS has been volatile with many diverse views. All
view must be voiced and recognized, but that creates tension. In a WG with
over 190 members and 70 observers, there are additional challenges.
. ICANN Ombudsman Herb Waye shared a few remarks about communicating
in a respectful and civil manner. Please report any instance of
disrespectful behavior to the ombudsman: herb.waye at icann.org
. Goal is to collaborate constructively to find compromises and come
up with solutions to our charter mandate.
. Note WG rules (RDS PDP WG List Discussion Rules.pdf
<https://community.icann.org/download/attachments/64078608/RDS%20PDP%20WG%20
List%20Discussion%20Rules.pdf?version=1&modificationDate=1493747136000&api=v
2> ). As the list is large, please think before replying +1 whether that
reply is really needed. Try to remain focused and succinct in your
contributions to topic under discussion.
3. Brief updates on: legal analysis <https://community.icann.org/x/J1zwAw>
and ccTLD responses
<https://community.icann.org/display/gTLDRDS/ccTLD+Registry+Operators%27+Res
ponses+to+Questions+on+Privacy%252C+Data+Protection+and+the+GDPR>
. Legal analysis <https://community.icann.org/x/J1zwAw> sought based
on WG member requests for independent analysis by outside counsel.
Leadership team evaluated proposals from several firms, with help from WG
member advisors, and selected a firm for this project. We are now completing
contracting with a firm that appears to be broadly respected by
stakeholders. The project will produce a report with their analysis of WG
questions within 6 weeks.
. Noted that this is just the first legal analysis; additional legal
analysis needs are anticipated in the future, each project to address
specific WG requests. It was suggested that we consider whether a retainer
arrangement would be appropriate for on-going Q&A on applicable laws.
. Noted that the WG's question list originally prepared for ICANN58
session may need to be refined; confirmed that refinement is anticipated as
part of the legal analysis project.
. ccTLD responses
<https://community.icann.org/display/gTLDRDS/ccTLD+Registry+Operators%27+Res
ponses+to+Questions+on+Privacy%252C+Data+Protection+and+the+GDPR> to
questions sent to 18 ccTLD operators have been received from .me, .ie, .ca
thus far - after more are received, we will look for common threads. See
ccTLD responses
<https://community.icann.org/display/gTLDRDS/ccTLD+Registry+Operators%27+Res
ponses+to+Questions+on+Privacy%252C+Data+Protection+and+the+GDPR> wiki page
for links to all responses; all responses to be added to this page as they
are received.
4. Cross-Community Session <http://sched.co/B3oo> results
a) Plan to consolidate/review/reflect feedback
b) Plan to finish deliberation on "minimum public data set" (MPDS)
. To allow us to move on beyond what's been covered thus far, we will
consolidate cross-community session feedback for consideration during our
second pass on these agreements
. Also the plan for loose ends on MPDS - remember and address during
our second pass
Action: Staff to document cross-community feedback for WG consideration
during second pass on fundamental charter questions. For links to session
recordings, scribe feed, and notes from the cross-community session, visit
this link: <https://community.icann.org/x/ygffAw>
https://community.icann.org/x/ygffAw
5. Start deliberation beyond "minimum public data set"
. See slides posted in advance of meeting:
ICANN59-RDS-PDP-WG-F2F-Slides-v3.pdf
<https://community.icann.org/download/attachments/64947348/ICANN59-RDS-PDP-W
G-F2F-Slides-v3.pdf?version=1&modificationDate=1498525841000&api=v2>
. Additional material displayed after break:
<https://community.icann.org/download/attachments/64947348/Data%20Elements%2
0Handout.pdf?version=1&modificationDate=1498639126213&api=v2> Data Elements
Handout.pdf
. Refer to latest Working Draft
<https://community.icann.org/x/p4xlAw> for Charter Questions/Subquestions
a) gTLD registration data element buckets
. Registration data elements defined in the 2013 RAA can be
subdivided into these buckets:
o Minimum public data set (MPDS)
o "Thin data" elements not yet addressed
o "Thick data" elements, including Registrant data, Admin/Tech contact
data
o New data elements that may be required
. We spent the past few months deliberating on the MPDS; it is now
time to move on to deliberating on the same questions, but expanding scope
of deliberation to other data elements
b) Choose most effective starting point for Tasks 12/cd
. See Work Plan <https://community.icann.org/x/oIxlAw> Task 12 for
approach to reach consensus on Foundational Question
. Task 12c = Key concepts for UP, DE, PR for data beyond MPDS
. Task 12d = Key concepts for GA for data beyond MPDS
. Would it help to focus first on Legal person data or Natural person
data?
Discussion
. See slide 21 - leadership team proposes focusing on Legal Person
Registrant Data next
. Some ccTLDs take this approach - distinguishing at time of
collection, but are these separable?
. Should we be looking at the superset of contact data, to determine
how we'll deal with contact data overall, then figure out how to
display/collect/process Legal versus Natural person data?
. Alternate proposal: Look at the superset of all elements that the
EWG came up with as first step
. In some jurisdictions a natural person can't be involved in
entrepreneurship without forming of a legal body reported to the tax agency,
so he's something between natural and legal person.
. Consider having a special flag for fields which clearly says that
these fields (e.g., address, name) are personal data or not. In Russian
Federation as a registrar, we came to the conclusion that until clearly
shown, it's not possible to distinguish between natural and legal persons.
. If you start with a small subset, it will be a problem that you
haven't actually defined your perimeters. Figure out your superset -the
legal perspective is figure out all the data elements you want to gather -
and then figure out how they sort [into natural person data or not]
. Currently most entities self-identify in the Registrant
Organization field by indicating their legal name. However, many natural
persons also put their own name in the Organization field.
. There are necessary distinctions between Legal/Personal and
Commercial data subjects, but the priority now should be the personal data
for individuals. The deadline for conformity with GDPR in and for EU
individuals is rather short.
. The requirements we establish in this PDP are for the future, not
for immediate resolution of existing Whois system compliance with GDPR.
. If we start with elements that are clearly Legal Person, we might
be able to make progress on those quickly, then deal with the harder
agreements
. Legal/Natural Person distinction applies in EU law but does not
apply in all national laws. In some countries, privacy rights go to the
speaker, which may be a group and not an individual, due to risk of
persecution for some groups.
. Different jurisdictions need to be applied to data elements as a
meta set, and then apply specific laws within each jurisdiction to the data
. If we look at an element like Registrant Organization, which is
clearly Legal Person, we know we won't convey personal privacy rights to
that entity and that might simplify agreements on how we'll collect and
display that data element
. Want ability for an organization to put all the data out there, if
they choose
. Note that EWG identified a purpose-based contacts approach, which
included data elements beyond today's Admin and Tech contacts (it's not just
the Registrant's entity type)
. Data elements are not different, it's just that it belongs to
different data subjects - for example, people enter their own name in the
Organization Field, so it is not as simple as checking the Org field to
determine entity type
. Self-identified registrants as entities is a different discussion
than looking at commercial activity on a website using that domain name
registration
. Commercial vs non-commercial discussion has already been settled in
PPSAI PDP, as it pertains to provision and use of Privacy/Proxy services
. Don't believe the PPSAI debate (and result) is relevant to the
current discussion, because PPSAI PDP [charter and scope] was different.
. Self-identification as a Legal Person could allow a given set of
rules to apply
. Important to talk about design of data before talking about
processing. For fields marked as personal data, there might be different
storage requirements, etc.
. Even in the case of a Legal Person entity, there may be fields that
are personal data
. Focusing on edge cases and grey areas is not a great place to start
- there will always be registrations associated w Legal Persons and
registrations associated with Natural Persons, if we start with those, we
can make progress and then we can tackle edge cases
. If we examine the data set, need to avoid straying into how data
will be used when establishing the universe of data.
. Proposal: Concentrate on the superset of data elements that may be
collected and possibly displayed in the RDS. That is, review the entire
table of proposed elements, decide what to delete/add, and then decide what
to collect/display.
. Based on straw poll, we will approach this from a data set
perspective first
. Note: Still need capacity to add or remove data elements in the
future - this could be one of the WG's recommendations (e.g., communication
methods may change for contact in the future)
c) Deliberate on chosen charter question for chosen data "bucket" --
. See above discussion and straw poll: Agreed next focus area:
Data Element requirements overall
. See ADDITIONAL MATERIAL:
<https://community.icann.org/download/attachments/64947348/Data%20Elements%2
0Handout.pdf?version=1&modificationDate=1498639126213&api=v2> Data Elements
Handout.pdf, quickly excerpted during the break from EWG Report Annex D to
support deliberation using the approach identified above
. Contains list of data elements proposed in the EWG Final report;
these are the data elements agreed upon by the EWG as needed to serve the
set of permissible purposes in that report
. Question: You don't collect data that is not required, so shouldn't
you start with the purposes and the data elements they need, then review the
set of data elements? (Yes)
. The list contains data elements that somebody COULD use; these data
elements were not all obligatory (i.e., mandatory to collect or display)
. Could this result in needing two separate systems - one for
personal data and another for the rest?
. Making something opt in / consent does not justify inclusion, if it
is completely unnecessary for the purpose (i.e. the registration of a domain
name). Under Data Minimization things like social media details - regardless
if they 'could be used' - still should not even be an option
. If you have a form with optional fields, there must be
knowledgeable consent. Why would you create two separate systems to
accommodate this?
. We're using purpose in a lot of different ways. The purpose under
EU DP laws isn't the same as the "hallway" definition of purpose - which may
be uses of data
. Might you need to know the type of entity for each data element?
For example, Registrant Type identifies the type of entity for all of the
Registrant data elements. But perhaps you need something more granular than
on the block level?
. Is there a requirement for the ability to signify something on a
per-element basis, such as data subject type, interest of data subject,
purpose for collection
. Suggestion to add a Remarks column to the table to allow for
indication of other information about the data element
. Some remarks might be information determined at time of collection,
while other remarks might be information determined by policy like purpose
served
. Telephone numbers may not be the most desirable way to be contacted
in the future - there might be a need for alternative contact methods
(twitter handles, etc.) instead of telephone #.
. Note: In the EWG Report Annex D list of elements, Registrant SMS,
IM, Social Media - those were examples of this, possibly not comprehensive.
. It might be possible to have multiple values for each data element
to allow for a list of alternative methods of contact.
. Stephanie Perrin: Use cases developed by EWG were more of a wish
list and possibly outside the bounds of data protection law. Endorsed this
approach because it might help us weed out those uses that were out of
bounds. Need to identify purpose for each data element.
. Data elements such as SMS may introduce new risks - for example,
people may not want to be contacted by SMS, or SMS may be used in two-factor
authentication so could be used
. Need to make distinction between fields that are mandatory and
fields that specific TLD operators may wish to offer (e.g., trademarks)
. Another value in "third column" is public/private - whether or not
the data subject considers the data to be public or private
. Anything ICANN supervises puts them in position of data controller.
If ICANN requires a data element in a contractual agreement, then ICANN is
responsible and accountable for that data element.
. However, Registrars and Registries have their own contracts with
each other, not controlled by ICANN. Any TLD-specific requirements in those
contracts are not set by ICANN.
. We are talking about minimum data elements from ICANN's
perspective, are we not? Anything outside ICANN's remit is not within
ICANN's remit.
. Registrant postal address and geographic location may no be longer
needed. This data isn't needed when I create a Facebook account or many
other kinds of service accounts, so why is it needed for the DNS?
. Given the existence of IDN gTLDs, we might need the Language of the
Domain Name as the Data Element? Will this list ultimately go through
translation and transliteration processes?
. Yes. Both the T/T recommendations and the IRD WG final report are
included in the background documents for this PDP found here:
https://community.icann.org/x/R4xlAw
. Regarding the list and assessment of personal data versus not
personal data, what does accountability mean? What are the particular
respects of accountability? In the GDPR, there are at least seven or eight
rights for the data subject for which the data controller can be held
accountable for, but in every other international data protection
legislation there are at least four: The right to access data, right of
deletion, right of rectification, and sometimes right of blocking as well.
So for all of these rights, the data controller must put in place a
mechanism to ensure this right. Data protection authorities would look at
how directly or how easily they can exercise those rights.
. Registrant Name may not be needed for natural persons, particularly
if there is something like Registrant Contact ID that allows identification
of that Registrant. So long as the Registrar has the name of the Registrant,
collected at point of sale, possibly the need for access to Registrant Name
can be served outside the RDS.
. As we heard in the Cross Community Working Group, you need to know
the person or the contact -- whether it' a company or otherwise - a way to
access that. So completely disagree: do not think contact ID is at all the
same as the name of the person. For accountability purposes, you absolutely
must have the name of the Registrant.
. Not suggesting that the data is not collected at the point of sale,
the point of activation, registration or what have you. If you could
actually collapse that entire registrant block of data elements down to a
registrant ID, it can contain whether it's validated or not, the last
update, etc.
. In the ccTLD space, there are several registries (e.g., .fr) where
the name can just completely disappear. It's still accessible via other
means but it isn't necessarily appearing in [WHOIS]. We do have the
information if somebody comes to us with through proper channels.
. We might be conflating data collected for RDS and data collected by
the Registrar so they can do their business. Two different data sets,
overlapping.
. Mixed views on this data element (Registrant Name) and associated
block.
. Registrars did not have any need for contact ID until the 2013 RAA
required it; it was not needed for their business purposes.
. Registrants should be educated about taking responsibility for what
data they disclose. No one is being tricked into disclosing their PII.
. Question: How many of you are comfortable with the five data
elements listed:
Registrant Name/Org, Type, Contact ID, Contact Validation Status, Last
Updated Timestamp
. Show of hands demonstrated more support than opposition, but not
all weighed in
Action: Staff to distribute an expanded version of the data elements table
reviewed during this F2F session (
<https://community.icann.org/download/attachments/64947348/Data%20Elements%2
0Handout.pdf?version=1&modificationDate=1498639126213&api=v2> Data Elements
Handout.pdf) to include a description of each new data element and further
information about each element, extracted from the EWG Final Report, for WG
member review in preparation for participating in this week's poll and our
next meeting.
Action: Leadership team to draft poll to gather WG member rationale for or
against each data element, to inform on-list discussion and continued
deliberation in our next meeting. Staff to implement this poll on data
elements as directed by the leadership team. All WG members are encouraged
to respond to the poll no later than 15 July COB.
6. Confirm action items, proposed agreements, and next meeting date
UPDATED: The next RDS PDP WG meeting has been rescheduled to 18 July at
16.00 UTC.
This date change was made after the F2F session concluded. Upon reviewing
action items below, WG leadership concluded that time allocated for the 11
July meeting would be better spent by each WG member individually reviewing
the listed data elements and then providing rationale for or against each
data element in response to this week's longer-than-usual poll. Rationale
gathered through this poll will then be used to inform data element
deliberation on-list and during the 18 July meeting.
Action: Staff to document cross-community feedback for WG consideration
during second pass on fundamental charter questions. For links to session
recordings, scribe feed, and notes from the cross-community session, visit:
<https://community.icann.org/x/ygffAw> https://community.icann.org/x/ygffAw
Action: Staff to distribute an expanded version of the data elements table
reviewed during this F2F session (
<https://community.icann.org/download/attachments/64947348/Data%20Elements%2
0Handout.pdf?version=1&modificationDate=1498639126213&api=v2> Data Elements
Handout.pdf) to include a description of each new data element and further
information about each element, extracted from the EWG Final Report, for WG
member review in preparation for participating in this week's poll and our
next meeting.
Action: Leadership team to draft poll to gather WG member rationale for or
against each data element, to inform on-list discussion and continued
deliberation in our next meeting. Staff to implement this poll on data
elements as directed by the leadership team. All WG members are encouraged
to respond to the poll no later than 15 July COB.
Meeting Materials (all posted at <https://community.icann.org/x/lATfAw>
https://community.icann.org/x/lATfAw)
. <https://community.icann.org/display/gTLDRDS/WG+Charter> WG
charter and <https://community.icann.org/x/oIxlAw> work plan
.
<https://community.icann.org/download/attachments/64078608/RDS%20PDP%20WG%20
List%20Discussion%20Rules.pdf> WG rules
<http://audio.icann.org/meetings/cph58/cph58-OPEN-2017-03-11-T1250-hallc14-Z
MJnPite6LbenznEM8Vi75R9UAOkTn1T-en.m3u> and
<http://gnso.icann.org/council/annex-1-gnso-wg-guidelines-08apr11-en.pdf>
expectations of PDP WG members
. Latest
<http://audio.icann.org/meetings/cph58/cph58-OPEN-2017-03-11-T1250-hallc14-Z
MJnPite6LbenznEM8Vi75R9UAOkTn1T-en.m3u>
<https://community.icann.org/x/p4xlAw> Working Draft of Key Concepts
Agreements
. Slide deck:
<https://community.icann.org/download/attachments/64947348/ICANN59-RDS-PDP-W
G-F2F-Slides-v3.pdf?version=1&modificationDate=1498525841000&api=v2>
ICANN59-RDS-PDP-WG-F2F-Slides-v3.pdf and
<https://community.icann.org/download/attachments/64947348/ICANN59-RDS-PDP-W
G-F2F-Slides-v3.pptx?version=2&modificationDate=1498526085000&api=v2>
ICANN59-RDS-PDP-WG-F2F-Slides-v3.pptx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170630/01df7835/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list