[Gnso-epdp-team] Notes and action items - EPDP Phase 2A Meeting #09 - 4 March 2021

Stephanie E Perrin stephanie.perrin at mail.utoronto.ca
Tue Mar 9 14:05:41 UTC 2021

Could someone please forward the link for the meeting ?  Thanks!


On 2021-03-04 2:54 p.m., Caitlin Tubergen via Gnso-epdp-team wrote:
> Dear EPDP Team,
> Please find below the notes and action items from today’s meeting.
> As a reminder, the next plenary meeting will be Thursday, 11 March at 
> 14:00 UTC.
> Best regards,
> Berry, Marika, and Caitlin
> -- 
> *_Action Items_*
> Please remember to check for action items using the team’s Workplan 
> and Action Items sheet: 
> https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdVdrRIdrw/edit#gid=0 
> <https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdVdrRIdrw/edit#gid=0>.
> *EPDP Phase 2A - Meeting #09*
> *Proposed Agenda*
> Thursday 4 March 2021 at 14.00 UTC
> 1.Roll Call & SOI Updates (5 minutes)
> 2.Welcome & Chair updates (Chair) (5 minutes)
>      1. Upcoming update to GNSO Council on status of progress (24
>         March 2021)
>               o Keith has an obligation to report back to the GNSO
>                 Council on the status of the group’s progress. Three
>                 weeks from now, Keith has to provide a report to the
>                 Council. The work over the next few weeks is critical
>                 – to demonstrate to the Council that progress is being
>                 made, and that there is a path to consensus.
>               o Reminder to please do homework – it’s critical for the
>                 group’s progress. It’s imperative that the team picks
>                 up the pace.
>               o Thoughts from Philippe (GNSO Council liaison): in
>                 capacity as liaison to Council, reiterate Keith’s
>                 previous points. Council meeting is scheduled for 24
>                 March. A case will need to be made to Council by this
>                 time.
>               o EPDP feedback: concerned that legal advice will still
>                 be outstanding when an update needs to be made.
>               o If legal questions are agreed to and submitted, this
>                 would help the case, but this has not happened yet.
>                 Need to demonstrate to the Council that the group is
>                 on track to deliver an Initial Report by.
>               o Suggest that the team plow ahead with the work and
>                 incorporate the legal advice into the evolution of the
>                 SSAD
>               o Keith has an obligation to deliver an update to the
>                 Council that the group is on track to deliver an
>                 Initial Report by May. Council will be looking at this
>                 with a critical eye as the manager of the PDP process.
>                 Submitting legal questions and demonstrating progress
>                 by this group will be critical.
>               o Hope Council will look at if the group is making
>                 progress to develop a policy, rather than on track for
>                 a specific and arbitrary date
>               o PDP 3.0 guidelines – any group has to commit to a plan
>                 following a cursory review of its charter. B/c the
>                 group started slower than anticipated, leadership made
>                 a decision to commit to delivery of an Initial Report
>                 by the end of May. This is an analysis based on the
>                 amount of work in front of us.
>      2. ICANN org response to EPDP Team questions (see
>         https://community.icann.org/x/I4GBCQ
>         <https://community.icann.org/x/I4GBCQ>):
> ·Status of implementation rec 6/13
> ·ICANN org liability in the context of distinguishing between legal / 
> natural             persons
> ·Please note ICANN org has provided responses to the two questions 
> over the       list; they are now posted on the wiki.
> 3._Legal vs. natural_(75 minutes)
>  1. Whether any updates are required to the EPDP Phase 1
>     recommendation on this topic (“Registrars and Registry Operators
>     are permitted to differentiate between registrations of legal and
>     natural persons, but are not obligated to do so“);
>  2. What guidance, if any, can be provided to Registrars and/or
>     Registries who differentiate between registrations of legal and
>     natural persons.
> a.Update from Legal Committee in relation to questions referred to 
> legal committee on legal / natural (Becky)
>               o Team made significant process during the two
>                 repurposed calls
>               o Legal Team has discussed all questions on both topics
>               o Bulk of legal v. natural questions are out for final
>                 sign-off by Friday
>               o The remaining legal v. natural questions will
>                 hopefully be completed over email.
>               o Aim is to finish up the work on Tuesday – call is
>                 extended to 90 minutes. If everyone does their
>                 homework, reviews all questions, and works online –
>                 should be in a position to finish on Tuesday. Again,
>                 this requires everyone to do their homework.
> b.Follow up questions to Jamboard brainstorming – Proposal 1a
>   * Review responses to leadership follow up questions to input
>     provided on JamBoard (see
>     https://docs.google.com/document/d/1Je23419t1xv7OFgD32-DmBrYknUqtbOt4wktPEj3pko/edit
>     <https://docs.google.com/document/d/1Je23419t1xv7OFgD32-DmBrYknUqtbOt4wktPEj3pko/edit>)
>   * EPDP Team to discuss and confirm updates to be made to proposal 1a
>               o Does the flowchart assist?
>               o BC: yes, but if steps are combined in the user
>                 experience, there would need to be a wireframe webpage
>                 in order to determine if this saves a step in the user
>                 experience
>               o BC: agree that the concern was addressed in previous
>                 recommendations but in terms of how to design a
>                 webpage, have to mention it for completeness
>               o If Rrs or Rys today are differentiating today or might
>                 in the future, what are the possibilities for doing
>                 this that could become best practices or
>                 recommendations for the group to consider?
>               o Is this trip necessary? Yes, if you are going to
>                 differentiate, but that is not accepted by many in
>                 this group. As you can see by the diagram, it is very
>                 complicated. This doesn’t appear to have any benefit
>                 on the public and private interest. If we agree with
>                 the original recommendation that it’s a choice,
>                 delving into the specific process for which they do so
>                 is a waste of this group’s time.
>               o Charter notes what types of practices could be
>                 developed for CPs that want to differentiate or may be
>                 required to differentiate in certain jx
>               o Best practices is not the deliverable here – it is
>                 just one step on the journey
>               o Several team members are trying to engage in
>                 one-on-one conversations with stakeholder
>                 representatives to get a more realistic perspective of
>                 what the real-world business consequences of
>                 differentiation are. We are open to listening and
>                 figuring out your concerns – want to make sure your
>                 customer relationships are preserved. Aware that
>                 reseller model is different than a retail registrar.
>                 There could be a path forward here and want to work
>                 together to create this path.
>               o Urge that we move away from flowcharts and try to
>                 arrive at a result that shows what to do and why to do it
>               o As it relates to the charter for this group, we are to
>                 review best practices. Do the Phase 1 recs that are
>                 consensus policy need to be adjusted? This does not
>                 presuppose that consensus will be achieved. Once we
>                 get through the best practices – based on this, should
>                 the recommendation change?
>               o Caution that a one-size-fits-all model actually only
>                 fits one. Suggest starting with the GDPR principles
>                 and how to achieve each of those principles if you
>                 want to differentiate. Current consensus policy, which
>                 is flexible and allows the registrar to choose, is
>                 appropriate. Guidance does not mean the policy should
>                 be changed.
>               o Tried to address some of these expressed concerns in
>                 the proposal. One concern raised was to consider the
>                 nature of personal data, not just legal v. natural
>                 data. Another concern was some models (like reseller)
>                 cannot take steps before registration, so tried to
>                 make this flexible.
>               o Should first look at why the Phase 1 recommendation
>                 needs to be changed.
>               o As we look towards the outcomes of this group – do we
>                 need to make adjustments to Phase 1 recommendations,
>                 and are there implications to Phase 2 recommendations?
>                 We approached this as a group – what could be possible
>                 – what are the potential best practices, but we will
>                 eventually have to move to how to clarify how existing
>                 policy should be changed (if at all).
>               o We are not being told – rather than look at ways it
>                 could be possible,  now we are being told we need to
>                 look at if group members want to make it possible.
>               o There is still work to be done regarding whether
>                 adjustments to consensus policy are needed or
>                 required. At the end of this process, is there a path
>                 to consensus on changing Phase 1 recommendations.
>               o Perhaps steps 2 and 3 could be collapsed (l v. n and
>                 whether personal data) could be asked in the same
>                 sentence.
>               o Asking someone if they are a legal or natural person
>                 is very confusing to most people, particularly with
>                 language differences. If a registrar can come up with
>                 a safe way of doing this, then the existing consensus
>                 recommendation says they can do this. Flagging people
>                 is a problem.
>               o Confusing the registrant has already been covered;
>                 there are safeguards in place in the GAC proposal. To
>                 be clear, this is about adding a binary flag to
>                 categorize the registrant as either legal or natural
>                 and that comes with benefits for policy choices. This
>                 is just considered to be a useful distinction as part
>                 of a broader proposal.
>               o Work with UE designers and making sure that choices
>                 presented to users are clear is very important –
>                 regarding the flag, if the purpose of the flag is for
>                 how data should be handled, that is already a requirement.
>               o Flag or not, registrar should have a way of
>                 identifying if data should be published or not; how
>                 they do this should be up to them. Ultimately, we are
>                 looking at a registrant making a declaration – no
>                 personal data, therefore publication could be OK. It
>                 could be the same declaration for someone with PII who
>                 wants their info published. The differentiation of
>                 legal v. natural is unnecessary here. We do not need
>                 to ask the legal v. natural question. The ultimate
>                 question is – is there consent to publish this info.
>               o The benefit of formally defining a flag is that it is
>                 standardized and can go into escrow if we want it to.
>                 The question is – do we want a flag for legal v.
>                 natural, we want a standardized flag so that it’s
>                 usable is appropriate. How we set it and if we set is
>                 question for later, but having the flag would be helpful.
>               o Yes, we have a flag, but the legal committee has been
>                 discussing this consent issue. The CP is relying on an
>                 attestation that there is consent to publish. This is
>                 a difficult question – large companies represented
>                 here may be able to assure themselves in most cases
>                 but others may not have a clue.
>               o Consent relates to personal data. In the comments on
>                 the proposal, some argued that legal v. natural is
>                 difficult and there are language and educational
>                 barriers. However the bar is much higher for consent
>                 under GDPR. Consent should be the last resort b/c the
>                 bar to prove that you have valid consent is very high.
>                 If someone believes the language is not simple enough
>                 for legal v. natural, how can it be valid enough for
>                 someone to provide informed consent? The distinction
>                 b/w legal v. natural is a valuable distinction in many
>                 data protection regimes. Maybe a way to do this if CPs
>                 would want to propose ways they could differentiate.
>   * Confirm next steps
> c.Review remaining proposals & input provided (starting with scenario #1)
>   * See
>     https://jamboard.google.com/d/1H3CDUTITCfgcS85WMjlvyLV07cb7_V7ksFz8lVjExPg/viewer
>     <https://jamboard.google.com/d/1H3CDUTITCfgcS85WMjlvyLV07cb7_V7ksFz8lVjExPg/viewer>
>   * Berry circulated a thought experiment yesterday.
>   * This thought experiment tries to encapsulate a lot of what we
>     spoke about in today’s meeting and before. What is important is
>     that in this is a thought experiment, nothing will happen
>     tomorrow, but, a few years down the road, it may become a
>     requirement to differentiate between legal and natural persons.
>     This thought experiment asks the group to consider what would
>     happen if this was a requirement. Let’s first approach this by
>     what is already in the pipeline to be implemented.
>   * Rec. 6 – touched on this – basically about Rrs providing ability
>     for RNH “consent” to have their info published. Some have already
>     implemented this; others will wait for this requirement to be
>     implemented. This is indirectly related to legal v. natural. How
>     are CPs actually going to implement this and obtain consent?
>     Example – domain investor may wish to have their info published –
>     what would this look like?
>   * Rec. 12 – this is a Phase 1 rec about the Org field.  The second
>     half of the recommendation notes requirements for new
>     registrations beginning on a date certain. On a date certain,
>     registrars have to allow registrants to publish the org field. How
>     does that impact the registration process – how will this be
>     implemented?
>   * Rec. 17 – which is the ability for CPs to differentiate b/w legal
>     and natural persons  should they choose to. Are some CPs going to
>     do this – what about brand protection models? If so, how are they
>     going to go about doing this?
>   * Phase 2 – recognizing that only the Council has adopted the Phase
>     2 recommendations – liability risks. Footnote 39 – there is a
>     requirement for a legal risk fund. Could this group build on this
>     particular concept?
>   * There are a series of questions here and the group should have a
>     frank discussion on all of these.
>   * So much of what we’re talking about ties back to Phase 1 and Phase 2
> _Feedback_
>   * Should not be making consensus policy based on a theoretical law.
>     We are close to agreement that do we want to publish the data or
>     not – and are we giving people a clear path to publishing, if
>     they’d like to publish it. __
>   * It seems clear that the NCSG wants to leave this as a
>     consent-based discretion. This is not what we’re here to do – we
>     are here to relitigate the legal v. natural distinction.__
>   * Please try to keep this from becoming personal.__
>   * We have a consensus policy – the question before us is do we need
>     to adjust the consensus policy.__
>   * The whole time the NCSG has been arguing, there has been law. The
>     fundamental question to be asked here – are you consenting to the
>     release of personal information here/can you consent to the
>     release of personal information here. __
>   * Consent relates to personal data. If there is a registrant
>     providing personal and non-personal data, and they do not consent 
>     – do you also not publish the non-personal information? The
>     distinction is inevitable and serves a purpose. __
> 4.Wrap and confirm next EPDP Team meeting (5 minutes):
> a.Meeting #10 Thursday 11 Marchat 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20210309/eab851ec/attachment-0001.html>

More information about the Gnso-epdp-team mailing list