Notes/ Action Items
Agenda: 1) Welcome and Intro
- Updating the data elements workbooks was already included in the EPDP Support Team's work in finalizing the EPDP Team’s Final Report
- Transfer of data from registrars to registries is something that needs to be discussed in more detail
- Purpose 6 - RPMs purpose - need better representation b/w what occurs when a contracted party transfers data to the provider and how the data is represented on provider's site once the case in concluded
- Francisco Arias of GDD provided some clarity regarding what data elements are collected rather than generated
- Additional input that relates more to existing Consensus Policies as it relates to registration data, CLD, Thick WHOIS, Transfer, etc.
- We may need additional meetings to get through the necessary work.
- There may be some outstanding dependencies with legal advice and/or outstanding plenary discussions.
- The consolidated data elements table - these tables did not make it directly into the Initial Report; however, there was a link included in Recs. 4 -6. The intent of these tables is a 50,000 ft view of which data elements are collected, transferred, and disclosed from Rr to Ry across the seven purposes. Each table has a collection logic column on the far right. If there is a collection logic, it will be green. Optional data elements appear in yellow. No data element collection will appear in red.
2) A quick review of changes to Annex D made from the Initial Report - Better clarification as to what is collected vs. generated.
- On p. 2 (transfers), under Purpose 1, you can see a series of 1s that are highlighted in red. It is only purpose 6 that requires the transfer of elements from registrar to registry.
- Currently awaiting an updated split purpose 2 to better define activation and allocation.
3) A discussion of the small team’s approach and other ideas/requirements based from the public comment(s) that suggest this review
Team Discussion
- RySG comments note we have not done a full analysis as a working group. The Team ran out of time to deliberate on the workbooks. One of the tasks of the WG is to define the minimum data set and define purposes for that and identify the legal basis under which the processing activities will occur. Including the workbooks by reference in the policy recommendation is problematic for implementation purposes. Hoping the small team's work can take the work within the workbooks and translate it into clear policy recommendations.
- In terms of recommendation language, that is a plenary decision, but the small team can make some suggestions as to how to translate the work into policy recommendations.
- The workbooks are essentially a cheat sheet to present to a DPA.
- What is the difference b/w a transfer and a disclosure? In the law, a transfer is a subset of a disclosure. When it's transferred, it's a receipt of the information. Transfer from a registrar to a registry could instead be considered a collection by the registry.
- Concern with changing the logic is it will dramatically change the tables themselves and whether we have enough time to deal with it.
- Rewriting the workbooks is necessary.
- It's not a disclosure if it's a transfer to an approved processor for processing. It's imperative to sort out who is the processor and controller.
- Page 1 is a table of comments and until there is finality, it will not be edited. In the workbook by purpose, the purpose language from Toronto has been included.
- One task for each workbook is the data flow diagram for each purpose.
High-level Summary of Changes
- Page 1 is a table of contents for readers to link down to the purpose statements.
- Page 3 - purpose 1, the structure is consistent with what was in the Initial Report. RySG is still working on 1(a) and 1(b), so we won't get into the details of the structure of Purpose 1.
- For the most part, when defining processing activities, the team needs to have a discussion around this in terms of how the workbooks are structured. Do we need to re-label transfer to disclosure for example?
- The Responsible Party column probably needs the most work - should this be labelled at this point? We may need to discuss how this will be documented in the interim while discussion is still ongoing.
- The third column is the lawful basis column, which will probably be dealt with last, as we are awaiting legal guidance on this.
Francisco List
- Is domain name a field that is generated by the Ry or Rr.
- In the first version of the workbooks, there was no distinction b/w what is collected vs. what is generated. This is instead input by the registrant.
- For the registry updated purpose - in order for the registrar to deliver the service, they have to collect the domain name from the Rt. Once the Rr collects the info, is it a transfer from the Rr to Ry, or is it a collection from the Ry?
- PA-1 would be collection by Rr
- PA-2 would be collection to Ry
- PA-3 would be transfer from Ry to Rr (this may instead be a disclosure)
- PA-4 would be disclosure of that data - what would be public in an RDS query from an Internet user
- PA-5 would be retention. We may need to consider if we need retention since they would all be the same.
- The original intent of having these four processing activities was for the purpose of consolidated tables to ask the questions at a macro level. We may need to be more precise in terms of activation and allocation of a domain name.
- Purpose 2: as part of SSR, PA-2 transmission of registration data from Rr to Ry was not required for this purpose? N/A may not be sufficient documentation here.
- There should not be transfer from Rr to Ry for this purpose - we are not collecting data just for disclosure.
- Review the homework and ICANN's questions which are labeled in this document. From there, come up with a proposed approach on how we modify the structure or the data elements tables themselves.
- Next steps: go through the processing activities.
- Wait to go through Purpose 1 after registry submission.
- We will focus on the processing activities - let's confirm the language in the processing activities and adapt it. Test the logic following revisiting this..
- Following confirmation across one purpose’s processing, we replicate it across the other purposes.
5) Mostly circle around the logic discussions around Purpose 1 and 2
6) Quick review of consolidated data elements by processing activity charts (updates started, but depends on updates to |