2017-09-20 Next Gen RDS PDP Working Group

Notes/ Action Items

1) Roll Call/SOI Updates

No updates to SOIs declared

2) Apply results of 12 Sept WG call to working document

Results showed 80% support of conclusions in the 12 September poll

ACTION ITEM: Staff to add the 2 WG agreements resulting from the 12 September poll to be added to the working document as tentative WG conclusions

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.

3)  Review recommendations from drafting team on Original Registration Date

Concern of the VT 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

VT determined that it would be valuable to know if there was a previous registration of a domain object

VT recommending instead that known occurences of a domain object's registration be recorded and counted

Counter would determine number of previous occurences, or result in an unknown query result if there are no indications of previous registrations - no negative results, which may be due to unkown previous registrations

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 VT has discussed included a counter 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

VT work and results encouraging as a technique where a small group of volunteers can discuss a topic in detail, and return to the WG with a recommendation over a 2-3 week period

ACTION ITEM: Staff to distribute drafting team output on Original Registration Date to WG mailnig 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

List of previously agreed to purposes for collection of data elements in the MPDS listed against 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 - essentialy, previous WG agreements  are the combination of the agreements on purposes to collect the data elements in the MPDS, and public access to them

Concern raised over the previously agreed to purposes for collection - these purposes may be appropriate for ICANN to disclose the data elements, but not for collection

Purposes for which ICANN can collect data should be limited to ICANN's limited mission in coordination of the DNS - ICANN should not be collecting data for the several purposes listed, but may display/provide access to data collected for the legitimate purposes identified

Independent legal analysis expected to be delivered shortly will provide information that may be useful to assess the appropriateness of ICANN collecting data elements in the MPDS for the agreed to purposes

The ICANN remit goes beyond simply operating DNS - It's mission and values talk all about 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

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 to purposes for access

General agreement that there are legitimate purposes for collecting MPDS - need to enumerate which purpose(s) they are

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

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

ACTION ITEM: WG Leadership Team to revisit the approach of use of these purposes for collection/access to the MPDS

The purposes listed are not necessarily relevant to purposes to access the MPDS, which is already publicly accessible, but may be more appropriate when considering purposes to provide tiered access to data beyond the MPDS

All that is required is to identify one reason for collection and display of a public element - example, the nameserver data must be public (minimum requirement), or the domain name would not work - other reasons would be irrelevant

Disagreement between WG members on the call on whether data elements in the MPDS can be considered PII, or not

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 correlating 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 amendment: for each element?)

Is the wording "that purpose must include justification for making MPDS public" or "is sufficient for making MPDS public"?

Intent to move on to access of data beyond the MPDS

ACTION ITEM: Staff to include the following question in this week's poll: do you agree with this statement: There must be at least one purpose for collecting each data element in the MPDS and that purpose must be sufficient for making the MPDS public

Poll question should include reference to the informal show of hands on this question during the call

    c) Confirm updates to previous WG agreements on MPDS, for access

   d) Consider WG agreements on purposes for collection of data beyond MPDS

   e) Discuss approach for deliberating on purposes for access to data beyond MPDS

5) Confirm action items and proposed decision points

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?

Leadership Team not aware of insight beyond what has been publicly distributed

Leadership Team also expecting final report from WSGR on Monday, 25 September and will coordinate utility of this report with the Legal Advisory group

6) Confirm next WG meeting (Tuesday 26 September at 16.00 UTC)