[gnso-rds-pdp-wg] Notes from RDS PDP WG F2F Meeting - 3 November 2016
Lisa Phifer
lisa at corecom.com
Fri Nov 4 04:29:29 UTC 2016
Dear all,
Below please find notes from our F2F WG meeting, along with links to meeting
materials. Deliberations will continue in our next WG meeting (Tuesday, 22
November 2016); additional materials for that meeting will be distributed in
advance of that call.
Best, Lisa
RDS PDP WG F2F Meeting - 3 November 2016
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 at <https://community.icann.org/x/NAe4Aw>
https://community.icann.org/x/NAe4Aw
1) Introduction & SOI Updates
. Roll call will be taken from AC
. Please remember to update your SOI
2) Accomplishments and Status
. What have we accomplished so far?
. See slides presented during the meeting
<https://community.icann.org/download/attachments/62392116/ICANN57-RDS-PDP-W
G-Slides-Draft8.pptx>
3) Next steps & Working Session
. See slides presented during the meeting
<https://community.icann.org/download/attachments/62392116/ICANN57-RDS-PDP-W
G-Slides-Draft8.pptx>
. Commence deliberations on possible requirements during today's
meeting, focusing on first three areas (privacy, users and purposes, data
elements)
Start discussions today, using a randomized iterative approach:
. Sort possible requirements for phase 1 requirements only.
. Randomly order the three questions: Users/Purposes, Data Elements &
Privacy.
. For the first round, start with the first randomly selected
question, followed by the second, and then the third, discussing a subset of
possible requirements, using the Prerequisites/Dependencies, Codes, and
Keywords to select subsets for deliberation.
. For the next round, rotate the order of questions so that the
second becomes the first, the third becomes second, and the first becomes
third, iterating on step 3.
Approach to reach consensus in phase 1
. See meeting materials: Approach to reach consensus during Phase 1
<https://community.icann.org/download/attachments/62392116/RDS%20PDP%20WG%20
Approach%20for%20Consensus%20-%2027%20October%202016.docx>
. Start by deriving rough informal consensus on policy requirements
after deliberation on first 3 questions as well as GA, DA and Other
Questions
. Following this deliberation, the foundational question is expected
to be answered: Is a new RDS policy framework needed or can the current
WHOIS policy framework be adjusted to meet requirements?
. This initial answer and rationale to be published in the first
Initial Report for public comment. WG to review all input received and then
review other questions in the charter which will lead to a second Initial
Report that will be published for public comment.
. Only at this stage will formal consensus be sought using process
defined in Section IV of Charter.
. Consensus recommendations and statements will be published in the
Final Report for Phase 1.
. After considering this WG's recommendations in the Final Report for
Phase 1, GNSO Council will decide on next steps, which depend on the answer
to the foundational question.
For today's meeting:
. Cover the first subset of Phase 1 Code=A possible requirements
without dependencies in this randomly selected order: users and purposes;
data elements; privacy
. Iterative process - no final decisions during today's meeting. Just
a starting point to move forward from and build informal consensus,
hopefully leading to formal consensus at the end of Phase 1.
. Subset of possible requirements for discussion were circulated
prior to today's meeting:
<https://community.icann.org/download/attachments/62392116/PRSpreadsheets-D5
-CodeAOnly-NoDependencies.pdf?version=1&modificationDate=1477710647000&api=v
2> PRSpreadsheets-D5-CodeAOnly-NoDependencies [PDF] and
<https://community.icann.org/download/attachments/62392116/PRSpreadsheets-D5
-CodeAOnly-NoDependencies.xlsx?version=1&modificationDate=1477710695000&api=
v2> [XLS]
. Depending on progress today, determination will be made on what
will get covered during the upcoming meetings, rotating the order of
deliberation on the first three charter questions.
Initial Deliberations
. Initial Subset for Deliberation:
<https://community.icann.org/download/attachments/62392116/PRSpreadsheets-D5
-CodeAOnly-NoDependencies.pdf?version=1&modificationDate=1477710647000&api=v
2> PRSpreadsheets-D5-CodeAOnly-NoDependencies [PDF] and
<https://community.icann.org/download/attachments/62392116/PRSpreadsheets-D5
-CodeAOnly-NoDependencies.xlsx?version=1&modificationDate=1477710695000&api=
v2> [XLS]
. Displayed List of PRs without Dependencies:
<https://community.icann.org/download/attachments/62392116/Initial-Deliberat
ion-List-v2.pdf?version=1&modificationDate=1478231277181&api=v2>
Initial-Deliberation-List [PDF] and
<https://community.icann.org/download/attachments/62392116/Initial-Deliberat
ion-List-v2.docx?version=1&modificationDate=1478231349204&api=v2> [DOC]
UP-D01-R01:
"In support of ICANN's mission to coordinate the global Internet's system of
unique identifiers, and to ensure the stable and secure operation of the
Internet's unique identifier system, information about gTLD domain names is
necessary to promote trust and confidence in the Internet for all
stakeholders." (p. 16, Section IIb, Purpose)
. Source: EWG Final Report
<https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf>
. Three possible requirements within this PR: support the stable and
secure operations, support the unique identifier system, and to promote
trust and confidence in the system
. The RDS system as updated should promote consumer trust and
confidence in the Internet.
. Information is necessary for those registering domain names, but is
it necessary to promote trust and confidence? Some agree, some disagree
whether information promotes trust and confidence
. What information is necessary? To be examined as we move forward
iteratively
. Need to be clear about the purpose of any recommendation - in this
case this PR is a general requirement - foundational and high level - not
specific
. Define "stakeholders" or drop phrase "all stakeholders"
. This PR is great as an aspirational statement but is too subject to
interpretation, would prefer to label as a goal or aspiration. A purpose
has to be specific, limited, and proportionate.
. An option is to incorporate this PR within the statement of purpose
rather than capture it as a requirement
UP-D01-R02:
"gTLD registration data [must be] collected, validated and disclosed for
permissible purposes only." (p. 21, p. 31 Principle 6)
. Source: EWG Final Report
<https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf>
. Key phrase is "for permissible purposes only"
. Collection and disclosure or permissible purposes only is fine, but
you don't validate for a purpose - must be accurate enough for a given
purpose
. Information disclosed should be validated - disclosing false
information defeats the purpose
. "For permissible purposes" applies to all three or just disclosure
. Noted that registrars collect additional information that may not
be for a permissible purpose, but that is not part of the RDS policy being
defined here
. Does validation for a particular purpose occur only when data is
requested, or when it is collected? (the latter)
. Do possible requirements fall into different categories? General
principles vs specific purposes. For example, data processing standards
depend on specific purposes (not general principles)
. Removing validation from this PR does not mean validation is not
important but it may be covered elsewhere (for example, in PRs for accuracy)
. "gTLD registration data must be collected for permissible purposes
only"; (2) gTLD registration data must be validated; (3) gTLD registration
data must disclosed for permissible purposes only. Of course, each of these
could be supplemented with additional more detailed but still granular
requirements (such as about what types or level of validation should be
applied)
. I think (1) would mean that the purposes for collection of the data
would be presented to the registrant (and permission would be gained) prior
to collection Permissible purpose for collection not necessarily the same
as permissible purpose for disclosure
. Is it possible to register a domain name which is missing data
required for a permissible purpose?
DE-D01-R01:
The [gTLD registration directory service] must accommodate purpose-driven
disclosure of data elements.
. Source: EWG Final Report
<https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf>
. Like this requirement (DE-D01-R01) because it is worded simply and
to my mind doesn't result in multiple, diverging interpretations
. Disclosure does not necessarily refer to public data - needs to be
precise about which data is public (e.g., DNS Name Servers) and which data
is disclosed for a specific purpose (e.g., contact data)
. If there are too many purposes, does that make all data accessible?
Purposes need to be specific, and access for a given purpose must be
controlled.
. don't read this requirement as implicitly allowing all purposes to
be valid. so the presumption that many purposes== many accesses may be
misplaced
. "Purpose-driven disclosure" must be defined
. The system has to allow disclosure to [law enforcement or another
requestor] for a specific purpose/specific purposes, yet to be defined.
DE-D01-R22:
Validators, Registries and Registrars may collect, store, or disclose
additional data elements for internal use that is never shared with the
[gTLD registration directory service].
. Source: EWG Final Report
<https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf>
. Registrars clearly collect data not shared with the RDS but that is
necessary for its business (e.g., credit card data)
. Need to clearly differentiate between ICANN-mandated data that must
be collected (via RAA) and customer relationship data (which is not the
subject of the RAA) - both in accordance with local law
. "should collect" as one piece, "should display" as another piece
. what is collected beyond [the RIA and RAA requirements] are not
ICANN's business
. What about registry-specific data? (e.g., proof provided to
registrars for certain gTLDs)? Would this be relayed from registrar to
registry even if not disclosed through the RDS?
. Don't need to explicitly state that some data is outside the scope
if the default position is that only data specifically required is within
scope (rewrite this negative requirement as a positive principle?)
DE-D12-R02:
The [gTLD registration directory service] should collect and display uniform
sets of data regardless of the registry involved. (sec. 5.2)
. Source:
<http://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf> GNSO PDP
on Thick WHOIS Final Report (2013)
. Uniformity requirement in Thick Whois has been commented on by DP
commissioners - "uniformity" is a dangerous word because it can imply
uniform disclosure - consistent labeling and display is narrower
. Further clarification may be needed on Thick WhoIs before
determining this
. Must be some carve outs for differences between registries
. Consistent labeling and display - this is the intent of "uniform"
in this PR, but there may be a need to display different data (in addition
to consistent display of common data) that is not precluded
. Uniformity is important for interoperability, but it is not
necessarily more important than having the right data for the right
purpose(s)
DE-D19-R01:
Based on the ICANN Governmental Advisory Committee (GAC) proposed
principles, gTLD [registration directory] services "should provide
sufficient and accurate data about domain name registrations and registrants
(.)" (para 3.3)
. Source: GAC Principles regarding gTLD WHOIS Services
<http://whois.icann.org/en/link/gac-principles-regarding-gtld-whois-services
> (28 March 2007)
. This requirement (d19-01) needs more precision. left as is it
actually concerns me
. Seems more like a principle than a requirement
. This statement wasn't drafted with this purpose in mind and is too
vague
. Phase 1 may define requirements on policy that are guiding
principles, to be supported through policies to be defined in detail during
Phase 2
PR-D30-R05:
The requirement for a third country to ensure an adequate level of data
protection was further defined by the CJEU in Schrems.It also indicated that
the wording 'adequate level of protection' must be understood as "requiring
the third country in fact to ensure, by reason of its domestic law or its
international commitments, a level of protection of fundamental rights and
freedoms that is essentially equivalent to that guaranteed within the
European Union by virtue of the Directive read in the light of the Charter"
pg.10
. Source:
<http://ec.europa.eu/justice/data-protection/article-29/documentation/opinio
n-recommendation/files/2016/wp238_en.pdf> Opinion 01/2016 on the EU-U.S.
Privacy Shield draft adequacy decision of the Article 29 WP 238
. What does third country mean in this context? Applies to forward
transfer of data from country which the data was collected or the subject of
the data
. It is almost impossible to transfer data while guaranteeing
constitutional protections without treaty - becomes more aspirational
. Should requirement be higher level statement such as RDS policy
should allow contracted parties to comply with applicable law?
. Should requirement state the implicit requirement that the RDS
should provide adequate data protection?
4) Action items & Next meeting
Action: Staff to distribute notes from today's meeting for further use in
drafting WG recommendations. All WG members to review these materials to
prepare for deliberation in our next meeting.
Next meeting date: Tuesday, 22 November 2016 at 17:00 UTC
Meeting Materials:
. RDS PDP WG Wiki: <https://community.icann.org/x/rjJ-Ag>
https://community.icann.org/x/rjJ-Ag
. WG Email Archive: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/>
http://mm.icann.org/pipermail/gnso-rds-pdp-wg
. Phase 1 Documents: <https://community.icann.org/x/p4xlAw>
https://community.icann.org/x/p4xlAw
.
<https://community.icann.org/download/attachments/62392116/RDS%20PDP%20WG%20
Approach%20for%20Consensus%20-%2027%20October%202016.docx?version=1&modifica
tionDate=1477710631000&api=v2> Approach to reach consensus during Phase 1
.
<https://community.icann.org/download/attachments/62392116/PRSpreadsheets-D5
-CodeAOnly-NoDependencies.pdf?version=1&modificationDate=1477710647000&api=v
2> PRSpreadsheets-D5-CodeAOnly-NoDependencies [PDF] and
<https://community.icann.org/download/attachments/62392116/PRSpreadsheets-D5
-CodeAOnly-NoDependencies.xlsx?version=1&modificationDate=1477710695000&api=
v2> [XLS]
.
<https://community.icann.org/download/attachments/62392116/ICANN57-RDS-PDP-W
G-Slides-Draft8.pptx?version=1&modificationDate=1478144990000&api=v2>
ICANN57-RDS-PDP-WG-Slides.pptx
.
<https://community.icann.org/download/attachments/62392116/Initial-Deliberat
ion-List-v2.pdf?version=1&modificationDate=1478231277181&api=v2>
Initial-Deliberation-List [PDF] and
<https://community.icann.org/download/attachments/62392116/Initial-Deliberat
ion-List-v2.docx?version=1&modificationDate=1478231349204&api=v2> [DOC]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20161104/64edc510/attachment.html>
More information about the gnso-rds-pdp-wg
mailing list