[Gnso-epdp-team] Notes and action items from EPDP Meeting #12 - 25 July 2019
Alan Woods
alan at donuts.email
Tue Jul 30 08:42:27 UTC 2019
Dear Janis,
We would like to echo the sentiments of Volker, and our registrar
colleagues. We understand that we are being pressed upon by numerous
outside forces to move matters along; however, not only are such matters
best served by time to consider the question or statement posed, more
practically speaking, and as has been noted previously, we are merely
representatives of much larger groups and cannot provide meaningful
approval to many substantive matters in the span of seconds. In matters of
substance, we may find ourselves unable to provide comment, one way or the
other, without time to canvass our broader groups, for discussions and
instructions. This may appear as silence, but we assure that it is neither
indicative of assent nor dissent, merely an indicator that we are not in a
position to yet comment without further reflection.
We understand the need to move matters along, and indeed, in non
contentious matters, I can accept that silence will be acceptable, but, we
do expect that in matters of a more substantive nature, including and for
example, where comments to a document are to serve as the basis for draft
policy recommendations, we would expect that such matters are to be decided
on a more affirmative basis and we cannot support silence as being a valid
indicator of approval in such instances.
Thank you for your continuing patience,
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 Fri, Jul 26, 2019 at 5:38 PM Volker Greimann <vgreimann at key-systems.net>
wrote:
> Just to add to my previous mail, we will be adding in some comments into
> the document today, but this is not to say there will not be further
> comments down the road. Also note that not commenting does not mean
> agreement.
>
> We also did not register the action on the call, which is probably why we
> did not object then.
>
> Best,
>
> Volker
> Am 26.07.2019 um 18:28 schrieb jk:
>
> Volker,
>
>
>
> Your concern is noted.
>
>
>
> We will discuss submitted early inputs in one of the next plenary meetings.
>
>
>
> I would like to use this opportunity to encourage team members raise their
> voice during the meetings if you are not sure about the proposal of the
> Chair. Without seeing body language, it is hard to say if proposal is
> acceptable. I take silence as approval.
>
>
>
> Best regards
>
> JK
>
>
>
> *From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces at icann.org
> <gnso-epdp-team-bounces at icann.org>] *On Behalf Of *Volker Greimann
> *Sent:* Friday, July 26, 2019 6:20 PM
> *To:* gnso-epdp-team at icann.org
> *Subject:* Re: [Gnso-epdp-team] Notes and action items from EPDP Meeting
> #12 - 25 July 2019
>
>
>
> Hi Ariel,
>
> we are concerned with your assumption under Action Item 1.
>
> We were working under the understanding that this would be subject to
> another plenary session and we did not have sufficient time to deliberate
> the eqarly input document with the entire group. Also, just because no
> clarifying questions have been raised does not mean that the contents of
> the document are a consensus position agreed by all. No questions means
> just that, no questions. But not necessarily agreement.
>
> We may very well end up agreeing with the contents of the document, but we
> are not there yet.
>
> We therefore respectfully request that this not be taken as basis for
> drefting the initial report quite just yet.
>
> Best regards,
>
> Volker Greimann
>
> Am 26.07.2019 um 17:10 schrieb Ariel Liang:
>
> Dear EPDP Team:
>
>
>
> Below, please find the notes and action items from yesterday’s EPDP Team
> Meeting.
>
>
>
> As a reminder, the next EPDP Team Meeting will be Thursday, 1 August at
> 14:00 UTC.
>
>
> Best regards,
>
>
>
> Marika, Caitlin, Berry (and Ariel – assisted with notetaking)
>
>
>
>
>
> *EPDP Phase 2 - Meeting #12*
>
> *Thursday, 25 July 2019* at 14:00 UTC
>
> *Action Items: *
>
> 1. If no further clarifying questions are submitted in response to the
> early input document by the deadline (25 July 2019), staff to consider the
> comments in the development of the draft policy recommendations and draft
> Initial Report.
> 2. Staff to set up survey for the EPDP Team to rank and identify the
> most representative case in each group of the use case categorization. EPDP
> Team to complete the survey by COB *Monday, 29 July*.
> 3. Staff to compile the input submitted on automation/accreditation to
> assist the EPDP Team in its substantive discussions during next week’s call
> and future calls. Leadership team to develop initial thoughts paper on
> accreditation to kick start discussions.
> 4. Chris Lewis-Evans to incorporate input received from the EPDP Team
> and continue fine tuning the use case (GAC LEA1-13719-1), which is expected
> to be attached in the annex to the Initial Report. Updated version to be
> posted on the Wiki and the leadership to make a further recommendation for
> how to finalize the use case.
> 5. In meeting on Thursday, 1 August, the EPDP Team to devote part of
> the meeting to discuss initial reaction from members on the SSAC
> Crime-Abuse Investigation Use Case. EPDP Team to provide input by writing
> no later than *14:00 UTC on Monday, 29 July*. More detailed discussion
> about this use case will take place in the meeting on 8 August.
>
>
>
> *Notes *
>
> *These high-level notes are designed to help the EPDP Team navigate
> through the content of the call and are not meant as a substitute for the
> transcript and/or recording. The MP3, transcript, and chat are provided
> separately and are posted on the wiki
> at: https://community.icann.org/x/l6ajBg
> <https://community.icann.org/x/l6ajBg> *
>
> 1. Roll Call & SOI Updates (5 minutes)
>
> - Attendance will be taken from Zoom
> - Remember to mute your microphones upon entry to Zoom, which is
> typically the first icon on the left on the bottom toolbar.
> - Please state your name before speaking for transcription purposes.
> - Please remember to review your SOIs on a regular basis and update as
> needed. Updates are required to be shared with the EPDP Team
>
> 2. Confirmation of agenda (Chair)
>
> - No objections
>
> 3. Welcome and housekeeping issues (Chair) (10 minutes)
>
> a) Update from Legal Committee
>
> - Started out by reviewing prior session’s action items and questions
> - Reviewed the remaining questions, narrowed down the scope, and those
> questions will be evaluated based on the needs of Phase 2. Near term goal
> is to understand all the legal requirements and try to develop sizing for
> requesting additional resources from the Board.
> - Next LC meeting is 6 August.
>
> b) Early input review status (deadline 25 July)
>
> - A number of groups responded to the EPDP Team’s request for early
> input. This input was subsequently organized by staff in the form of an
> early input review tool.
> - Following EPDP Team discussion, input regarding SSAD has been
> incorporated into SSAD worksheet for EPDP Team review. In addition, the
> EPDP Team agreed to review the input received and document any clarifying
> questions in the google doc that was created.
> - Deadline for clarifying questions on the early input was Thursday 25
> July. No comments/questions were received at the time of the call.
> - ACTION ITEM: If no further clarifying questions are submitted in
> response to the early input document by the deadline (25 July 2019), staff
> to consider the comments in the development of the draft policy
> recommendations and draft Initial Report.
>
> 4. Use Cases Categorization (10 minutes)
>
> a) Review proposed categorization put forward by small team
>
> - A small group of volunteers agreed to work with staff. Based on the
> original staff categorization and incorporating input from NCSG, BC and
> IPC, staff/volunteers went through a number of iterations to review the use
> cases. Important to note that no use case has been eliminated as a result
> of this exercise. Objective is to identify the most representative case for
> each category as a starting point for the deliberations. Following review
> of the most representative use case in each category, the EPDP Team can
> then decide whether additional cases need to be reviewed.
> - 5 groups, as noted on the document.
> - Appreciation to Milton, Margie, Chris, and Brian for their
> contributions to this exercise.
> - Chair’s proposal: Identify in each group, the most representative
> use case that the EPDP Team should look at first, starting from Group 1.
> - We have already made decisions where to start. First group 1. After
> that, group 2, move to group 4 and then group 3 or 5.
> - Staff to put in survey format and ask EPDP Team members to respond
> to the survey by COB Monday, 29 July.
> - Review the representative use case first, and see whether any issue
> associated other use cases that warrant being reviewed. Not sure whether
> there is time to do an in depth review of each of them.
> - For the rest of the cases, maybe only look at the differences
> instead of an in depth review.
> - Would it be useful to map the stages (e.g., a series of questions)
> that a compliant organization must go through as it determines whether it
> is a legitimate request for information. Who? What scope? Under what
> authority? Etc. Left column of the use cases are geared toward answering
> those questions and providing a framework for discussions. In reality we
> are talking about rather simple system. Supply is the Registry/Registrar,
> and they have the building blocks. Going through the use cases is to
> understand each of the building blocks.
>
> b) Confirm proposed categorization
>
> - No objection
>
> c) Confirm new ranking survey & deadline to determine most representative
> use case in each category
>
> - Staff to set up survey for the EPDP Team to rank and identify the
> most representative case in each group of the use case categorization. EPDP
> Team to complete the survey by COB Monday, 29 July.
>
> 5. Use case – first reading: Investigation of criminal activity where
> domain names are used. Typical specific example: phishing attack
> <https://community.icann.org/download/attachments/111386876/SSAC%20Crime-Abuse%20Investigation%20Use%20Case%20-%2011%20July%202019.docx?version=1&modificationDate=1562865007000&api=v2>
> (60 minutes)
>
> - Chair’s proposal: EPDP Team to identify the difficulty in the first
> reading of the case (SSAC Crime-Abuse Investigation Use Case), present them
> in writing and share on the mailing list.
> - Defer the discussion of the use case till 8 Aug due to Greg’s
> absence during next week’s meeting? Provide initial overview during today’s
> meeting with ability for EPDP Team to share initial observations during
> today’s and next week’s meeting, followed by in depth review during 8
> August EPDP Team meeting.
> - Review a set of tasks / purposes that occur in a number of cyber
> crime cases. Some are done by investigators in private realm. Some steps
> are done by law enforcement due to the same goal. Purpose here is to
> explain how things work practically and see what issues would surface.
> - Start with practical instances (i.e., recital 49) about the
> processing of data. Then compromised/malicious registrations.
> - Section A, law enforcement may also rely on these parties and
> techniques.
> - Section B, Tasks 1-2: reasons why the data are requested and used.
> Maliciously registered means somebody uses the domain name to commit a
> crime. If a domain name is maliciously registered, suspending the domain
> name is an option. If a domain name is compromised, you don’t want to
> suspend the domain. Reputational providers do not generally block domains.
> Some just list domain names and say don’t have anything to do with them.
> You need to determine what additional domains may be related. The issue is
> dealing with ongoing harm. You can determine what other domain names are on
> the same IP address, which may not be operated by the same bad actor.
> - Section B, Task 3: If the contact data is bogus, it is a sign of bad
> faith. Sometimes criminals do a poor job of faking the data. Accessing
> accuracy is important. Comment from EPDP Team members: Bogus data is not
> automatically a sign of bad faith. And your accuracy check has to be done
> by compliance.
> - Section B, Task 4: Need to document the case and preserve the reason
> why you made the decision of suspending the domain name and substantiate
> why the domain name is problematic. Be responsible and give decision
> makers the information they need.
> - Section B, Task 5: law enforcement and private parties do this.
> Private parties may want to avoid associated assets.
> - Section B, Task 6: many aspects involve automation. Some block lists
> use algorism. The system that protects people involve a high degree of
> automation.
> - So how does 49 relate to domain names? When domains are as the
> mechanism for the cybercrime attack, the “ability of a network to resist…”
> will largely be based on the ability to continue to allow traffic from said
> domain, or (as Greg is explaining) to block / reject any further traffic
> from or access to said domain.
> - How can you describe things generally and then go to nitty gritty
> issues like automation. you need to be very specific in other fields as
> well. Don’t see a Use Case here. Need clear explanation on how all those
> recitals and all the clauses apply to these issues.
> - It is an issue with the law but not what ICANN/EPDP Team can fix. We
> still have to apply the law as best as possible, but EPDP Team cannot make
> any effort to change the law.
> - The EPDP Team needs to work on how to deal with the balance of the
> law.
> - The internet will die far faster if people are advocating breaking
> it because people did not involve themselves in the crafting of such law.
> For example the e-privacy regulations were stalled because an affected
> party advocated on how the law would have an unintended consequence. Again
> ICANN cannot fix the way it is, we can only figure out a way of making the
> "new" post GDPR world better .... including shaping future legislative
> endeavors - not by ICANN policy supporting a bending of that law.
> - They should be reported to law enforcement. Not like Brian Krebs
> just putting out info of the attackers wife on a public blog.
> https://krebsonsecurity.com/2017/07/who-is-the-govrat-author-and-mirai-botmaster-bestbuy/ security
> researchers need to do their research diligently without harming those who
> are not involved.
> - Suggest that people do their research on how investigations by
> private actors are managed under DP law in the meantime, and talk about the
> case the following week. While cybercrime is a good example of rampant
> regulatory avoidance, it is not the only one. However, it does not work
> well under data protection law (competition law also being relevant but not
> in our remit).
> - The need is to stop the harmful activity, it is not to identify the
> guilty party. You don’t need redacted data to substantiate the domain.
> There will be a lot of information that won’t be redacted. Support efforts
> by private actors to sweep through the information to stop attacks, but we
> don’t need to open up the data.
> - The practical issue is that the vast majority of the cases do not
> involve law enforcement or are being reported. Law enforcement does not
> have the resources. A lot is done by relying on contract.
> - Phone number is relevant when its relevant. This use case doesn't
> cover those instances where passive DNS (for example) was sufficient. They
> do exist, but not relevant to this use case .
> - ACTION ITEM: In the meeting on Thursday, 1 August, the EPDP Team to
> devote part of the meeting to discuss initial reaction from members on the
> SSAC Crime-Abuse Investigation Use Case. EPDP Team to provide input by
> writing no later than 14:00 UTC on Monday, 29 July. More detailed
> discussion about this use case will take place in the meeting on 8 August.
>
>
>
> 6. Use case – final reading: Investigation of criminal activity against a
> victim in the jurisdiction of the investigating EU LEA requesting data from
> a non-local data controller
> <https://community.icann.org/download/attachments/111386876/Use%20Case%20-%20GAC%20LEA1-13719.docx?version=1&modificationDate=1563377116000&api=v2>
> (30 minutes)
>
> - Chair’s Proposal: deal with this item before the first reading of
> item #5
> - Starting from g) Safeguards (requirements) applicable to the Entity
> Disclosing the Nonpublic Registration Data
> - See responses from Chris Lewis-Evans to comments submitted by RrSG
> on this use case. Chris agrees with Registrar group’s suggestion re Section
> C, as it gives an increasing level of accuracy. Agree with the suggested
> change in Section D by the registry group. Section F, agree with the
> suggested change.
> - Chris Lewis-Evans will also consider additional registrars’
> comments/questions. Registrar reps indicated that they will need a couple
> of days to review the responses Chris provided and may respond further on
> the list once they have had a chance to do that. Don’t take silence as
> complete agreement.
> - Re 6(1)F, the legal authority needs to be identified. EPDP Team is
> not expert to verify that. Ensure that LEA establishes the legal authority
> itself.
> - Section H:
>
>
> - Clarify the comments from registrars, add safeguards under automated
> system which may be different.
> - Need to have a discussion about how the automated system works.
> - Probably useful to drop a footnote in the template to provide the
> explanation Chris just gave so it’s clear on its face and avoids later
> confusion and uncertainty.
>
>
> - Section I, no further comments/requests.
> - Section J:
>
>
> - First time discussing accreditation. It is a chicken-egg situation,
> as it depends on the standardized system. Jurisdiction and legal basis
> would be necessary for an accreditation body to look at.
> - There are differences between accreditation and validation. Some
> suggested to first discuss validation first, as it has different forms
> which can or cannot be automated. Accreditation might then be fully
> automated.
> - “Validation” probably means “authentication” that is covered in
> Section K. We need to deal with accreditation first before authentication.
> There may be one exceptional case that one can be authenticated before
> accreditation, but it does not justify changing the default order.
> - This depends on the implementation of the standard system. Even
> we don’t end up with having a centralized system, we can still do it. A
> decentralized system can still have value. The same standards can be
> centralized and also applied in decentralized way.
> - The “code of conduct” may not be part of the accreditation.
> Disclosure / nondisclosure related issues belong more in the safeguard
> section.
> - EPDP Team can create a special accreditation entity that consists
> of one group or many groups. There are a number of options. But first need
> to see whether there is a broad agreement that accreditation as a principle
> should be introduced in the standard.
> - EPDP Team needs a set of definitions because people are using the
> terms in different ways, and for accreditation, there are two aspects.
> Accredditing of a group to be eligible to use a system (or make a manual
> request) and accrediting an individual requester to be part of that group. This
> is what we currently have in the chair’s working definitions document:
> “Accreditation – refers to the process or action of recognizing a person as
> having a particular identity, possibly with an associated affiliation or
> status.”
> - See Chair’s working definitions here:
> https://community.icann.org/x/-5WjBg
> <https://community.icann.org/x/-5WjBg%5C>. Strongly suggest to
> flesh out the details when people are using different meanings for the same
> terms.
> - There is no accreditation body that the EPDP Team needs to define
> or create. The EPDP Team does not need to determine what the accreditation
> elements/criteria are. Specifically about the LEA, it is up to the law
> enforcement and the coalition of law enforcement bodies to do it. Part of
> this comment will represent part of the policy statement. As a policy
> matter, there should be accreditation, the accreditation should ensure
> certain aspects/points, etc. We can develop general policies on
> accreditation and it is in our work plan.
> - There would be some “approved” list of accredited based on some
> the set of criteria.
> - Another consideration, albeit not an immediate problem, is about
> authoritarian government, human rights protection, cloud act, etc. We can
> accredit a law enforcement agency as a legitimate one, but if there is a
> national law that allows the agency to investigate or harass people that
> criticize the government, how do we want to handle that? Do we want to have
> additional human rights protection attached to the accreditation criteria?
> - A lot of those human rights concerns can be addressed by the
> terms of use, ensuring there is strong enforcement of the terms of use.
> - General policies to keep authoritarian countries away from
> disclosure and accreditation? Don’t think this group can do that. Also some
> of these countries are allegedly undertaking cyber attacks. Whatever this
> LEA accreditation body would be, civil society would definitely have to be
> involved in the definitions, but this is outside of our remit.
> - Somebody accredited does not mean he/she has a valid request. You
> have to review each request to ensure it is valid. There is a
> responsibility for the entity that releases the data to validate the
> request. We all agree at this point that accreditation doesn't assume
> guaranteed access. A valid form of accreditation is merely a factor in the
> 6(1)f balance - or in the case of jurisdiction - a confirmation that there
> is a legal obligation on that controller in that jurisdiction.
> - Does every single contracted party need to act as its
> accreditation body? This may not be implementable.
> - The correct safeguards for both the accreditation and the
> authentication levels need to be developed.
> - If we are talking about a fully automated accreditation process,
> law enforcement organizations can be done easily, but not so easy to
> accredit other kinds of organizations. Need some human intervention. Also
> need a decision making process, which can be automated possibly.
> - Staff have grouped the input on accreditation together, aligning
> with the relevant charter questions (but no definition):
>
>
> - b) What are the unanswered policy questions that will guide
> implementation?
> - b1) How will credentials be granted and managed?
> - b2) Who is responsible for providing credentials?
> - b3) How will these credentials be integrated into
> registrars’/registries’ technical systems?
>
>
> - Chair’s proposal: When accreditation is discussed next time, Staff
> to pull out their compilation of everything that has been submitted on
> accreditation and identification related processes to help inform EPDP
> Team’s further deliberation on this fundamental building block.
>
>
> - Section L:
>
>
> - Come back to “credentialing” in a more structured way when reviewing
> the next case.
> - We add a footnote to note it.
>
>
> - Section M:
>
>
> - it is up to the LEA whether there is any urgency. In certain cases,
> a specific quick turn around may be necessary, but 2 days across the board
> may be too restrictive.
> - There is concept of acknowledging the requests, whether the data
> will be delivered. Some requests have higher priority and some requests
> demand different levels of confidentiality. Need to accommodate these
> concepts.
> - If you have a lot of requests, you have to staff up too.
> - Maybe Section M and Section O should be different. The level of
> requests is just for the LEA’s consideration, and that level is generally
> lower than other kinds of requests. Maybe 4 business days would be more
> than reasonable? Some exceptions can be made and listened to.
> - We cannot apply go daddy standards to all Registrars. It is a
> long tail data set, and many registrars may have one request/day, aligning
> with their size of business. There is a natural balancing. Also need to
> factor in that not all registrars will receive the same volume of requests
> - this may be aligned with the # of domain names under management.
>
>
> - Section N:
>
>
> - Is it possible to have an automated decision? How determinations are
> made when there is disagreement? We can automate processes, but not all
> processes can be automated. Need to evaluate all the information received
> before moving forward.
> - If an LEA makes a request for 10,000 records all based on the
> same legal basis and investigation, could the request be manually reviewed
> but once approved the delivery of the data automatic?
> - There may be instances that some data fields can be released
> safely for bona fide parties. Automated does not mean all the way to
> finish, it can be 80% of the process. This is important to know by the
> practitioner.
> - All the details regarding use cases are relevant to what can be
> automated or not. Focus on the use cases first and then circle back to this
> question. Automation is one of the charter questions and building blocks.
>
>
> - Section N:
>
>
> - Suggest removing the word “possible” and leaving “desirable”. A
> “possible" question should remain in the template, though we may want to
> separate it from "desirable" Data retention would be subject to
> legal requirements in the jurisdiction of the LEA would it not? Might be
> better to ask whether automation is consistent with legal
> requirements/legal basis .
>
>
> - Section P: not so clear, suggest the same language used in the
> previous section for retention. There is no blanket answer.
> - ACTION ITEM: Staff to compile the input submitted on
> automation/accreditation to assist the EPDP Team in its substantive
> discussions during next week’s call and future calls. Leadership team to
> develop initial thoughts paper on accreditation to kick start discussions.
> - ACTION ITEM: Chris Lewis-Evans to incorporate input received from
> the EPDP Team and continue fine tuning the use case (GAC LEA1-13719-1),
> which is expected to be attached in the annex to the Initial Report.
> Updated version to be posted on the Wiki and the leadership to make a
> further recommendation for how to finalize the use case.
>
>
>
> 7. Any other business (5 minutes)
>
> a) Priority 2 small team meetings update
>
> (1) Accuracy and WHOIS ARS (see
> https://docs.google.com/document/d/1pS9Pibanj-Hp6LztZpeERtxdoLsnp4y_-do0vU5VJuw/edit[docs.google.com]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1pS9Pibanj-2DHp6LztZpeERtxdoLsnp4y-5F-2Ddo0vU5VJuw_edit&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=5YD7bD56hEe4pQH_dqUWfn942ryJsY558QEJfweSvL4&s=F6hmCB4N05tXAmHo8nuMH6_4YK5hSWXaa5p8T0SNwXw&e=>
> )
>
> (2) Input received on other priority 2 items from RrSG (see
> https://mm.icann.org/pipermail/gnso-epdp-team/2019-June/002174.html)
>
> (3) Leadership to recommend next steps via mailing list
>
> b) Council request for input on org letter requesting clarification on
> Data Accuracy and Phase-2 (see
> https://gnso.icann.org/sites/default/files/file/field-file-attach/marby-to-drazek-21jun19-en.pdf[gnso.icann.org]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_default_files_file_field-2Dfile-2Dattach_marby-2Dto-2Ddrazek-2D21jun19-2Den.pdf&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=5YD7bD56hEe4pQH_dqUWfn942ryJsY558QEJfweSvL4&s=YeVJr1ZFqKyDvbIDvXURXaal3PB4fqg3oghAsQwtfSA&e=>).
> EPDP Team to provide input on the mailing list. Confirm deadline for
> input.
>
>
>
> - The EPDP Team did not address these agenda items
>
>
>
> 8. Wrap and confirm next EPDP Team meeting on Thursday 1 August 2019 at
> 14.00 UTC (5 minutes)
>
> a) Confirm action items
>
> b) Confirm questions for ICANN Org, if any
>
>
>
>
>
>
>
> _______________________________________________
>
> Gnso-epdp-team mailing list
>
> Gnso-epdp-team at icann.org
>
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
> _______________________________________________
>
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
>
> --
> Volker A. Greimann
> General Counsel and Policy Manager
> *KEY-SYSTEMS GMBH*
>
> T: +49 6894 9396901
> M: +49 6894 9396851
> F: +49 6894 9396851
> W: www.key-systems.net
>
> Key-Systems GmbH is a company registered at the local court of
> Saarbruecken, Germany with the registration no. HR B 18835
> CEO: Alexander Siffrin
>
> Part of the CentralNic Group PLC (LON: CNIC) a company registered in
> England and Wales with company number 8576358.
>
> --
> Volker A. Greimann
> General Counsel and Policy Manager
> *KEY-SYSTEMS GMBH*
>
> T: +49 6894 9396901
> M: +49 6894 9396851
> F: +49 6894 9396851
> W: www.key-systems.net
>
> Key-Systems GmbH is a company registered at the local court of
> Saarbruecken, Germany with the registration no. HR B 18835
> CEO: Alexander Siffrin
>
> Part of the CentralNic Group PLC (LON: CNIC) a company registered in
> England and Wales with company number 8576358.
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190730/d3f1d2d9/attachment-0001.html>
More information about the Gnso-epdp-team
mailing list