[gnso-rds-pdp-wg] Notes and Action Items - RDS PDP WG F2F Meeting - 28 June 2016

Lisa Phifer lisa at corecom.com
Thu Jun 30 13:24:15 UTC 2016


Dear all,

 

The following notes summarize key points of discussion, agreements, and
action items from the RDS PDP WG F2F meeting on 28 June at ICANN56. All WG
members – especially those who were unable to attend the meeting - are
asked, prior to providing their input, to review the official transcript and
recordings of the meeting:

 

·       Transcript GNSO RDS Part 1 28 June Helsinki
<http://schd.ws/hosted_files/icann562016/f0/Transcript%20RDS%201%2028%20June
%20Helsinki.pdf> 

·        Transcript GNSO RDS Part 2 28 June Helsinki
<http://schd.ws/hosted_files/icann562016/29/Transcript%20GNSO%20RDS2%2028%20
June%20Helsinki%20%5B1%5D.pdf> 

·       Transcript GNSO RDS Part 3 28 June Helsinki
<http://schd.ws/hosted_files/icann562016/cd/Transcript%20GNSO%20RDS3%2028%20
June%20Helsinki.pdf> 

·        Adobe Connect Recording Multimedia Session Recording
<https://icann.adobeconnect.com/p3qr9nmm42k/>  Part 1

·        Adobe Connect Recording
<https://icann.adobeconnect.com/p3ty476eer8/> Multimedia Session Recording
Part 2 

·        English Audio
<http://audio.icann.org/meetings/hel56/hel56-OPEN-2016-06-28-T0425-hallb-IC3
By7pjcu7tl0hdSj9fNZR36HW1oLO7-en.m3u> Session Recording Part 1

·        English Audio  <http://stream.icann.org:8000/hel56-hallb-en.m3u>
Session Recording Part 2 

 

In particular, refer to Transcript Part 3 (Adobe Connect Session Recording
Part 2) for significant discussion of how the WG will begin deliberation to
reach consensus. After brief initial deliberation on a few possible
requirements, participants agreed to revamp the proposed approach by
starting with a statement of purpose and use cases to establish a foundation
for deliberation on specific possible requirements. This proposed approach
will be circulated to the full WG for comment by 7 July.

 

1.            Introductions

 

·        WG members in attendance introduced themselves. 

·        No SOI updates were noted.

 

2.            PDP Work Plan: Accomplishments and Status

 

·        Current Work Plan: https://community.icann.org/x/oIxlAw

·        Reviewed WG progress on recent tasks

o   Task 7e: Outreach #1 – Review & Analyze inputs using Comment Review Tool
(16 June) – Task completed at this meeting (see agenda item 3 below) 

o   Task 9c: Outreach #2 – Request additional Possible Requirements (11-27
June) – Additions received from RySG, response with no further inputs at
this time received from NCSG, GAC expects to respond by end of July. 

o   Task 11: Decide how and when the WG will try to reach consensus – Task
continued in this meet (see agenda item 3 below)

·        Approved Work Plan was relayed to GNSO Council by liaison Stephanie
Perrin to inform them of this WG’s initial plans.

·        Timeline for completing phase 1? Task 11 will determine approach to
reaching consensus during phase 1; this will help us get a better handle on
timeline, but phase 1 will take a while.

·        If an SO/AC/SG/C doesn’t have any input at this point, it would
still be helpful if they indicate this now to facilitate planning of WG
activities.

 

3.            PDP Work Plan: Next Steps and Working Session

 

Task 7f: Outreach #1 – Finalize Comment Review Tool

 

·        The WG reviewed the draft Comment Review Tool:
 
<https://community.icann.org/download/attachments/59641480/Outreach%20%231%2
0-%20Public%20Comment%20Review%20Tool%20-%2025%20June%202016%20.docx?version
=1&modificationDate=1467016057000&api=v2> Outreach #1 - Public Comment
Review Tool - 25 June 2016 .docx

·        Q2-RySG – Add text under Action Items: WG members should be tasked
with extracting possible requirements from the RySG comments provided here

·        Responses that refer to deliberating upon possible requirements
should note that the WG is currently developing a phase 1 process for
deliberating on all possible requirements

·        How will the GAC be engaged in this PDP so that concerns are not
raised at the end of the process? 

•                          It is important to address any differences
between PDP advice and GAC advice throughout the PDP process, so that there
is no need for board to consider over-riding policy recommendations. 

•                          Steps have already been taken to facilitate this
– for example, the GAC has provided input through outreach #1 – and it is
important that input is taken into consideration by the WG. We have an
active liaison to the GAC PSWG (Greg Mounier) to facilitate on-going
interaction. There may still be situations where the GAC does not agree with
GNSO consensus policy but hopefully there will be fewer with early/on-going
engagement.

·        To answer the question of is a new RDS needed we need to take into
consideration the outcome of parallel WHOIS improvements – it is part of
this WG’s charter to do so. If improvements haven’t yet been implemented,
may need to reflect any assumptions in the WG’s initial report.

