<html>
<body>
<font face="Arial, Helvetica">Dear all,<br><br>
Below please find notes and action items from today's RDS PDP WG call. A
redline documenting the output of agenda item 4 below will be circulated
separately and also posted on the wiki page linked below.<br><br>
Please also note Action Item #1 below: We are seeking 2-3 volunteers to
assist with extracting possible requirements from the GDPR. If you are
interested in helping with that task, please reply to the list or contact
staff.<br><br>
Best, Lisa<br><br>
<br>
<b>Notes 4/10 – RDS PDP WG Meeting<br><br>
</b><i>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/tA_4Aw<br><br>
</i>1.&nbsp; Roll call/SOI update<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Roll call will be taken from
AC<br><br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Please remember to update
your SOI<br><br>
2.&nbsp; Brief Updates: status update, ICANN57<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Submitted meeting request,
now finalizing schedule for ICANN57<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Update on all things WHOIS
has been identified as a high-interest topic - this would include work of
RDS PDP WG. The GAC will take the lead in organizing and planning this
high-interest topic session.<br><br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status update was distributed
to WG mailing list and posted to wiki to help inform others, including
the Board, of this WG's progress<br><br>
3.&nbsp; Call for volunteers to complete pending PR assignments:<br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a.&nbsp; Review of codings - a
number of volunteers have come forward (Fabricio Vayra, Vicky Schlecker,
Rod Rasmussen, Susan Kawaguchi and Beth Allegretti) who will work with
staff to review the mapped codes reflected in Draft 4 of the Possible
Requirements list. Hope to complete work next week. <br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.&nbsp; Outstanding possible
requirements from new EU GDPR (Final Regulation (EU) 2016/679 of the
European Parliament and of the Council (27 April 2016): Greg Shatan has
started on this but would appreciate assistance in extracting PRs from
this large key input document.<br><br>
<b>Action Item #1:</b> WG members asked to volunteer to assist with GDPR
possible requirements; seeking 2-3 volunteers to assist Greg with
completing this task for inclusion in the WG's Possible Requirements
List.<br><br>
4.&nbsp; Continue work on statement of purpose<br><br>
<u>Overall comments: <br><br>
</u>·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hollenbeck already
resolved<br><br>
<u>Title comment: <br>
</u>·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Should collection be
included in this statement of purpose? Does it fall within this WG's
charter since data is collected by the shared Registry System (based on
EPP)?<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; What Registries collect for
the purpose of running their business is not necessarily our business,
but what is relayed to the RDS is.<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; As long as something is
mandated by ICANN in its accreditation of registrars, then it is part of
the policy framework to be addressed by this WG. You can't determine
policy for privacy unless it includes the collection instrument.<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The RDS itself doesn't
collect data; it provides access to data already collected. The protocols
don't talk about data collection.<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Problem is using terms
without defining them. Whatever is in the RDS will be a subset of what is
actually collected.<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Terminology difference
between RDDS and RDS - RDDS includes data and directory services, while
RDS doesn't - was this distinction intended to narrow the scope of this
PDP to directory service?<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the scope is just
directory service, then it does not include the shared registration
system that is based on existing protocols - changing that would require
mapping from existing system to any new system<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note that EWG considered this
and recommended a new approach for collecting and updating contact data
that would collect contact data directly from those contacts, separate
from DN registrations, and then be able to reuse those contacts for
registrations<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For now, leave title as-is;
this doesn't need to limit what the WG addresses<br><br>
<u>Intro paragraph comments:<br>
</u>·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Accept edits to first
paragraph<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For second paragraph,
distinction intended is between purposes of users and actions, not
purposes of data elements - trying to manage access to information about
a domain name registration; this relates to purpose of access for
specific users, not necessarily purpose of managing access. Resolution is
to delete affected sentence.<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Delete residual reference to
prerequisite conditions - now Goals for each RDS Purpose.<br><br>
<u>Overall Goals comments:<br>
</u>·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Goal a) - must be
considered in conjunction with proposed deletion of Goals b)-e)<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Maybe Overall Goals were
useful to frame the conversation but may not be useful to include in
statement of purpose itself.<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note there was considerable
discussion about placing several goals in the overall goals or goals for
each purpose - deleting from overall goals shouldn't prevent keeping some
(e.g., d) and e) and f) ) as goals for specific purposes<br><br>
<u>Goals for each Purpose comments:<br>
</u>·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note above discussion of
keeping d) and e) and moving them back to this section - want to retain
these criteria for each specific purpose that would then be listed in the
last section<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Goal ii) - Regarding generic
top level domain names - this should also apply to second level etc.
domain names under gTLDs. Refer instead to registration data associated
with gTLDs<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Goal iv) - Does this leap
ahead to needing an RDS without articulating a rationale for collecting
&amp; maintaining registration data? Proposed resolution is to add
&quot;, if there is one&quot; - but there will be a rationale, the
question is what the rationale is for (to be determined by WG). Agree not
to delete bullet at this time.<br><br>
<u>Specific Purpose for RDDS comments:<br>
</u>·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #1 - Strike &quot;to
enable management...&quot; because that's just one use case, yet to be
deliberated upon as a requirement<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #1 - consider revising to
framing statement rather than statement of purpose - left open, not
agreed yet<br>
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #3 - proposed renumbering of
3a) and 3b) as 3 and 4 to be applied to next draft<br><br>
<b>Action Item #2:</b> Staff to produce and distribute a redline that
reflects today's call agreements and resolutions, including open
items<br><br>
5.&nbsp; Confirm next meeting date: Tuesday 11 October at 16:00
UTC<br><br>
<b>Meeting Materials:</b>
<a href="https://community.icann.org/x/tA_4Aw" eudora="autourl">
https://community.icann.org/x/tA_4Aw<br>
</a></font></body>
</html>