[gnso-rds-pdp-wg] Notes from today's RDS PDP WG meeting

Wed Sep 21 06:33:40 UTC 2016

Dear All,

Please find below the notes from today’s RDS PDP WG meeting. Please take particular note of the action items.

Best regards,

Marika

Notes 21/9 – RDS PDP WG Meeting

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/C4xlAw.

1. Roll Call / SOI

2. Continue discussion on Statement of Purpose

   Review and comment on draft purpose statement

·         Posted at https://community.icann.org/x/XQK4Aw

·         Does this statement presuppose that access will be granted to registration data? That is, taking off the table the possibility that there might not be access to the data? Distinction between a data service and a directory service - this seems to imply there would be a directory service to enable access.

·         Proposed edit: delete registration data from the first sentence, leaving only "This statement is intended to define the purpose of a Registration Directory Service (RDS) for generic TLD domain names."

·         In second paragraph, proposed edit to delete "and services related to them" - for example, a service such as WhoWas might be going beyond the scope of an RDS or the core purpose.

·         Alternatively, add ", if any" after services. Place phrase in brackets: "[and services related to them, if any]"

·         Is there an assumption that a registries are thick (current consensus policy)? Noted that RWhoIs is core to any thin registry (although the RDS shouldn't necessarily make a distinction between thick or thin registries)

·         With regard to consensus policy, there can be changes proposed by this WG which would affect future consensus policy (and the RAA), if approved by the GNSO Council and adopted

·         Does this cover (1) all data collected by registrars, or (2) just the data collected in the relationship between registrars to registries and in the relationship between registrars/registries and ICANN? (the latter #2)

·         Should we assume that privacy/proxy works the same way as now? No, P/P policies are a moving target (PPSAI is now in IRT) and will evolve between now and when RDS policies are proposed/adopted. The issue with privacy/proxy is whether or not we write the policy to say that we have to know who the registrant is or whether it is an access point.

·         Comment from last call, reflected in discussion below: "First, having a list of purposes / accommodating multiple purposes. Second something that can be communicated readily to registrants and others. And third, something that you can use to establish a relationship between the stated purpose and a proposed or actual use."

·         Under overall goals, this should be talking about access to repositories of registration data

·         Proposed addition to overall goals: statement that could be readily communicated to registrants, statement that establishes a relationship between purpose and the RDS, statement that may contain multiple purposes. [Note these are currently listed under prerequisite conditions v, vi -- proposal is to move those under Overall Goals, tweaked appropriately]. For example:

·         d. To communicate purpose(s) of the RDS to registrants (and others)

·         e. To establish sufficient relationship between the purpose(s) and the use(s) of the RDS

·         Questions raised as to whether these are goals for the statement of purpose, or goals for the purpose of the RDS itself

·         Regarding paragraph 2, the first sentence combines (1) the purpose of registration data and why it's collected, and (2) the purpose of a system that allows access to it.

·         Possible alternative: "the system that collects, maintains, and provides or denies access to some or all of those data elements"

·         Due to data protection laws, do we need to be careful to state clearly the purpose of collection, access, etc - is that our goal here? Are we getting into the weeds where we don't have to? 

·         One of the things we're trying to accomplish is to create a legal basis for compliance with data protection laws - is that our job or is that something that happens later by legal review?

·         We need to be conscious of data protection restrictions and requirements, so that proposed policies don't end up being illegal//non-compliant.

·         Shouldn't privacy issue be discussed separately, especially in the context of sale of data?

Action Item #1: Staff to apply above edits as redline for WG review and discussion on the full WG list, noting with comments that proposed move was not resolved, as well as data protection law question above.

3. Review Draft 4 of triaged possible requirements list

·         Discuss possible deletion of flagged PRs (those marked "??")

·         Discuss WG feedback on phase, code, and keyword mappings

·         Identify essential missing inputs (if any) and plan to include them

Action item #2: WG members to review latest version of triaged possible requirements, including specific questions identified, in order to commence deliberations. 

Action item #3: Staff to circulate possible deletion of flagged PRs to mailing list to encourage input by WG members ahead of next week's meeting

Action item #4: For those WG members that have outstanding requirements to review documents for possible requirements, please do so as soon as possible or indicate that you are no longer able to do so, so that these can be assigned to someone else. See https://community.icann.org/x/shOOAw.  

4. Confirm next meeting (Tuesday 27 September at 16.00 UTC)

Marika Konings

Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) 

Email: marika.konings at icann.org  

Follow the GNSO via Twitter @ICANN_GNSO

Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160921/e674d546/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4619 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160921/e674d546/smime.p7s>