·        Q2-GAC – Vicky Scheckler volunteered to extract possible
requirements from the GAC’s suggested inputs. Adjust action item text to
reflect this.

·        Noted that some EWG member statements and blogs still need
volunteers to extract possible requirements. Ayden Ferdeline and Stacie
Walsh volunteered to do so.

·        Q4-SSAC response – Revise to indicate that the WG is in the process
of gathering possible requirements to help define the problem.

·        Q4 SSAC response – A Problem Statement drafting team was formed to
help develop a very concise and tight problem statement, drawing from the
Issue Report and Charter. This should be a conceptual problem statement; it
should not redefine the issue or charter or go into details and/or
solutions. This drafting will be done in parallel to ongoing work. 

·        Volunteers for this drafting team are: 

•                          Stephanie Perrin

•                          James Gannon. 

•                          Alex Deacon 

•                          Nick Shore 

•                          Shane Kerr 

•                          Ayden Federline 

•                          Susan Kawaguchi (leadership liaison) 

•                          Mark Svancarek 

•                          Daniel Nanghanki  

•                          Marina A. Lewis 

·        With respect to RDAP, this WG may recommend that RDAP be used to
implement policy, but any policy needs requiring RDAP extension will need to
be relayed to the IETF for consideration.

 

Action Item #1: The sign-up sheet will be updated to reflect the following
volunteers will review these documents to extract possible requirements:

 

·        Additional GAC-suggested documents – Vicky Sheckler

·        Dissenting Report from Stephanie Perrin – Ayden Ferdeline

·        Where Do Old Protocols Go To Die? by Scott Hollenbeck – Stacie
Walsh

·        Building a Better WHOIS for the Individual Registrant – Stacie
Walsh

 

Action Item #2: Staff to update draft Comment Tool to reflect noted change
and circulate to WG for final approval within two weeks.

 

Action Item #3: Staff to create a mailing list for the Problem Statement
drafting team. Concise Problem Statement to be drafted by team for WG
consideration.

 

Task 9e: Outreach #2 - Incorporate additional Possible Requirements

·        Possible requirements from Cross-Community RDS session were posted
to mailing list, see:
 <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/2016-June/000933.html>
http://mm.icann.org/pipermail/gnso-rds-pdp-wg/2016-June/000933.html

·        All additions suggested during Cross-Community RDS session to be
added to the next draft of the WG’s ongoing Possible Requirements List after
confirming with transcript

·        Also expect to incorporate any additional Possible Requirements
gathered during Outreach #2, as well as those to be extracted by WG members
from documents identified during Outreach #1 (see above) and suggested
during this F2F meeting

·        Additional possible requirements that are not already on the list
will be added to Draft 4

·        Draft 4 will be produced after Draft 3 triage effort has been
completed

·        For a description of triage goals, see Task 11 approach

Finalize Task 11: Decide how and when the WG will try to reach consensus 

 

·        The proposed approach to reach consensus (v12) was reviewed by the
WG, see:
 
<https://community.icann.org/download/attachments/59648535/Possible%20approa
ch%20to%20consensus%2024%20Jun%2016%20WG%20v12%20clean.docx?version=1&modifi
cationDate=1466823237000&api=v2> Possible approach to consensus 24 Jun 16 WG
v12 clean.docx (24 Jun 2016)

·        There were no additional questions or concerns raised on items 1 &
2

·        Questions were raised on item 3 (where to start deliberation) on
Chuck’s proposal to start by identifying a subset of possible requirements
“that would apply to the RDS in all circumstances“

·        Chuck explained that the aim of item 3 was to commence discussions
today on any possible requirements that may apply in all circumstances,
regardless of users, jurisdiction, etc.

·        Should the WG consider sending regular questions to the GAC via the
PSWG on some of the constitutional or data protection requirements that may
apply in the different countries? Could help with the research on this
topic. This should not hold up deliberations of the WG. Is that information
needed now, if we design a system that respects the laws of each land, that
would need to be dealt with in the implementation phase. The possible
requirements could say something like 'the system would allow for respecting
the laws of each country’ which would translate in the implementation phase
to a system that would accommodate this and where this information will be
needed. 

·        Should be cognizant of possible legal requirements when developing
possible requirements, but recognize that these may be dealt with in the
implementation phase. 

·        Are there certain requirements that would apply in all
circumstances and which the WG would agree with? Meeting participants
brainstormed this question with the following suggestions:

o   RDS needs to comply with international standards and legislation - for
example UN Law on corporate social responsibility which includes a whole
chapter on human rights, International convention for data protection &
privacy which has been signed by all Council of Europe countries and Turkey
and Uruguay. 

o   Registration data collection needs to reflect necessity,
proportionality, & be purpose bound - 108 countries that currently have data
protection / privacy legislation which are expressed as principles. This may
not be a universal requirement as it is not necessarily subscribed to by all
countries. 

§  Discussion: Does this apply in all circumstances? At high level yes, but
would need more definition on what it means in practice. 

o   Must prevent leaks of RDS information 

