Versions Compared

Version Old Version 5 New Version Current
Changes made by

Andrea Glandon

Michelle DeSmyter

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

For other times: https://tinyurl.com/yb9cb8nn

Info

PROPOSED AGENDA

.  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:

1) Welcome and Intro

2) A quick review of changes to Annex D made from the Initial Report

3) A discussion of the small team’s approach and other ideas/requirements based from the public comment(s) that suggest this review

4) A review of input received from Francisco based on a technical perspective (may align to some of the logic concerns from RySG)

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 workbooks)

BACKGROUND DOCUMENTS

Annex D - Data Elements Workbooks - 16 Jan 2019.docx

Annex D.pdf

Data Elements Matrix_v1.1.pdf

Info
titleRECORDINGS

Mp3

Adobe Connect Recording

Tip
titlePARTICIPATION

Attendance & AC chat

Apologies: none

 

Mp3

Adobe Connect Recording

Attendance & AC chat

Apologies: Alan Woods

Note
Note

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

  • 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.

      

    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

    1. 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.

    1. 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.

    1. 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)”

    1. 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.

    1. 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)”

    1. 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?

    1. 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

    1. 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:

    1. 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:

    1. 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:

    1. 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:

    1. 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

    1. 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:

    1. 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:

    1. 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.

    1. 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.

    1. 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.

    1. 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.

    1. 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?

    1. 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.

    1. 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.

    1. 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?)

    1. 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. 

    1. 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.

    BACKGROUND DOCUMENTS

    Annex D - Data Elements Workbooks - 16 Jan 2019.docx

    Data Elements Matrix_v1.1.pdf

    Info
    titleRECORDINGS
    Tip
    titlePARTICIPATION

     

    Notes/ Action Items


    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