January 2019 - Gnso-epdp-team

Recordings, Attendance & AC Chat / GNSO Temp Spec gTLD RD EPDP / Tuesday, 22 January 2019
by Andrea Glandon Jan. 23, 2019

Jan. 23, 2019

Dear all, Please find the attendance and AC chat attached to this email, and the MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Tuesday, 22 January 2019 at 14:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/8pUWBg MP3: https://audio.icann.org/gnso/gnso-epdp-temp-spec-gtld-reg-data-22jan19-en.m… <https://urldefense.proofpoint.com/v2/url?u=https-3A__audio.icann.org_gnso_g…> AC Recording: https://participate.icann.org/p5z5xa9q4nf/ ** Please let me know if your name has been left off the list ** Mailing list archives of the GNSO Temp Spec gTLD RD EPDP : https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: https://community.icann.org/x/IYEpBQ Thank you. Kind Regards, Andrea Glandon

1 0

For your review - Proposed language for agreements reached in principle
by Marika Konings Jan. 22, 2019

Jan. 22, 2019

Dear EPDP Team, In Toronto, we reached agreement in principle on several issues but did not have time to develop language to which the team agreed. To move that discussion forward, the support team has developed the proposed language below for discussion and inclusion in the Final Report. Please review this language with your group to ensure it aligns with the agreement that was reached. If you are of the view that it does not conform to the agreement, please: 1. Respond to this message and change the subject line to the topic of the recommendation about which you have concerns; 2. Outline your concerns, focusing on how the proposed language does not reflect the principle agreement reached, and; 3. Propose edits that would address your concerns that are in line with the agreement reached. The deadline for doing so is Thursday 25 January so that there is sufficient time to review and discuss any concerns. If no concerns are raised, this language will be incorporated into the draft Final Report for your review. Best regards, Caitlin, Berry and Marika ========= Based on the discussions during the F2F meeting in Toronto, the following updated language is provided for EPDP Team review on the following topics / recommendations: 1. Natural vs. legal Draft recommendation 1) The EPDP Team recommends that the policy recommendations in this Final Report apply to all gTLD registrations, without requiring Registrars to differentiate between registrations of legal and natural persons, although registrars are permitted to make this distinction. 2) The EPDP Team recommends that as soon as possible ICANN Org undertakes a study, for which the terms of reference are developed in consultation with the community, that considers: * The feasibility and costs of distinguishing between legal and natural persons; * Taking into account examples of industries or other organizations where this has been successfully done; * Consider privacy risks to registrants, and; * Consider the risks of not differentiating. 3) Depending on the timing of the research, whether to inform the scope or make use of its findings, the EPDP team will discuss the Legal vs Natural issue in Phase 2. 1. Consent to publish additional contact information Agreement in principle: In its discussion on consent, the Temporary Specification omitted RNH email as a piece of information to which the registrant could consent to publication. This draft recommendation corrects that omission. Draft recommendation The EPDP Team recommends that, as soon as commercially reasonable, Registrar must provide the opportunity for the Registered Name Holder to provide its Consent to publish additional contact information. 1. Organization Field Agreement in principle: Rather than requiring the publication or redaction of the Organization Field, a phased approach was suggested by Team Members that gained general agreement. Updated Recommendation #9 1. The EPDP Team recommends that Registrars MAY begin redacting the Registrant Org field immediately. 2. For existing registrants: the EPDP Team recommends that Registrars MUST notify all existing Registered Name Holders that the Registrant Org field will be treated as non-personal data for new registrants beginning on [x date - to be agreed upon during the implementation of this Policy], and accordingly, the field will be published for new registrants in the freely-accessible directory beginning on [x date]. However, if existing Registered Name Holders wish to have its Organization field published within the freely-accessible database, it must affirmatively consent to the publication by opting in. If the Registered Name Holder affirmatively opts in to the publication of its existing (or modified) Registrant Organization, the Registrar may publish the Registrant Organization Field immediately and/or on the agreed-upon [x] date. 3. The EPDP Team recommends if the existing Registered Name Holder does not affirmatively opt in to the publication of its Registrant Organization field, the Registrar will show the existing Registrant Organization Field but the field MAY be left blank. 4. Upon (1) the registration of a Registered Name sponsored by Registrar or (2) the transfer of the sponsorship of a Registered Name to Registrar, the Registrar MUST inform the Registered Name Holder that the Registrant Org field will be published unless the Registered Name Holder affirmatively opts in to redaction of the Registrant Org field. 1. Deferring consideration of new proposed purposes to phase 2 Agreement in principle: With regards to proposed Purpose O, the Purpose supporting ARS, and the additional purposes received through public comment, the EPDP Team understands some legal clarification is required as to whether those purposes can fall under existing Purposes. Additional complexities were introduced. Therefore, the Team decided to put off this discussion for Phase 2 where the EPDP Charter makes it clear that additional Purposes are, in fact, anticipated. Draft recommendation The EPDP Team commits to considering in Phase 2 of its work whether additional purposes should be considered to facilitate research carried out by ICANN’s Office of the Chief Technology Officer (OCTO) as well as the continuation of the WHOIS Accuracy Reporting System (ARS). This consideration should be informed by legal guidance on if/how provisions in the GDPR concerning research apply to ICANN Org. Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

