[Gnso-epdp-team] Notes and action items from EPDP Meeting #41 - 23 Jan 2020

Janis Karklins karklinsj at gmail.com
Fri Jan 24 07:10:42 UTC 2020

Thank you, Caitlin, for listing homework items.

I would like to reiterate, that it would be very useful if Team members
could suggest what functions the suggested "body/entity" (committee,
unit...) could perform ensuring thoughtful evolution of the model from
fully decentralized disclosure decision making (hybrid model) to more
automated disclosure decision making (centralized model). Should this
"body/entity" be supervised and by whom?

Thank you and safe travels

On Fri, Jan 24, 2020 at 1:04 AM Caitlin Tubergen <caitlin.tubergen at icann.org>

> Dear EPDP Team,
> Please find below the notes and action items from today’s EPDP Team
> Meeting.
> For all those attending: safe travels to the F2F meeting, and see you soon!
> Best regards,
> Marika, Berry, and Caitlin
> *--*
> *Action Items*
> 1. EPDP Support Staff to send Legal Q2, which has been approved by the
> plenary team, to B&B for its review.
> 2. EPDP Team to review the GAC proposal on accreditation of public
> authorities in advance of the F2F meeting.
> 3. EPDP Leadership and Support Staff to consider today's discussion and
> prepare an agenda for the F2F meeting to be distributed on Sunday, 26
> January.
> 4. EPDP Team to submit additional feedback on today's discussion and the
> EPDP Leadership-proposed chameleon model by 14:00 UTC on Sunday, 26 January.
> *EPDP Phase 2 - Meeting #41*
> *Proposed Agenda*
> Thursday, 23 January 2020 at 14.00 UTC
> 1.                            Roll Call & SOI Updates (5 minutes)
> 2.                            Confirmation of agenda (Chair)
> 3.                            Welcome and housekeeping issues (Chair) (5
> minutes)
> a)                      Update from the legal committee
>    - Following this call, a document which includes the rationale for
>                posing each question will be provided. Regarding Reverse Look-ups, the
>                legal committee thought the question was still relevant as the question for
>                reverse look-ups as there was a proposal to prohibit reverse look-ups.
>                - The path forward for this – Thomas raised a point of
>                order whether this is in scope, and it is the Chair’s authority to rule on
>                that. Alternatively, the Team could remove the bracketed language.
>                - Legal Committee recommends the legal questions should be
>                sent out.
>                - Re: legal vs. natural questions, NCSG noted the
>                outstanding policy question should be answered before legal questions are
>                pursued. The LC believes that in order for ICANN to carry out the
>                feasibility exercise, the questions would be helpful to inform this
>                exercise. The LC is seeking clarification of the existing legal advice.
>                - Territorial scope – B&B provided legal guidance on the
>                territorial scope of GDPR and the advice and updated EPDB guidance could be
>                relevant here. The LC believes given the Board’s note re: geographic
>                differentiation, the implications of the two events would be helpful.
>                - WHOIS accuracy – follow-up clarification questions on
>                B&B’s previous advice re: relevant parties – who may be included in this
>                with respect to GDPR roles. LC also agreed it would be helpful to have
>                practical guidance with respect to this.
>                - Re: reverse look-ups, there is no agreement on this
>                particular topic, so it would be wise to indicate that on that particular
>                topic, there is no agreement within the Team, so the Team is seeking
>                community feedback on this point.
>                - Regarding reverse look-ups, the Initial Report or Final
>                Report should remove all references to reverse look-ups. If the Team
>                believes this should be dealt with at some point, it could flag it for a
>                future PDP.
>                - Question utility on putting reverse look-ups out for
>                public comment – agree that this is out of scope, so the Team is not
>                endorsing or prohibiting it
>                - May be foolish to NOT get legal advice on this now
>                - Disagree that just b/c B&B is available means the Team
>                should ask advice
>                - There is no objection to Q2. There is no consensus re:
>                reverse look-ups. Therefore, the Team will not send the question regarding
>                reverse look-ups.
>                - Object to territorial scope and the legal vs. natural
>                question
>                - Agreement to send Q2. The other questions need further
>                discussion with the Legal Committee.
>                - Accuracy question – NCSG reads this as accuracy is a
>                right of the data subject
>                - Action: EPDP Support Staff to send Q2 to B&B for its
>                review.
> b)                     ICANN follow up on Belgian DPA response to
> Strawberry letter – see questions suggested by Marc Anderson:
> ·      Is ICANN expecting an additional communication on the Strawberry
> letter?
> ·      Would ICANN org like feedback from the EPDP Team before it meets
> with the Belgian DPA?
>    - The EC has been helping ICANN facilitate a meeting with the Belgian
>                DPA – was hoping to have this meeting before the F2F, but this has not
>                happened.
>                - EC believes it would be useful to have a meeting with
>                the Belgian DPA
>                - There is no set date yet for this meeting, but trying to
>                set meeting as early as possible in February
>                - Synopsis: work is ongoing, and there is no update yet,
>                but hoping for an update in the near future
> 4.       Introduction of Proposal for an SSAD Hybrid able to evolve to a
> Centralized and Automated Model (“The Chameleon”)
> a)                      Staff overview
>    - Attempt from Leadership and Staff to review the CPH proposal and
>                reactions to it and the small team’s input and come forward with a proposal
>                - Attempt to add flexibility and meaningful SLAs
>                - Took the recommendations in the draft Initial Report and
>                adding additional specificity
>                - The basics of the model – the requestor submits a
>                disclosure request to the central gateway (performed or overseen by ICANN
>                org) – the central gateway would determine if the request meets the
>                criteria for an automated response or if it needs to go to the CP for review
>                - There is an assumption that at the outset bucket 4 would
>                be substantially larger than what is in bucket 5, but through experience
>                gained or additional legal guidance, more requests may shift to bucket 5
>                - Another new concept introduced in the hybrid-hybrid
>                model is the steering committee – the underlying idea is should there be a
>                mechanism that allows for the evolution over time without requiring a new
>                PDP each time– maybe there is not, but this is an initial proposal for
>                discussion.
>                - This is similar to the CSC to IANA-PTI to follow SLAs
>                and the performance of PTI and enhance these over time – this is more used
>                as a concept – is this necessary or is there a way that the evolutionary
>                model could be captured?
>                - Went through preliminary recommendations in the latest
>                version of the Initial Report – the comments raised have been removed for
>                ease of reading, but those comments will be dealt with via the issues list
>                - There are now two preliminary recommendations about
>                automated disclosure requests to accommodate the two branches in the
>                previous diagram
>                - SLAs have been included – is there a way to help predict
>                what will come in
>                - Some of the other changes deal with who would be dealing
>                with what
>                - In reference to the steering committee, this is an
>                initial proposal – this is not intended to circumvent policy rules – it is
>                trying to find a compromise solution from the various proposals.
> b)                     EPDP Team reactions
>    - Having a roadmap around how to allow future automation will be
>                helpful. Maybe a function or a group can evolve this as more legal
>                certainty is gained.
>                - Strongly support the model – getting something close to
>                what the different group could support. The document references shifting
>                liability – we should not be talking about shifting liability. Strongly
>                support the work of standing committee, but it should not be making policy
>                decisions. There should not be a jointly-appointed rep for NCSG/ALAC.
>                - Under current model, the only way to create contractual
>                obligations on CPs is through a PDP. This group would not be wading into
>                policy waters, only on implementation automation – this group cannot
>                self-determine what is a policy question – that needs to go somewhere else
>                like the GNSO Council. Looking at the broader view from groups are critical
>                of the ICANN model, this seems to show that the PDP is not fit for purpose.
>                This is the wrong approach – the right approach would be to fix the PDP. If
>                the proposal is for a group outside of the PDP that could impact the
>                contract, that is too big of a loophole/wildcard/variable for contracted
>                parties to accept. Critics of the MSM will pounce on this as evidence that
>                the MSM is not working.
>                - Standing PDP could be an alternative to a standing
>                committee
>                - Do not support an external group that is designed to
>                exclude non-commercial users from decision-making. The CSC is not an
>                appropriate precedent. Question the need for evolution – the EPDP Team can
>                come up with an automated model for certain disclosures – there can be
>                evolution of procedures and technologies, and there can be oversight of
>                that through the GNSO Council.
>                - Would need a Privacy Impact Committee to assess the
>                impact of this
>                - New draft is closer to what can be published for initial
>                comment – there are problematic elements but can discuss these at the F2F
>                - Need to call out automation where legally permissible
>                and technically feasible.
>                - There could be standing IRT-like group to assist in the
>                evolution
>                - Modeling a steering committee after the CSC is very good
>                – the membership will be different b/c the customers and functions are very
>                different
>                - Will the committee have the responsibility where the
>                decision making for the disclosure request can be done through automated
>                means?
>                - Have to discuss the safest way to get legal certainty is
>                to get this approved as a code of conduct under the GDPR
>                - Action: EPDP Team to review the GAC proposal on
>                accreditation of public authorities
>                - Action: Leadership and Staff will consider today’s
>                discussion and prepare the F2F meeting in the best possible way
>                - Action: EPDP Team can prepare additional feedback to
>                assist Leadership in developing next week’s F2F agenda
> c)                      Confirm next steps
> 5.                            Plans for F2F meeting in Los Angeles
> a)                     Leadership Priorities
> b)                     EPDP Team input
> c)                      Confirmation of expected homework / preparations
> by EPDP Team for the LA F2F meeting
> d)                     Confirm next steps
> 6.                            Continue review of issues list (those items
> not dependent on item #4), if time allows
> a)                     See highlighted items on the issue list
> b)                        EPDP Team input
> c)                      Confirm next steps
> 7.                            Wrap and confirm next EPDP Team meeting (5
> minutes):
> a)                      Monday 27 January 2020 at 9.00 local time at the
> ICANN office
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200124/09bba099/attachment-0001.html>

More information about the Gnso-epdp-team mailing list