[Gnso-epdp-team] FW: Small Team - Data Elements Workbooks

Tue Jan 22 00:06:27 UTC 2019

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 at berrycobb.com <mail at 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).