6 9

EPDP Recommendation 7 - email list discussion
by Kurt Pritz Jan. 22, 2019

Jan. 22, 2019

Hi Everyone: There were several items (Recommendations) that we agreed to discuss via email with the idea that we could close on them without taking time for discussion in a meeting. This email concerns Recommendation 7, addressing data disclosures to ICANN Contractual Compliance. The current recommendation states (1) The EPDP Team recommends that updates are made to the contractual requirements for registries and registrars to transfer to ICANN Compliance the domain name registration data that they process when required/requested, consistent with the data elements workbook that analyzes the purpose to handle contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users (see Annex D, Workbook 5). (2) The data elements workbook that analyzes the purpose to handle contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users contains the specifically-identified data elements the EPDP Team recommends be transferred from registries and registrars to ICANN Compliance (see Annex D, Workbook 5). Small Team Discussion (1) The small team indicated that the Workbooks should not be incorporated by reference into the Recommendation as the Workbooks provided justification or background for the Recommendation but were not Policy statements themselves. (2) The small team expressed the concern that the Recommendation, as written, did not comply with the principle of minimization in that the Recommendation as they could be interpreted to mean that the complete data set could be requested for each ICANN Compliance inquiry, whether necessary for that particular inquiry, or not. Proposed updated language recommendation 7 – ICANN Compliance (1) The EPDP Team recommends that updates are made to the contractual requirements concerning the registration data elements for registries and registrars to transfer to ICANN Compliance the domain name registration data that they process when required/requested, consistent with the data elements listed below. [Bolded language added.] (2) The analysis in Annex D describes the data elements and data flow for the purpose for processing data in accordance with ICANN Contractual Compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users. Based on that analysis and EPDP discussion, the EPDP Team recommends that the following data elements be transferred from registries and registrars to ICANN Compliance.* *To clarify, the data elements listed here are the aggregate of data elements that ICANN Compliance may request. For each request, the data elements requested must be narrowly tailored to meet the needs of the request. (E.g., as noted in the Summary of ICANN Organization’s Contractual Compliance Team Data Processing Activities <https://community.icann.org/download/attachments/90774122/Summary-Contractu…>, in validating a complaint, “the Contractual Compliance Team will only request the redacted/masked data elements that are needed to validate the issue(s) outlined in the complaint.”) Action: Please indicate on the mailing list whether you have any concerns about these modifications and/or what other aspects of this recommendation should be discussed. If there are additional questions for ICANN Compliance that would serve toinform the deliberations on this recommendation, please share these also. Deadline: Friday, 25 January, additional email discussion might follow depending on responses. Thx & best regards, Kurt

1 0

Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Thursday, 24 January 2019 at 14:00 UTC for 3 hours
by Terri Agnew Jan. 22, 2019

Jan. 22, 2019

Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays via the audio cast or view only Adobe Connect room. As requested and discussed on Tuesday's (14 August 2018) meeting, please note that an additional Adobe Connect room has been created for use by interested alternates and observers to be able to view-only the main EPDP Team Adobe Connect room. The view-only room will also broadcast the audio of the EPDP Team AC room, however, those in the view-only room will not be heard. Note that the audio cast stream will also remain available for now for those that prefer to use that option to listen live to the EPDP Team meeting. View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u Agenda wiki page: https://community.icann.org/x/9JUWBg Thank you. Kind Regards, Terri

2 1

FW: Small Team - Data Elements Workbooks
by mail＠berrycobb.com Jan. 22, 2019

Jan. 22, 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(a)berrycobb.com <mail(a)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.

2 1

Re: [Gnso-epdp-team] Proposed Agenda for EPDP Team Meeting #38 - Tuesday 22 January at 14.00 UTC
by Marika Konings Jan. 22, 2019

Jan. 22, 2019

As a reminder, the public comment review tools and discussion tables for today’s meeting can be found here: https://community.icann.org/x/U4cWBg. For your convenience, you will find here attached the discussion tables for today’s topics. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Monday, January 21, 2019 at 09:54 To: GNSO EPDP <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed Agenda for EPDP Team Meeting #38 - Tuesday 22 January at 14.00 UTC Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which has been scheduled for Tuesday 22 January at 14.00 UTC. Best regards, Caitlin, Berry and Marika ============ EPDP Meeting #38 Agenda Tuesday, 22 January 2019 1. Roll Call & SOI Updates (5 minutes) 1. Welcome and Updates from EPDP Team Chair (5 minutes) * Recap from F2F meeting and next steps * Review of outstanding action items * Other updates, if applicable 1. Continue review of public comments on Initial Report * Recommendation #3 WHOIS Accuracy – “The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be affected by this policy[1]” (30 minutes) i. Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) ii. Question for team: which concerns merit group discussion? Specifically, do any of the concerns present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation? (20 minutes) iii. Confirmation of agreement reached or next steps to come to agreement (5 minutes) * Recommendation 9 – Data redaction - City (30 minutes) i. Review of ICANN Org response to question on this topic (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-January/001250.html) (5 minutes) ii. Deliberate (20 minutes) iii. Confirmation of agreement reached or next steps to come to agreement (5 minutes) 10 minute break * Recommendation #14 Responsible Parties (30 minutes) * Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) * Question for team: which concerns merit group discussion? Specifically, do any of the concerns present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation? (20 minutes) * Confirmation of agreement reached or next steps to come to agreement (5 minutes) * General Comments (30 minutes) * Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) * Question for team: which concerns / data elements merit group discussion? Specifically, do any of the concerns / data elements suggested present new information the EPDP Team has not discussed in the context of the Initial Report? (20 minutes) * Confirmation of agreement reached or next steps to come to agreement (5 minutes) 1. Next steps to get to Final Report (15 minutes) * See draft Final Report circulated to the mailing list (see https://drive.google.com/a/icann.org/file/d/1E6W-daNTaadOhG5BRlzNJQbrT9MSoK…) * Initial thoughts and suggestions * Process for review (see https://docs.google.com/document/d/1sVZ9odV0qK1Bk8a4bDwWe5RW_PBzOnYBhHW_GnL…) 1. Wrap and confirm next meeting to be scheduled for Thursday, 24 January 2019 at 14.00 UTC (5 minutes) * Confirm action items * Confirm questions for ICANN Org, if any Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>. ________________________________ ________________________________ [1] The topic of accuracy as related to GDPR compliance is expected to be considered further, as well as the WHOIS Accuracy Reporting System.

1 0

Re: [Gnso-epdp-team] EPDP Program Status
by Alan Greenberg Jan. 22, 2019

Jan. 22, 2019

Milton, ARS can readily be considered part of Purpose 5 if we change the references to Contractual Compliance (upper case denoting a specific department) and make it more general. It is effectively an audit. The language in the purpose rationale is very specific and would need to be generalized. When I had suggested this earlier, there was resistance to doing that, wanting to keep it strictly related to the tasks of the Contractual Compliance department. Alan At 21/01/2019 01:49 PM, Mueller, Milton L wrote: Hi, Kurt For the most part I concur with what you?ve put here, but I have two differences that I?d like to record: 1. I was asked to summarize the public comments on Rec 1 (additional purposes). My work was submitted to the list. It shows that ARS is asking for data disclosure to ICANN for compliance purposes. Ergo, I have a hard time understanding why it is not already covered by Purpose 5. While I agree that we may need more legal opinion on whether ICANN is a controller, which would affect its ability to obtain data for compliance purposes, we did not agree to push ARS as a ?new purpose? to Phase 2 nor to consider it as a derivation of Purpose 2 (response to lawful disclosure requests) because it clearly does not fit in either category. I don?t think this is a controversial recommendation; whatever your view of ARS, it is hardly debatable that this is a compliance issue not a new purpose. 2. On Purpose 1, it was clear that there is not, and never will be, consensus on adding ?obligations? to Purpose 1. Obligations to third parties are covered by Purpose 2, and obligations to ICANN, Registries and Registrars are covered by the clauses referring to ?subject to contractual terms, conditions and policies.? Of the small group that was pushing adding the term ?obligations,? no one was able to make a credible case that such obligations are not covered by other purposes or by the existing language. So that is a settled issue. We are waiting for wording revisions from the CPH that would split this into two purposes, that?s all I recall. Hope your summary of program status can be modified to reflect these comments. Dr. Milton Mueller Professor, School of Public Policy Georgia Institute of Technology [IGP_logo_gold block_email sig] <http://www.internetgovernance.org/> From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Kurt Pritz Sent: Sunday, January 20, 2019 8:47 PM To: EPDP <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] EPDP Program Status Hi Everyone: Thank you again for you attentiveness and doggedness last week. Terrific. Attached is a status of our work. The first is an overall status outline all issues; the second is a tabular listing of the status of each Purpose and Recommendation. Please read both docs to get a complete picture. We will follow up with guides for each of the upcoming meetings. Thank you again, Kurt _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team

1 0

EPDP Program Status
by Kurt Pritz Jan. 21, 2019

Jan. 21, 2019

Hi Everyone: Thank you again for you attentiveness and doggedness last week. Terrific. Attached is a status of our work. The first is an overall status outline all issues; the second is a tabular listing of the status of each Purpose and Recommendation. Please read both docs to get a complete picture. We will follow up with guides for each of the upcoming meetings. Thank you again, Kurt

2 1

Proposed Agenda for EPDP Team Meeting #38 - Tuesday 22 January at 14.00 UTC
by Marika Konings Jan. 21, 2019

Jan. 21, 2019

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which has been scheduled for Tuesday 22 January at 14.00 UTC. Best regards, Caitlin, Berry and Marika ============ EPDP Meeting #38 Agenda Tuesday, 22 January 2019 1. Roll Call & SOI Updates (5 minutes) 1. Welcome and Updates from EPDP Team Chair (5 minutes) * Recap from F2F meeting and next steps * Review of outstanding action items * Other updates, if applicable 1. Continue review of public comments on Initial Report * Recommendation #3 WHOIS Accuracy – “The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be affected by this policy[1]” (30 minutes) * Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) * Question for team: which concerns merit group discussion? Specifically, do any of the concerns present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation? (20 minutes) * Confirmation of agreement reached or next steps to come to agreement (5 minutes) * Recommendation 9 – Data redaction - City (30 minutes) * Review of ICANN Org response to question on this topic (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-January/001250.html) (5 minutes) * Deliberate (20 minutes) * Confirmation of agreement reached or next steps to come to agreement (5 minutes) 10 minute break * Recommendation #14 Responsible Parties (30 minutes) * Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) * Question for team: which concerns merit group discussion? Specifically, do any of the concerns present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation? (20 minutes) * Confirmation of agreement reached or next steps to come to agreement (5 minutes) * General Comments (30 minutes) * Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) * Question for team: which concerns / data elements merit group discussion? Specifically, do any of the concerns / data elements suggested present new information the EPDP Team has not discussed in the context of the Initial Report? (20 minutes) * Confirmation of agreement reached or next steps to come to agreement (5 minutes) 1. Next steps to get to Final Report (15 minutes) * See draft Final Report circulated to the mailing list (see https://drive.google.com/a/icann.org/file/d/1E6W-daNTaadOhG5BRlzNJQbrT9MSoK…) * Initial thoughts and suggestions * Process for review (see https://docs.google.com/document/d/1sVZ9odV0qK1Bk8a4bDwWe5RW_PBzOnYBhHW_GnL…) 1. Wrap and confirm next meeting to be scheduled for Thursday, 24 January 2019 at 14.00 UTC (5 minutes) * Confirm action items * Confirm questions for ICANN Org, if any Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>. ________________________________ [1] The topic of accuracy as related to GDPR compliance is expected to be considered further, as well as the WHOIS Accuracy Reporting System.

1 0

**Resending Reminder** Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Tuesday, 22 January 2019 at 14:00 UTC for 3 hours
by Julie Bisland Jan. 21, 2019

Jan. 21, 2019

**Tuesday, 22 January 2019 at 14:00 UTC for 3 hours** Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays via the audio cast or view only Adobe Connect room. As requested and discussed on Tuesday's (14 August 2018) meeting, please note that an additional Adobe Connect room has been created for use by interested alternates and observers to be able to view-only the main EPDP Team Adobe Connect room. The view-only room will also broadcast the audio of the EPDP Team AC room, however, those in the view-only room will not be heard. Note that the audio cast stream will also remain available for now for those that prefer to use that option to listen live to the EPDP Team meeting. View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Agenda wiki page: https://community.icann.org/x/8pUWBg Thank you. Kind Regards, Terri

1 0