[gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from Next-Generation RDS PDP WG Call - 20 September 2017
Amr Elsadr
amr.elsadr at icann.org
Wed Sep 20 18:24:27 UTC 2017
Dear Working Group Members,
Please find the action items and notes from this morning’s WG call below. The action items, notes, meeting documents and recording are also available on the meeting’s wiki page here: https://community.icann.org/x/ZGfwAw. The transcripts of the call will be posted on the same page, when they become available.
Thanks.
Amr
Action Items:
1. Staff to add the 2 WG agreements resulting from the 12 September poll to the working document
2. Staff to distribute drafting team output on Original Registration Date to WG mailing list; all WG members invited to review and comment
3. Staff to prepare a poll to confirm support for the proposed WG agreement reached in this call; all WG members are encouraged to participate in the poll by COB Saturday23 September
Notes:
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 here: https://community.icann.org/x/ZGfwAw
1) Roll Call/SOI Updates
* No updates to SOIs declared
2) Apply results of 12 Sept WG call to working document
* Results of the 12 September poll:
* Annotated Poll Results: https://community.icann.org/download/attachments/66086756/AnnotatedResults-Poll-from-12SeptCall.pdf
* 80% agreement that the RDS must support Registrant Postal Address data elements (Registrant street address, city, state/province and postal code), 20% disagree
* 92% agreement that the RDS must support Registrant phone + phone extension, 8% disagree
WG Agreement: The RDS must support Registrant Postal Address data elements: Registrant Street Address, City, State/Province, and Postal Code.
WG Agreement: The RDS must support Registrant Phone + Registrant Phone Ext (extension) data elements.
ACTION ITEM: Staff to add the 2 WG agreements resulting from the 12 September poll to be added to the working document
3) Review recommendations from Drafting Team on Original Registration Date
* Concern of the Drafting Team with the Original Registration Date is that this is data that had not been previously collected - might present as false positives in the future
* If the data hasn't been collected, there is no way to know if the name has been deleted and re-registered
* If this feature is turned on, the earliest recorded registration date would present as the Original Registration Date, which would be a potentially misleading data element
* Team determined that it would be valuable to know if there was a previous registration of a domain object
* Team recommending instead that known occurrences of a domain object's registration be recorded and counted
* Counter would determine number of previous occurrences, or result in an unknown query result if there are no indications of previous registrations - no negative results should be counted, which may be due to unknown previous registrations - count should not be zero if no occurrences of previous registrations are counted, but instead should indicate “unknown”
* Benefit of counter would be to provide an indication of possible abuse, should the count increase suddenly over a short period of time
* Other counters that the Team has discussed included a count of domain transfers, or transfers between registrars - no consensus was reached on whether to include recommendations on them
* WG will not discuss the proposal during this call, but will revisit it when resuming discussion on data elements - WG members may discuss the proposal, and ask questions on the WG mailing list
* Team work and results encouraging as a technique in which a small group of volunteers can discuss a topic in detail, and return to the WG with draft text and rationale for full WG consideration over a 2-3-week period of time
ACTION ITEM: Staff to distribute drafting team output on Original Registration Date to WG mailing list; all WG members invited to review and comment
4) Resume deliberation on Purposes for gTLD registration data (see handout)
a) Charter Question: For what specific (legitimate) purposes should gTLD registration data elements be collected?
b) Review previous WG agreements on purposes for collection of data in the MPDS
* Handout: https://community.icann.org/download/attachments/66086756/RDSPDP-Handout-For20SeptCall-v2.pdf
* List of previously agreed to purposes for collection of data elements in the MPDS listed with related use cases in 20 September Call Handout on slides 3-5 (also listed without the use cases on slide 2)
* Previous WG agreement on public access to the MPDS - are previous WG agreements the combination of the agreements on purposes to collect the data elements in the MPDS, as well as public access to them?
* Concern raised over the previously agreed-to purposes for collection - these purposes may be appropriate for ICANN to disclose (provide access to) the data elements, but not for collection
* Purposes for which ICANN can collect data should be limited to ICANN's limited mission – perhaps ICANN should not be collecting data for the several purposes listed, but may display/provide access to data collected for legitimate purposes identified?
* Independent legal analysis (expected to be delivered soon) will provide information that may be useful to assess the appropriateness of ICANN collecting data elements for the agreed-to purposes
* The ICANN’s remit goes beyond support of the DNS - It's mission and values include the stable and secure operation of DNS, Preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet, and so forth
* The purpose limitation principle states that personal data collected for one purpose should not be used for a new, incompatible, purpose.
* Some of the data elements in the MPDS are generated rather than collected, and play a role in the security and stability of the operation of the DNS
c) Confirm updates to previous WG agreements on MPDS, for access
* Are the agreed-to purposes for collection of data elements in the MPDS considered legitimate purposes for access to the MPDS? - Need to align purposes for collection with WG agreements for MPDS public access
* General agreement that there are legitimate purposes for collecting MPDS - need to enumerate which purpose(s) they are
* Specifically, we already have several agreements on this: WG Agreement #2) Every data element in the MPDS should have at least one legitimate purpose, #3) Every existing data element in the MPDS does have at least one legitimate purpose for collection, and #23) RDS policy must state purpose(s) for public access to the MPDS
* Informal show of hands in the AC room on purposes for collection of data elements in the MPDS being legitimate purposes for access to the MPDS: 6/19 agree, 2/19 disagree
* Stated reason for disagreement: I'm putting disagree because I'm not sure it's that simple. I think we need to consider who has access for these purposes and under what circumstances. I don't think all these purposes would apply to unlimited public access.
* When considering the data elements that would be included in the MPDS, they were individually mapped to the legitimate purposes agreed-to for collection of data elements in the MPDS in order to identify at least one for each data element that would provide applicability for public access
* It is unclear how some of the purposes listed for collection of data elements in the MPDS (for example, legal action) are practically relevant without access to registrant data, which is not included in the MPDS. In other words, the purpose cannot be satisfied by only MPDS data elements, even if it makes use of (some) MPDS data elements.
* The MPDS needs to be public, so there is no way to prevent the use of this data for all the purposes listed for collection, however, the purposes themselves are not necessarily legitimate purposes for collection and access to the MPDS
* The purposes listed are not necessarily relevant to purposes for access to the MPDS, which is already publicly accessible, but may be more appropriate when considering purposes that may warrant requiring gated access to data beyond the MPDS
* All that is required is to identify one reason for collection and display of a public data element – example: the nameserver data must be public (minimum requirement), or the domain name would not work (although this is a DNS and not RDS requirement) – would other purposes for nameserver be irrelevant?
* WG Leadership Team to revisit the approach of use of these purposes for collection/access to the MPDS
* Disagreement between WG members on the call on whether data elements in the MPDS can be considered PII, or not
* Note WG Agreement #20 on access to the MPDS: gTLD registration data in the MPDS must be accessible without requestor identification, authentication, or stated purpose
* There may not be value in expanding the agreed-to purposes for collection of elements in the MPDS to purposes for display of the MPDS at this point
* Previous WG agreement #23: RDS policy must state purpose(s) for public access to the MPDS
* Informal show of hands in the AC room to be confirmed by poll - do you agree with this statement: There must be at least one purpose for collecting the MPDS and that purpose must include justification for making MPDS public - 7/19 agree, no disagreements
* Friendly amendments modified the proposed agreement to refer to purposes for each data element and to replace “justification” with sufficiency - see final text below
* Intent to move on to access of data beyond the MPDS during upcoming WG calls; many WG members on call supported moving on
* Poll question should include reference to the informal show of hands on this question during the call
Proposed WG Agreement (to be confirmed by Poll): There must be at least one purpose for collecting each data element in the MPDS, and that purpose must be sufficient for making that data element public.
ACTION ITEM: Staff to prepare a poll to confirm support for the proposed WG agreement reached in this call; all WG members are encouraged to participate in the poll by COB Saturday23 September
d) Consider WG agreements on purposes for collection of data beyond MPDS (deferred)
e) Discuss approach for deliberating on purposes for access to data beyond MPDS (deferred)
5) Confirm action items and proposed decision points
1. ACTION ITEM: Staff to add the 2 WG agreements resulting from the 12 September poll to be added to the working document
2. ACTION ITEM: Staff to distribute drafting team output on Original Registration Date to WG mailing list; all WG members invited to review and comment
3. ACTION ITEM: Staff to prepare a poll to confirm support for the proposed WG agreement reached in this call; all WG members are encouraged to participate in the poll by COB Saturday23 September
WG Agreement: The RDS must support Registrant Postal Address data elements: Registrant Street Address, City, State/Province, and Postal Code.
WG Agreement: The RDS must support Registrant Phone + Registrant Phone Ext (extension) data elements.
Proposed WG Agreement (to be confirmed by Poll): There must be at least one purpose for collecting each data element in the MPDS, and that purpose must be sufficient for making that data element public.
6) AOB
* Can the Leadership Team provide insight on what ICANN is doing with the EU Data Commissioners, and what will be happening at the upcoming meeting in Brussels?
* ICANN’s ad hoc GDPR compliance task force is attempting to arrange a meeting
* Leadership Team not aware of insight about this meeting beyond what has been publicly distributed
* Although unrelated to the GDPR compliance task force, note that Leadership Team is also expecting the final legal analysis report from outside counsel before the end of September 2017, and will distribute to the WG upon receipt
6) Confirm next WG meeting (Tuesday 26 September at 16.00 UTC)
Meeting Materials:
* 12 September Call poll (closed COB Saturday 16 September)
* Link to participate: https://www.surveymonkey.com/r/R27QB5W
* PDF of Poll Questions:Poll-from-12September-Call.pdf<https://community.icann.org/download/attachments/66086758/Poll-from-12Sept.pdf?version=1&modificationDate=1505278077000&api=v2>
* SurveyMonkey Summary Poll Results:SummaryResults-Poll-from-12SeptCall.pdf<https://community.icann.org/download/attachments/66086756/SummaryResults-Poll-from-12SeptCall.pdf?version=1&modificationDate=1505669584000&api=v2>
* SurveyMonkey Raw Data Poll Results: RawDataResults-Poll-from-12SeptCall.zip<https://community.icann.org/download/attachments/66086756/RawDataResults-Poll-from-12SeptCall.zip?version=1&modificationDate=1505669594000&api=v2> and XLS<https://community.icann.org/download/attachments/66086756/RawDataResults-Poll-from-12SeptCall.xlsx?version=1&modificationDate=1505669610000&api=v2>
* Annotated Survey Results: AnnotatedResults-Poll-from-12SeptCall.pdf<https://community.icann.org/download/attachments/66086756/AnnotatedResults-Poll-from-12SeptCall.pdf?version=1&modificationDate=1505670151000&api=v2>
* Drafting Team Action Item Response regarding "Original Registration Date" Original Registration Date - 18 September 2017<https://community.icann.org/download/attachments/66086756/Volunteer%20Team%20on%20Action%20Item%20regarding%20Original%20Registration%20Date%20-%2018%20Sep%20Update.docx?version=1&modificationDate=1505773044000&api=v2> and pdf<https://community.icann.org/download/attachments/66086756/Volunteer%20Team%20on%20Action%20Item%20regarding%20Original%20Registration%20Date%20-%2018%20Sep%20Update.pdf?version=1&modificationDate=1505773062000&api=v2>
* RDSPDP-Handout-For20SeptCall-v2.pdf<https://community.icann.org/download/attachments/66086756/RDSPDP-Handout-For20SeptCall-v2.pdf?version=1&modificationDate=1505777253000&api=v2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170920/33ee2404/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list