§  Discussion: If all information were publicly available then would no
leaks be possible? No, there is some information related to the system
itself which you do not want to see public, for example, ID and password or
information enabling corruption of the database. Change to: Ensure system
security and secure administration. May need to provide examples to broader
community. May need to differentiate between system and user security?

o   RDS needs to be a properly-designed secure, stable, and resilient system

o   Registration data elements must include domain name and its status

o   RDS needs to be resilient against single point of failure (e.g., Backup
of information)

o   RDS must provide the name of the registrant, and a physical address and
email address for the registrant that should be accurate and contactable

o   RDS needs to collect registrar name

o   RDS needs to be accessible for purposes identified

§  Discussion: Elements of security and administration would need to be in
place to accomplish this (see also earlier requirements). 

o   RDS needs to include name server information

§  Discussion: Does this need to be in the RDS? The information is already
available in the DNS and you do not need a name server to registrar a domain
name. 

o   RDS needs to include standard information that is required for
registrars to meet contractual obligations such as domain name registration
transfers

o   RDS needs to support IDNs

o   RDS needs to avoid out of sync information between different systems
that may interact or contain the same information (e.g. DNS and RDS) 

o   RDS needs informed consent - Individual consent concerning information
that is collected as well as options for redress

·        After the WG discussed the above possible requirements, the
question was asked:
Should the WG first deal with the policy and then system requirements? If
so, how?

·        It was suggested that the WG start by examining use cases - talk
about users, their purposes, the data involved, and privacy impacts at a
principle level, separate out the principles from the actual data to be
collected and the system requirements. Continue to refine each use case
until enough use cases have been considered to understand the purpose of
registration data. 

·        Expert WG took a similar approach, by starting with use cases. 

·        The WHOIS 2007 Task Force also examined use cases, should consider
those as well.

·        Attendees agreed that there was a need to find an approach that is
efficient for deliberating on possible requirements and discussed whether
the use case approach would facilitate this. 

·        How to ensure that a sufficient set of use cases are identified?
Does the approach presuppose that information currently collected will
continue to be collected? Would the use case approach prevent starting from
a clean slate? 

·        Note that use cases examined could include those that shouldn’t be
a valid use case under a next generation RDS. Need to be careful on how use
cases are defined - shouldn’t be about specific business models. 

·        Consider splitting use cases to examine both user and technical
requirements – but need to be careful not to start designing the system.
Need use cases to focus on policy requirements, which may include some high
level technical requirements. 

·        Need to consider possible constraints on the use of the data - in
some jurisdictions data can also be used for previously agreed upon cases

·        Use cases are not a one-to-one relationship to a solution that is
then implemented. Broad concepts will come forward from use cases such as
cases that could be supported by gated or non-gated access. The same
solutions may apply to other uses cases, even those that may not have been
identified yet. 

·        Do we need to come to rough consensus on “purpose” before looking
at use cases? 

·        Starting with “purpose” is key to making progress.

 

Action Item #4: Circulate EWG statement on purpose that was originally
drafted by Stephanie as an example and possible starting point for this WG
to answer the question of “What is the purpose of collecting, maintaining,
and providing access to registration data?”

 

·        Avoids repeating work that has already been done - that doesn’t
mean that work is accepted as is, but at least it provides a starting point.


·        Identifying use cases does not mean endorsing that case - it may
actually do the opposite (e.g. not a use that the system should facilitate).
A spectrum of use cases (from permissible to illegal) were also identified
as part of the EWG’s analysis of use cases.

·        There was no disagreement among meeting participants to approach
deliberations by beginning with a statement of Purpose. 

 

Action Item #5: All WG members are asked to review F2F meeting recordings
Part 2 and/or transcript Part 3 to ensure that all WG members are up to date
with the discussions that took place in Helsinki.

 

Action item #6: Leadership team to update Task 11 item 3 to reflect
direction given in this meeting to circulate the EWG report’s Purpose
statement as an example and pursue use case methodology as a possible
starting point prior to deliberating upon individual possible requirements.

 

Action item #7: After listening to recording or reviewing transcript of F2F
discussion of Task 11, WG members are asked to review/comment on updated
Task 11 approach by 7 July, in preparation for further discussion and
finalization during the 12 July WG call.

 

4.            Confirm Action Items, Next Steps, Next Meeting

 

·        No WG meeting week of 3 July

·        Next WG meeting will be 12 July 16.00 UTC

·        Next steps and call agenda to be circulated to WG mailing list

 

Meeting Materials:

RDS PDP WG Wiki: https://community.icann.org/x/rjJ-Ag

WG Email Archive: http://mm.icann.org/pipermail/gnso-rds-pdp-wg

Work Plan: https://community.icann.org/x/oIxlAw

SO/AC/SG/C Outreach and Inputs: https://community.icann.org/x/pYxlAw

Phase 1 Documents: https://community.icann.org/x/p4xlAw, including

Initial List of Possible Requirements (10 June 2016)

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160630/3814f59e/attachment.html>


More information about the gnso-rds-pdp-wg mailing list