[Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Janis Karklins
karklinsj at gmail.com
Mon Oct 21 15:30:46 UTC 2019
I think we need to be careful and not to mix two terms: automatic and
automated.
We agreed at the beginning of the process that there won't be an automatic
access or disclosure. Each request will be examined on its own merits - in
automated or manual fashion. When it comes to manual processing - we will
attempt to standardize it as much as possible.
JK
On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann at key-systems.net>
wrote:
> Hi Hadia,
>
> the problem with automatic disclosure is that even if it were legally
> possible in certain circumstances, it carries with it a certain liability
> risk. Naturally therefore, it should be the decision of the party (-ies)
> carrying this liability whether they accept this liability risk or not.
> From everything Göran has told us, ICANn will not be the party accepting
> this liability, so that leaves the contracted parties.
>
> I for one would be open to granting some form of automated access to
> certified law enforcement agencies of my own jurisdiction (and others that
> may be legally applicable) for example as they have the power to legally
> compel me to provide that data, but others may not accept that liability of
> short-cutting due process.
>
> 6(1)a - is a tricky number, since it also (amongst other requirements)
> requires us to provide evidence of that consent, and everytime we act
> through third parties, we cannot be sure that the consent we gathered is
> actually that of the data subject.
>
> As far as processing for fraud protection, IT security, etc go under the
> GDPR, I would advise revisiting this section as you may be surprised as to
> whose protection and security this is intended for (that of the processor
> and controller, but not that of unrelated third parties). It is a
> legitimate purpose for internal processing by the processor but not for
> disclosure by a third party who wants to use it for that purpose. So again,
> it is not as easy as you think it is.
>
> You are correct that for the balancing test you need to prove that the
> interests of the data subject does not override the interests of the
> requestor, but for that, you need to look at the specific circumstances. I
> think it would be very difficult to automate such a review to find out the
> interests of the data subject, let alone figuring out whether they do not
> outweigh the interests of the requestor. Maybe Google and Facebook have
> that kind of AI tech, but we don't. Again, certain types of LEA requests
> may be on a different scale that make this easier.
>
> I have been a big fan of doing the LEA part first and then looking at what
> parts of that would be adaptable to other requestors from the start. With
> that, we would likely already have another part that would be ready for
> development now.
>
> Best,
>
> Volker
> Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
>
> Hi ,
>
>
>
> At least we can agree that using the accreditation system only for
> identification is a waste of money, resources and defies any kind of
> logical thinking. Also Amr, I don't know why you see automatic disclosure
> as impossible (provided of course that it abides by the law) Whether
> automatic disclosure will be possible or not will depend on the lawful
> basis used for disclosure and on the specific context and circumstances
> (under some lawful basis and not all). So for example if you are disclosing
> data under 6(1)(a) -consent for specific purposes- I would argue that
> automating this is both desirable and possible. But also if we look at the
> disclosure of the data under 6(1)(f) (legitimate interest) In order to
> decide whether to disclose the data or not you will need to perform a
> legitimate interest assessment which would consist of three parts
>
> Purpose test
>
> Necessity test
>
> Balancing test
>
> For the purpose test, legitimate interest may include a wide range of
> purposes, however GDPR specifically mentions fraud prevention, IT security
> and criminal acts as legitimate interests so if you have parties accredited
> for specific purposes they can automatically pass this test.
>
> For the necessity test you need to prove that there is no other logical,
> less intrusive way to achieve your purpose, again if you have parties
> accredited for specific purposes this test can also be automated.
>
> For the balancing test you need to prove that the interests of the data
> subject does not override the interests of the requestor and again under
> similar contexts and circumstances maybe this could be possible.
>
>
>
> I am not trying now to decide what can or cannot be automated as this will
> need thorough studying, but what I am trying to say that it is not useful
> to anyone to just decide that automatic disclosure would be impossible. We
> might be wasting good implementation solutions and practices if we come up
> with a policy that states so.
>
>
>
> Best
>
> Hadia
>
>
>
> *From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces at icann.org
> <gnso-epdp-team-bounces at icann.org>] *On Behalf Of *Amr Elsadr
> *Sent:* Monday, October 21, 2019 1:43 PM
> *To:* Volker Greimann
> *Cc:* gnso-epdp-team at icann.org
> *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25
> - 17 Oct 2019
>
>
>
> Hi,
>
>
>
> I think we need to be very clear on what we’re discussing, and what
> different groups might be seeking or agreeing to. Alex pointed out a number
> of areas where automation may be helpful in processing disclosure requests,
> which we should take in to consideration.
>
>
>
> However, the notion of *“automatic disclosure”* (which to me, includes
> the decision and actual action/performance of disclosure) is not one that I
> imagine could be worked out, without infringing on the rights of
> registrants. I’m open to listening to why some might find that to be
> incorrect or not a sufficient deterrent, but right now, my view is likely
> the opposite of the IPC’s. I don’t believe we should be recommending a
> policy that allows for automatic disclosure under any circumstance.
>
>
>
> So regarding action item 1, this part of the discussion should not result
> in any update to the Accreditation Building Block. Like Volker said, there
> is no agreement on this specific point.
>
>
>
> Thanks.
>
>
>
> Amr
>
>
>
> On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann at key-systems.net>
> wrote:
>
>
>
> Hi JK,
>
> we are not disagreeing here, I think, just trying to clarify our
> understanding. I also agree to that principle.
>
> Best,
>
> Volker
>
> Am 21.10.2019 um 12:48 schrieb Janis Karklins:
>
> Volker,
>
>
>
> I had impression that the principle that "SSAD should be as much automated
> as possible and standardized for the rest" was agreed by all groups in the
> Team already a while ago.
>
>
>
> When we are thinking about implementability and scaleability of the
> system, ambiguities in formulations may not be helpful. I understand that
> on some issues groups may have divergent or even opposing opinions. We
> should be as flexible as possible and as precise as possible and look at
> the SSAD as a package of different compromises by all groups.
>
>
>
> JK
>
>
>
> On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann at key-systems.net>
> wrote:
>
> Hi Alex,
>
> thank you for your response. I don't think that anyone opposes the idea
> that certain aspects of the system can and should be automated, however
> that is not the general usage of the term in this group so far. "To
> automate" was always discussed in the context of automating the disclosure
> decision, and in that context, we cannot support this language.
>
> I think it would be helpful if we were all more clear in what we mean when
> we use certain words.
>
> Automating completeness, error checking and notices of receipt makes sense
> and it would be very much appreciated if the system takes care of that for
> us, but that is not what we mean by "automation".
>
> To your last points, I think we have established that all requests will
> likely be those of the 6.1.f. variety, and those all include that notorious
> balancing test which needs to take into consideration facts that are not
> part of the request and in my view cannot be automated.
>
> My personal position on this is that this point can be left open:
>
> If a disclosing CP feels that they can automate that part as well, they
> should be able to do so, but we should not mandate it. So by striking the
> reference at this point, we do not prohibit such automation, but we also do
> not mandate it. That strikes me as a workable compromise between our
> positions, won't you agree?
>
> Best,
>
> Volker
>
> Am 20.10.2019 um 19:02 schrieb Alex Deacon:
>
> Volker and all,
>
>
>
> Our thoughts on the topic of automation.
>
> The IPC objects to any policy that does not allow for the automation of
> request/response processing. Once again I remind everyone we are
> defining policy for a *system* that will be RDAP based - not a process that
> is based on "old fashioned" technology like smoke signals, wax sealed
> correspondence written by quill and ink, telex messages, faxes or email.
> (We already did this in Phase 1 Rec 18)
>
> Clearly we want a policy that allows for the automation of syntax checking
> of incoming requests, resulting in an automatic response that indicates the
> errors to the requestor. This automation addresses the risk of filling up
> the request queues of the discloser with malformed requests.
>
> Clearly we want a policy that allows for the automation of checking that
> the contents of a request is complete, based on policy we are setting in
> another building block, resulting in an automatic response that details
> what is be missing (per policy). This automation allows for the
> discloser to indicate - without human intervention - what additional
> information is required per policy and enables the requestor to address the
> error.
>
> Clearly we want a policy that allows for the automation of an immediate
> and synchronous response that indicates the receipt of a valid request and
> some indication that it will be processed. Typically such responses
> include a "ticket number" or some kind of uniqueID to allow for future
> queries (status, updates, deletion, etc.). This automation allows for
> efficient queue management on the disclosers side and assists in ensuring
> our principal of "predictability" is met for the requestor.
>
> It is important to note that in none of the three points above do I state
> or even suggest that automation will or can result in the automatic
> response of non-public data.
>
> However having said that - there is no doubt in my mind that there will
> exist some subset of well formed, valid, complete, properly identified and
> accredited requests for some subset of legal basis and some subset of
> purposes that indeed can be automatically processed and result in the
> disclosure of non-public RDS data without human intervention. The IPC
> would object to any policy language that would explicitly forbid this from
> ever happening.
>
> Thanks.
> Alex
>
> ___________
>
> *Alex Deacon*
>
> Cole Valley Consulting
>
> alex at colevalleyconsulting.com
>
> +1.415.488.6009
>
>
>
>
>
>
>
> On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann at key-systems.net>
> wrote:
>
> Hi Caitlin,
>
> I don't think 4.B) Principle B:
>
> · What does accreditation mean? The group discussed the potential
> for allowing for the automatic disclosure where allowed under the law
> suggest “and automation of responses where possible under applicable law”
>
> truly captures the content of our disscussion. The draft should only
> contain agreed language and the inclusion of "and automation of" was very
> much not agreed. In fact this language was opposed by a large group and
> therefore should be removed unless approved.
>
>
>
> --
> 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.
>
>
>
>
>
> On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <
> caitlin.tubergen at icann.org> wrote:
>
> Dear EPPD Team:
>
>
>
> Please find below the notes and action items from today’s EPDP Team
> meeting.
>
>
>
> The next EPDP Team meeting will be *Tuesday, 22 October* at 14:00 UTC.
>
>
>
> Best regards,
>
>
>
> Marika, Berry, and Caitlin
>
>
>
> *EPDP Phase 2 - Meeting #25*
>
> *Proposed Agenda*
>
> Thursday, 17 October 2019 at 14.00 UTC
>
>
>
> *Action Items*
>
> 1. Support Staff to update the text of the Accreditation Building Block
> <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit>
> and Financial Sustainability Block
> <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit>
> based on today’s discussion.
> 2. EPDP Team to provide additional edits in the Accreditation Building
> Block
> <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit>
> re: implementation guidance and definitions by COB tomorrow, *Friday,
> 18 October*.
> 3. EPDP Team to provide additional edits from today’s conversation to
> the Financial Sustainability Block
> <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit>
> by *Friday, 18 October*.
> 4. EPDP Volunteers needed to propose initial text for Building Block M
> – Terms of Use/Disclosure Agreements/Privacy Policies
> <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit>
> by * Monday, 21 October*.
>
> 1. Roll Call & SOI Updates (5 minutes)
>
>
>
> 2. Confirmation of agenda (Chair)
>
>
>
> 3. Welcome and housekeeping issues (Chair) (5
> minutes)
>
> a) Update from legal committee
>
> b) Status of building blocks
> <https://community.icann.org/x/k5ICBw>
>
> 4. Accreditation
> <https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit>
> (building block f and j) – second reading continued (30 minutes)
>
> a) Overview of implementation guidance section
>
> b) Feedback from EPDP Team
>
> Principle b
>
> · Requirements should be spelled out as part of the policy
> discussion
>
> · There will be different types of entities and may have
> different documentation to provide
>
> · These requirements should be as uniform as possible
>
> · C may need to come before B
>
> · There needs to be an underlying baseline of requirements that
> are uniform.
>
> · Accreditation is all about identification; thought the group
> agreed that accreditation is at a minimum about identity, but it could also
> establish other things as well – such as law enforcement, cyber security,
> etc.
>
> · It would be helpful to draw a line b/w the accreditation
> process and what needs to be included in the disclosure request – parties
> seeking accreditation should probably not have to include every scenario
> where a law enforcement would have to interface with the SSAD – hoping the
> Team can be more specific with baseline requirements for accreditation
>
> · Law enforcement will likely have a different accreditation
> system than other entities, so that conversation should be separate
>
> · What does accreditation mean? The group discussed the potential
> for allowing for the automatic disclosure where allowed under the law
> suggest “and automation of responses where possible under applicable law”
>
> · Accreditation does not equate to automated response by default
> – each query will be decided upon on its own merits
>
> · Certain types of people (user groups) may allow for
> streamlining – some categories may involve more scrutiny – to that extent,
> accreditation is more than authentication of identity
>
> · By adding too much into one subject, the discussion is
> encumbered. The discussion of accreditation and authentication should be
> decoupled.
>
> · The small team for accreditation agreed that accreditation is
> not authorization. It might be desirable and helpful to have attributes
> associated with accreditation. The only attribute that will consistently
> make a difference is whether it is law enforcement or not. With respect to
> cyber security researchers, any IT person could legitimately claim to be
> doing cyber security research. There shouldn’t be entry barriers that say
> you are or are not cyber security researchers.
>
> · The building block includes a list of definitions, which the
> Team has not yet discussed.
>
> · If accreditation only proves identity, the Team is limiting
> what it can discuss with regard to the release of data.
>
> · Support Staff to try to analyze what was said during the
> conversation with respect to Subpoint B and Subpoint C for online
> consideration
>
> Principle d
>
> · What is the expectation for what de-accreditation means?
>
> · Accreditation would be that the accreditation is who they say
> they are; as a result, there is access to the system without further
> verification of identity. If an entity is de-accredited, it would need to
> be re-accredited.
>
> · This would mean that the authority could revoke access to the
> system, not “de-accredit”.
>
> Principle g
>
> · What is the accreditation policy and requirements – where is
> this?
>
> · The accreditation policy and associated requirements have not
> been drafted/implemented yet
>
> Principle i
>
> · Issue with replaced “must be paid for service” with
> “cost-recovery system” – this could suggest that the costs need to be
> covered by another form. The whole system is for the benefit of third-party
> users who would request disclosure of registration data – concerned with
> costs being shifted to registrants
>
> · Two types of costs involved – development and deployment of the
> system and then the cost of day-to-day running of the system
>
> · The costs need to be considered in a cost-recovery system. The
> purpose of accreditation is to lower these costs. Whatever cost-recovery
> system takes place – these costs need to be recovered from the users of the
> system, not from registrants or contracted parties.
>
> · Have issues with the terms “significantly reduce”. This is a
> separate system. The Team really needs to consider a cost-benefit analysis
> of figuring out someone’s ID – how much will this actually cost? Is it
> achievable?
>
> · Perhaps the second sentence could be moved to Block N.
>
> · There are two sets of development costs – accreditation system
> and SSAD. This paragraph should be limited to the development of the
> accreditation system. Re: development of SSAD – that should be moved to
> Building Block N.
>
> · Agree with moving the second sentence to Building Block N. If
> the benefit exceeds the cost, there needs to be an escape valve in the
> policy. As a policy principle, it should be the benefits of the SSAD system
> must outweigh the costs.
>
> · If there are too many requirements, the system will be too
> expensive. Avoid saying the costs outweigh the benefits. This language
> needs more work to make it clear what the team is after.
>
> · Maintain first sentence and delete second sentence
>
> · This conversation can be moved to the financial building block.
>
> · Registrants do get something from the SSAD – a reliable and
> secure DNS. The SSAD is not a clean slate – the current system is the
> registrars having to do the work themselves, and someone is paying for
> this.
>
> · There is a clean and reliable DNS system today – to say
> “cleaner” and “more reliable” would be preferable. Costs may be occurring
> in other areas that are offset for a system that doesn’t currently exist is
> problematic and disproportionate.
>
> Principle k
>
> · The use of the word “tagging” is confusing
>
> · Marc to submit proposed updated online
>
> · What is the meaning b/w the first and second sentence?
>
> · The SSAD takes requests from accredited and unaccredited users,
> so unaccredited users will be treated a different way. RDAP is a query
> response protocol, where you query the system and get a response back.
> There will now be instances where some queries will be responded to right
> away and others will be queued (for balancing tests have to be conducted)
> and the response will be returned later – RDAP was not designed to be used
> in this way.
>
> · The second sentence in k does not make sense.
>
> Implementation Guidance Feedback
>
> · Drafting note c – legitimate and lawful purpose described above
> (stated)
>
> · Some implementation belongs in the policy – a and b could be
> left in implementation guidance. C and D could be left in the policy
> language as opposed to implementation guidance.
>
> · De-accreditation – this will depend on what the specifics of
> accreditation are and what it would mean for someone to be de-accredited
>
> · At the F2F, the Team talked about de-accreditation for the
> users of the system and the accrediting entities. E and G are potentially
> in conflict with each other.
>
> · What does access to the system mean? Even bad actors should
> have access to the public data.
>
> · This hinges on unaccredited users having access to the system –
> is the SSAD being used by everyone, or just accredited users?
>
> · Can the Team agree that the SSAD could be used by both
> accredited and non-accredited users? The difference is that accredited
> entities will query the system w/o verification of the entity.
>
> · SSAD should be usable by everyone and not exclude anyone
>
> · How one does identity verification is a decision ICANN should
> be making in the public interest.
>
> · Concern that individuals should not be prevented from getting
> access to data they may need to protect their domain name
>
>
>
> c) Confirm next steps
>
> · Support Staff to update the text of the Accreditation Building
> Block based on today’s discussion. EPDP Team to provide additional edits in
> the Google Doc for implementation guidance and definitions by COB tomorrow,
> Friday, 18 October.
>
> 5. Financial Sustainability
> <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit>
> (building block n) – second reading
>
> a) Overview of updates made following first reading
>
> b) Feedback from EPDP Team
>
>
>
> · Third paragraph: cost-recovery basis is used in multiple
> places. The Team needs to define this term. Cost-recovery is a term of art
> in accounting, and that definition is probably not what the Team meant here.
>
> · Cost recovery may mean different things to different people.
> Also, what does “historic costs” mean in this context? The users of the
> system should be sustaining the capability of the system on an ongoing
> basis.
>
> · Second paragraph – object to contracted parties bearing the
> costs.
>
> · Different parties will bear different costs – this language
> does not explain that division of responsibilities. For example, accredited
> entities will bear the costs of getting accredited. The parties who are
> receiving the queries that contracted parties would be responsible for
> setting up their systems to receive queries and respond to them.
>
> · Registrants being beneficiaries of the system may be a tenuous
> argument
>
> · Fourth paragraph – in favor or usage-based fees that sustain
> the operation of this system.
>
> · A system cannot be costed out unless we know what the system is
> designed to do.
>
> c) Confirm next steps
>
>
>
> 6. Terms of use / disclosure agreements /
> privacy policies
> <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit>
> (building block m) – first reading
>
> a) Review building block
>
> b) Feedback from EPDP Team
>
> c) Confirm next steps
>
>
>
> 7. Wrap and confirm next EPDP Team meeting (5
> minutes):
>
> a) Tuesday 22 October 2019 at 14.00 UTC
>
> b) Confirm action items
>
> c) 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.
>
> _______________________________________________
> 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.
>
> _______________________________________________
> 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/20191021/504a18db/attachment-0001.html>
More information about the Gnso-epdp-team
mailing list