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

Tue Jan 22 17:20:37 UTC 2019

Hi guys,

As noted in the Doodle poll response I was tentative for this time slot,
and that tentative has turned to a likely not. Luckily Marc is also on the
team, and I will still be happy to do the work, but this evening is far
from ideal for me. I can pop in for the start of the meeting, but I shall
have to leave relatively soon.

Apologies all,

Alan

[image: Donuts Inc.] <http://donuts.domains>
Alan Woods
Senior Compliance & Policy Manager, Donuts Inc.
------------------------------
The Victorians,
15-18 Earlsfort Terrace
Dublin 2, County Dublin
Ireland

<https://www.facebook.com/donutstlds>   <https://twitter.com/DonutsInc>
<https://www.linkedin.com/company/donuts-inc>

Please NOTE: This electronic message, including any attachments, may
include privileged, confidential and/or inside information owned by Donuts
Inc. . Any distribution or use of this communication by anyone other than
the intended recipient(s) is strictly prohibited and may be unlawful.  If
you are not the intended recipient, please notify the sender by replying to
this message and then delete it from your system. Thank you.

On Tue, Jan 22, 2019 at 12:07 AM <mail at berrycobb.com> wrote:

> 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*
>
>    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.*
>
>
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190122/45f77976/attachment-0001.html>