Hi Plenary EPDP Team, As you will recall from the end of our day 3 session in Toronto, interested persons volunteered to work on the small team to test the logic of the processing activities and data elements across the seven workbooks. Their first meeting is 22 Jan 2019 at 17:30 UTC. The following have volunteered thus far: * Alex Deacon * Sarah Wyld * Alan Woods * Marc Anderson * Stephanie Perrin Below you will find an introductory email of the small team’s scope and primary activities. As this was formed on the fly, not all were present to volunteer or they were not interested in the level of detail this group will get into. Thus, the small team will welcome one or two more, especially from groups not yet represented. Given the urgency, alternates are welcome if the primary is unable to participate or interest in this topic resides elsewhere among your representatives. Please let me know if someone from your group is interested to join and we will add you/them to the small team. The 22 Jan session is not planned to be its only scheduled meeting. Thank you. B GNSO Policy Consultant @berrycobbb From: mail@berrycobb.com <mail@berrycobb.com> Sent: Monday, January 21, 2019 16:13 To: Cc: Subject: Small Team - Data Elements Workbooks Importance: High Hi All, By now, you should have received a Small Team – Data Elements Workbooks calendar invite for tomorrow, 22 Jan 2019 at 17:30 UTC for 2 hours. Upon your review of the workbooks (attached), you’ll likely see that we’ll probably need at least two more meetings to work these into final shape for the Final Report. Please consider some possible times you may be available this week and next. Apologies for the length of this email. Attached is Annex D of the draft Final Report that contains the following high-level changes in redline from the Initial Report: * Converted Purpose lettering to Purpose numbering (A to 1), including Processing Activity codes and the data flow map(s) * The addition of sidebar comments of areas that should be considered as each of the workbooks is reviewed, sourced from: * Items remaining not yet considered at publication of initial report * Latest agreed to purpose statements from Toronto * Input from ICANN Org (see below) * Other global changes identified across all Purpose workbooks, pending dependencies from plenary or the legal committee What are the key activities this small-team should accomplish? * confirm the logic of processing activities across collection, transfer, disclosure and retention * confirm data flow maps * confirm data elements for each processing activity * reconcile most recent recommendation text for Rec #s 4, 5, 6 and 8 to the processing activities and data elements * confirm and make consistent purpose rationale statements * others to be discussed What is out-of-scope for the small-team? * Purpose Statements from Toronto; the latest language will only be referenced in confirming the logic of the processing activities and data elements * The deliberation on the lawful basis until input has been received from the Legal Committee Other key tasks: * Await Purpose 1 proposal from RySG to split into Purpose 1A & 1B * Final conclusions on the Thick Whois Policy deliberations at the plenary, as it should be properly represented in the workbooks * Rows 72-82 of Registration Data Fields Comparison (not discussed for this meeting, but is additional input from ICANN Org on certain provisions in current RyAs) For the first meeting: * A quick review of changes to Annex D made from the Initial Report * A discussion of the small team’s approach and other ideas/requirements based from the public comment(s) that suggest this review * A review of input received from Francisco based on a technical perspective (may align to some of the logic concerns from RySG) * Mostly circle the logic discussions around Purpose 1 and 2 * Quick review of consolidated data elements by processing activity charts (updates started, but depends on updates to workbooks) ***Below you will see in RED actions/response to Francisco’s input to the data elements. Virtually all of these have been imported into the attached Annex D either via redline suggested change or a comment or both for the team to consider. Lastly, I will be forward this email to the main list to announce the scheduling of this call and allow for others interested to join, given that not all were present in Toronto. See you tomorrow. Thank you B Berry Cobb GNSO Policy Consultant @berrycobb Please see below additional input: 1. In recommendations 4 and 5: “Domain Name” is not a field generated by the registry/registrar, but provided by the registrant. BAC: Updated in workbooks, will be updated in Final Report 2. In recommendation 4 and 5: “Registrar Registration Expiration Date” is an optional field, i.e., not all the registrars add their own expiration date. However, if a registrar sets this field, they must transmit it to the registry. BAC: Updated in workbooks, will be updated in Final Report; comment made in Purpose 1 workbook to be reviewed by small team as this was formerly marked as Required. 3. In recommendation 4: “Reseller” is optional. However, if a registrar sets this field, they must transmit it to the registry. BAC: Updated in workbooks, will be updated in Final Report; ; comment made in Purpose 1 workbook to be reviewed by small team as this was formerly marked as Required. 4. In recommendation 4: They may want to signal that “Domain Status” can appear more than once. BAC: Updated in workbooks as footnote, will be updated in Final Report: The field will now be listed as “Domain Status(es)” 5. In recommendation 4: “Tech ID” is not optional by itself; I think what they meant is to say that providing a technical contact is optional, however, if one is provide there will be a “Tech ID” field; that is also probably the intend for the other technical contact fields. BAC: Yes, that is the intent. 6. In recommendation 4: “Name Server IP Address” can appear more than once and it is not generated by the registry/registrar, but provided by the registrant (in the general case, it just so happens that some registrants provide the DNS hosting service and so they provide these in such cases on behalf of the registrant). BAC: Updated in workbooks, will be updated in Final Report: The field will now be listed as “NameServer(s)” 7. In recommendation 5: “Registry Domain ID”, “Registry Registrant ID”, and “Tech ID” are not transferred from registrar to registry. The registry creates these. BAC: Updated in workbooks, will be updated in Final Report: Question: Just to confirm, if I were perform a RDDS query at the Registrar, these three fields will not be displayed? 8. In recommendation 5: “Registrar Whois Server”, “Registrar URL”, “Registrar Abuse Contact Email” and “Registrar Abuse Contact Phone” are not transmitted to the registry with each registration in EPP; they are provided to the registry once by each registrar and used for each registration a registrar has. I’m not sure if you want to flag this or not. BAC: Added as footnote on Purpose 1 table 9. In recommendation 5: “Updated Date” is not transmitted by the registrar to the registry. The registry sets this in its database when the registrar makes any update to the domain name (e.g., change DNS servers). BAC: Updated in workbooks, will be updated in Final Report: 10. In recommendation 5: “Creation Date” is not transmitted by the registrar to the registry. The registry sets this in its database when the name is created. BAC: Updated in workbooks, will be updated in Final Report: 11. In recommendation 5: “Registry Expiry Date” is not transmitted by the registrar to the registry. The registry sets/updates this in its database when the name is created, renewed, and possible as a result of other operations. BAC: Updated in workbooks, will be updated in Final Report: 12. In recommendation 5: “Registrar” and “Registrar IANA ID” are not transmitted by the registrar to the registry. The registry knows this when onboarding the registrar independent of any given registration. BAC: Updated in workbooks, will be updated in Final Report: 13. In recommendation 5: “Domain Status” (which is a field that can appear multiple times) may or may not be set by the registrar; some status are set by the registrar, some are set by the registry. BAC: Added as footnote on Purpose 1 table 14. In recommendation 5: “DNSSEC” is not transmitted by the registrar to the registry. The registry derives this from other information provided by the registrar, i.e., DNSKEY or DS records. BAC: Updated in workbooks, will be updated in Final Report: 15. In recommendation 5: “Last Update of Whois Database” is not transmitted by the registrar to the registry. The registry knows when this happened, i.e., when the registry updated the database that contains the record being asked for. BAC: Updated in workbooks, will be updated in Final Report: 16. In recommendation 6, numeral 6: the text should be updated to something like “… the EPDP Team recommends be transferred by Registries and/or Registrars (as the case may be) to data escrow providers …” Some of the fields are only available to the registry and it only makes sense for the registry to escrow those; adding something to the effect of the above language would allow later in the process to define explicitly which fields are escrowed by registry and which by registrars. Alternatively and preferably, the EPDP may want to separate the recommendation in two, one for registries, another for registrars. BAC: Agreed on the preference, and that is why Purpose 4 is split into two workbooks 4A-Registrar, 4B Registry. I think for the purpose of the Final report, we should remove the brown consolidated table, and create a distinct table for the Rr and Ry, representing the specific data fields transferred to the Escrow Provider. This will be flagged for the small team review. 17. In recommendation 6: it should be clarified that “optional” fields must be escrowed if data exists. BAC: Added footnote to Purpose 4B workbook, we’ll add to Final Report’s recommendations section upon executing #16 above. 18. In recommendation 6: “DNSSEC” should not be escrowed. Instead the related DNSKEY or DS records from which this field is derived must be escrowed. BAC: Added comment to Purpose 4B workbook to address with small team. 19. In recommendation 6: “Last Update of Whois Database” should not be escrowed. As explained above, this field indicates when the registry updated the database that contains the record being asked for. It only makes sense in the context of a response to a given query. BAC: This will be addressed in #16 above; confirmed that Purpose 4B workbook properly transfers this field, while the 4A workbook does not. 20. In recommendation 6, question 3: perhaps the EPDP should consider language similar to what the 2017 base registry agreement has in specification 2 regarding what should be escrowed: “the universe of Registry objects to be considered for data escrow are those objects necessary in order to offer all of the approved Registry Services”. BAC: This can be addressed in #16 above? 21. In recommendation 8: the table is missing to list the Registrant ID and Tech ID to indicate whether they should be redacted or not. BAC: Confirmed. This table should be updated. I flagged in the Purpose 2 workbook for the small team to confirm these two fields. “Registry Registrant ID” shows disclosed and redacted. However, “Tech ID” is not designated as being disclosed. The consolidated data elements table also has this flagged to be addressed. 22. Recommendation 9 does not appear clear enough. BAC: Being considered by EPDP Plenary, substantial changes deliberated in Toronto that will changes the recommendation language from the Initial Report. 23. Recommendation 11 seems to be missing the list of data elements to be retained. BAC: Retention is still an active issue under deliberation by the EPDP. The small team will also examine the logic of retention across each of the 7 purposes, by role. Purpose 1 workbook contains the Processing Activity and data elements that will be retained, but it is implied that it is both for Registrars and Registries. Should two Processing Activities in the workbook be created to distinguish and Rr and Ry retention tag? Recommendation 11 only mentions Registrars, should it also include Registries (or via a distinct recommendation?) 24. Recommendation 12 includes a few elements to be developed during the implementation of the policy (e.g., timeliness of responses, format, logging) that are probably too big topics to be left for implementation. It would be better if the policy dealt with them. BAC: Retention is still an active issue under deliberation by the EPDP. 25. Annex D: various data element matrices use as key { “1” = Required “(1)” = Optional “-“ = Not Required or Optional}. The last two elements could benefit from clarification as to: 1) what it means to be optional as described above; and 2) whether “-“ is not required or optional; I don’t think it is helpful to have these in one element. BAC: Added as issue to address in small team review of workbooks.