<html>
<body>
<font face="Arial, Helvetica">Dear all,<br><br>
Below please find notes and action items from today's RDS PDP WG call.
<br><br>
A redline documenting the output of agenda item 3 (statement of
purpose) will be circulated separately and also posted on the wiki page
linked below for your review and comment.<br><br>
Please also note Action Item #1 below: We are still seeking additional
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 11/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:
<a href="https://community.icann.org/x/JRa4Aw" eudora="autourl">
https://community.icann.org/x/JRa4Aw<br><br>
</a></i>1. Roll call/SOI update<br>
· Roll call will be taken from
AC<br>
· Please remember to update
your SOI<br><br>
2. Call for volunteers to extract possible requirements from new EU
GDPR<br>
· Requested volunteers to help
Greg Shatan complete extracting possible requirements from GDPR. Greg has
good start on this but could use help from WG members to complete this
task.<br>
· Volunteers: Marina Lewis<br>
· Still welcome additional
volunteers<br><br>
<b>Action #1:</b> Marina Lewis, Greg Shatan, and Lisa Phifer to work
together (with any additional volunteers) to complete GDPR task.<br><br>
<br>
3. Continue work on statement of purpose (see latest version,
below), starting with section: <i>Specific Purposes for Registration Data
and Registration Directory Services<br>
</i>· On #1, no strong feelings
to reword as framing statement rather than purpose<br>
· Regarding lifecycle, not
every TLD has the same lifecycle. SSAC spoke to this in SAC054 by
identifying events that may or may not occur in the lifecycle of any
specific TLD; however, the lifecycle describes the overall set of events.
Note that future new gTLD rounds may include TLDs with different
lifecycles as well. Additional text proposed to note that there may be
some variations in lifecycle. Every domain has a lifecycle - the RDS
tells you about data associated w that domain's lifecycle.<br>
· On #2, does the statement
include too much at this point (e.g., implying there will be controlled
rather than unlimited access)? Noted that one possible policy to manage
access is to allow unlimited access - that is, an open management policy.
Options considered: "manage access to information" vs
"provide information about" - proposed resolution is
"manage access to and/or provide information about..." - is the
purpose providing information, based on some agreed-upon rule set (that
is management is not the purpose). See redline for final proposed text
encompassing this.<br>
· On #2, should registries be
included? The registry is implicit in the TLD regardless. Removed for now
- can always be added<br>
· On #2, is omission of
information about registrants intentional? No, added
"registrants" to list.<br>
· On #3, is this necessary
given #2 as providing information - is contact a use case? Can you enable
contact with (for example) a registrant without providing information
about that registrant? Overlapping but somewhat distinct purpose - RDS
may have more than one purpose.<br>
· On #3, use same phrasing as
#2 - "agreed policy"<br>
· On #3, agree this purpose
should include both (1) identifying domain contacts and (2) facilitating
contact with those contacts <br>
· On #3, agreed to not listing
types of contacts but allowing them to be defined by "agreed
policy"<br>
· On #3, agreed to replace
"facilitate contact with" by "facilitate communication
with" domain contacts, based on agreed policy<br>
· On #4, noted that
considerable WG list discussion has occurred regarding
"accuracy" - To be discussed but for the moment, focusing on
the rest of this purpose... [resolution: move accuracy to separate
purpose item, to be discussed]<br>
· On #4, again, use same
phrasing as #2 - "agreed policy"<br>
· On #4, is this purpose
redundant with #2 - "To release data that may not be otherwise
publicly available, under specific and explicit conditions, based on
agreed policy" - is this different than #2, "To provide
information about...based on agreed policy." Is the distinction
"may not be otherwise publicly available" necessary or add
value to the statement of purpose. Agreed to combine #2 and #4 in next
draft, moving [accuracy] to another separate purpose for further
discussion.<br>
· On #2, add "domain
contacts" to list of information provided (either in addition to or
instead of "registrant")<br>
· With regard to accuracy,
comments included the following:<br>
· Shouldn't the RDS be an
authoritative and accurate source of information? Is this a purpose of
the RDS? Should it be a separate and distinct purpose?<br>
· SAC 055:RecommendationThe
SSAC recommends that the Registration Data Policy Committee’s charter
should include the requirement to define “accurate registration data” and
provide guidance as to how to achieve it.<br>
· A big part of building trust
in an authoritative database is having some comfort that the data is
accurate. in light of this, part of the purpose of the RDS should be to
have accuracy to build such trust<br>
· Accuracy is a purpose of the
way data is collected. it is also a purpose of the transmission mechanism
used by RDS (RDAP, port 43 or whatever we choose). but accuracy is not a
purpose of the RDS itself.<br>
· Don't want to preclude the
possibility that the RDS runs proactive checks on the accuracy of data -
which isn't about providing access to the data per se<br>
· Considering possible text for
a new purpose. One potential is "A purpose of the RDS is to provide
an authoritative source of accurate data." But can the RDS ensure
accuracy of data? Having a purpose of having accurate data is not the
same as certifying accuracy.<br><br>
<b>Action #2:</b> Staff to circulate call results as redline. All WG
members to review redline and submit any further feedback on-list before
next WG call.<br><br>
4. Confirm next meeting date: Wednesday 19 October at 05:00
UTC<br><br>
<br>
<b>Meeting Materials:</b>
<a href="https://community.icann.org/x/JRa4Aw" eudora="autourl">
https://community.icann.org/x/JRa4Aw<br>
</a></font></body>
</html>