Note
Notes/ Action Items Action Items Policy Support Staff to send an updated write-up of assignments 1 and 2. The updated write-up will include numbered and highlighted proposed compromises for areas where members of the Scoping Team disagree. (sent – please see email) Following receipt of the updated write-up (under action item 1), Scoping Team to review the highlighted portions of the write-up and flag any proposals (using the corresponding number) to indicate proposed compromises that are unacceptable. For proposals that are flagged as unacceptable, please provide alternate language by COB Wednesday, 8 June. Scoping team to provide any further comments, and especially alternative proposals for consideration, for section 2.1.2 (measurement of whether current goals are met) ASAP, but no later than Wednesday, 8 June. Registration Data Accuracy Scoping Team – Meeting #32 Thursday 2 June at 14.00 UTC Welcome & Chair Updates (5 minutes) Scenarios for EDPB - see update from ICANN org (https://mm.icann.org/pipermail/gnso-accuracy-st/2022-May/000444.html) (15 minutes) Continue review of Scoping Team input (see https://docs.google.com/document/d/1rCBaQ175p_VrP6DtxLUuuoO9Uv5C2qp_/edit [docs.google.com]) Invited Elena Plexida to the call, as she is a leader of this engagement work As part of the government engagement team at ICANN, engaging with DPAs is part of my work Plan to send a high-level letter to the EC later this week. The idea is to ask whether the EC would be willing to help introduce this issue at the EDPB. Learned to never ask a question at trial that you don’t know the answer to – would assume this formal request would have a certain time element attached to it The last formal exchange with the DPAs was in 2020 – at that time, at the urging of the EC, ICANN engaged with the Belgian DPA. When ICANN had this exchange with the Belgian authority, it was the Belgian authority that said that these questions are global and this exchange should occur at the level of the EDPB. In the meantime, ICANN org will be doing background work with the scenarios. This week, ICANN will send a letter to the EC will submit a letter to the EDPB, if the EC says no, ICANN will move forward with the engagement independently. Couldn’t this question just be asked without a formal letter? Asking the EC formally in order to strengthen the request; having the EC as a political ally is helpful – however, ICANN can still reach out to the EDPB independently. There have been times where ICANN uses examples that are too high-level. Would be helpful to better build out this program. Understand that there will be interactions with the EC; we even have someone on this team. This is just a confirmation that the EC will work with us. Do not think that having the answers to these scenarios should not hold up the work in the accuracy scoping team – do not see why the work needs to be paused until the answers are received. EC does not have control over what other institutions (like the EDPB) do. The EC, however, cannot be the penholder for the scenarios; ICANN should just submit the scenarios directly to be the most efficient. That said, will take a look at the wording of the scenarios. The question at hand is a procedural one – will the EC help send the questions. Appreciate that ICANN is taking another approach with the EC; agree that this is ICANN’s work to do – appreciate the update Thank you for engaging with this team. The group is looking at providing access to data to the US, so that has international data transfer aspects to it Will the community be able to see the scenarios before they are shared? ICANN is making the request; the community is not making a risk assessment for them – not sure we need to get into the specifics of the scenario now Regardless of the outcome of the EC request, ICANN will still have to submit the scenarios. Believe there has been an outgoing request for a DPIA for years and believe this engagement should also involve the community. Currently, ICANN is in a tricky space – the assessment will have a lot of privileged and confidential data in it. Have not yet discussed what can be shared with the community, though would like to maintain an open dialogue. At what point do domain name holders have a right to know how ICANN is processing their data? GDPR provides that data subjects can inquire how their data is processed. Expanded on original ALAC comments – added additional flavor. If the group is going to ask questions about other types of accuracy, that is something that should be discussed here – maybe want to look past what the 2013 RAA says and look at other scenarios. Agree that scenario 1 doesn’t seem fruitful. Scenario 2 seems especially worthwhile, particularly if we targeted lists of phishing or abusive domain names. No objection to Scenario 3 or 4. Have to be as specific as possible in order to get specific and meaningful guidance. Agree that the merit of asking about Scenario 1 is very limited. The real question is can I have a legitimate interest in data that is not publicly available. Periodic audits need more explanation (perhaps in a footnote) in order to be easily understood by the EDPB. Propose to eliminate Scenario 1, that could help the drafting I think this group is done at this point – propose to draw a line and end the discussion here. There is an incredible rise in phishing and domain name abuse – this should be used in communications. ccTLDs have done great work in reducing ccTLDs issues – if there are examples of communications that have gone back and forth, it would be helpful to see these ccTLDs may have an easier exchange with their respective DPAs, but this isn’t necessarily consistent Believe review of ccTLDs to determine precedent would be very helpful Confirm next steps Write up for Section 2.1.2 – Measurement of whether current goals are met (seehttps://docs.google.com/document/d/1CYs9mLHsKcZevmZtFrQBDXbv_nkQ5PKe/edit [docs.google.com]) (15 minutes) Review input received There was a placeholder in the write-up regarding whether current goals are met – the conversation around EDPB engagement was one part of that; the other proposals are also covered in this write-up. The goal is to integrate this into the write-up. There have been some editorial edits that have been made. There was also a question about flagging incentives. This could be flagged as part of the survey. There are two specific recommendations within this document. There might be a need to pause the work while waiting to see if proposals requiring access to data are worked out. Question: how could assignment 3 start without measuring accuracy? Support Staff is interested to hear how this is envisioned. CPs forgot to add their comments – they were imported into a copy of the document rather than the shared document. Will add in shortly Hesitant to go down these roads and scope out possible tools and they are not in compliance with GDPR per an EPDB decision, concerned about wasting time. Question: what constructive work could we do if we do not pause? Concerned that waiting would delay things even further The survey to registrars should be made mandatory Idea is to finalize this document soon so that it can be submitted shortly after ICANN74 – if there are any additional suggestions, these need to come in ASAP so that the group can review during ICANN74 Confirm next steps Write up for assignments #1 & #2 (see https://docs.google.com/document/d/13sP-2z7rusEYrDyntrgm-tcIavPMJndU/edit[docs.google.com]) (30 minutes) Continue review of input received Support staff has gone through the document and made suggestions regarding how to proceed on the issues. Trying to call out a possible way to deal with disagreements. Suggest sharing the document after this call – could highlight Support Staff’s proposed approach. Ask the group to review and determine if there is anything that is unacceptable Confirm next steps Confirm action items & next meeting (Thursday 9 June at 14.00 UTC)

Note

Notes/ Action Items

Action Items

Policy Support Staff to send an updated write-up of assignments 1 and 2. The updated write-up will include numbered and highlighted proposed compromises for areas where members of the Scoping Team disagree. (sent – please see email)
Following receipt of the updated write-up (under action item 1), Scoping Team to review the highlighted portions of the write-up and flag any proposals (using the corresponding number) to indicate proposed compromises that are unacceptable. For proposals that are flagged as unacceptable, please provide alternate language by COB Wednesday, 8 June.
Scoping team to provide any further comments, and especially alternative proposals for consideration, for section 2.1.2 (measurement of whether current goals are met) ASAP, but no later than Wednesday, 8 June.

Registration Data Accuracy Scoping Team – Meeting #32

Thursday 2 June at 14.00 UTC

Welcome & Chair Updates (5 minutes)
Scenarios for EDPB - see update from ICANN org (https://mm.icann.org/pipermail/gnso-accuracy-st/2022-May/000444.html) (15 minutes)
1. Continue review of Scoping Team input (see https://docs.google.com/document/d/1rCBaQ175p_VrP6DtxLUuuoO9Uv5C2qp_/edit [docs.google.com])
  - Invited Elena Plexida to the call, as she is a leader of this engagement work
  - As part of the government engagement team at ICANN, engaging with DPAs is part of my work
  - Plan to send a high-level letter to the EC later this week. The idea is to ask whether the EC would be willing to help introduce this issue at the EDPB.
  - Learned to never ask a question at trial that you don’t know the answer to – would assume this formal request would have a certain time element attached to it
  - The last formal exchange with the DPAs was in 2020 – at that time, at the urging of the EC, ICANN engaged with the Belgian DPA. When ICANN had this exchange with the Belgian authority, it was the Belgian authority that said that these questions are global and this exchange should occur at the level of the EDPB. In the meantime, ICANN org will be doing background work with the scenarios.
  - This week, ICANN will send a letter to the EC will submit a letter to the EDPB, if the EC says no, ICANN will move forward with the engagement independently.
  - Couldn’t this question just be asked without a formal letter?
  - Asking the EC formally in order to strengthen the request; having the EC as a political ally is helpful – however, ICANN can still reach out to the EDPB independently. There have been times where ICANN uses examples that are too high-level. Would be helpful to better build out this program.
  - Understand that there will be interactions with the EC; we even have someone on this team. This is just a confirmation that the EC will work with us.
  - Do not think that having the answers to these scenarios should not hold up the work in the accuracy scoping team – do not see why the work needs to be paused until the answers are received. EC does not have control over what other institutions (like the EDPB) do. The EC, however, cannot be the penholder for the scenarios; ICANN should just submit the scenarios directly to be the most efficient. That said, will take a look at the wording of the scenarios.
  - The question at hand is a procedural one – will the EC help send the questions.
  - Appreciate that ICANN is taking another approach with the EC; agree that this is ICANN’s work to do – appreciate the update
  - Thank you for engaging with this team. The group is looking at providing access to data to the US, so that has international data transfer aspects to it
  - Will the community be able to see the scenarios before they are shared?
  - ICANN is making the request; the community is not making a risk assessment for them – not sure we need to get into the specifics of the scenario now
  - Regardless of the outcome of the EC request, ICANN will still have to submit the scenarios. Believe there has been an outgoing request for a DPIA for years and believe this engagement should also involve the community.
  - Currently, ICANN is in a tricky space – the assessment will have a lot of privileged and confidential data in it. Have not yet discussed what can be shared with the community, though would like to maintain an open dialogue.
  - At what point do domain name holders have a right to know how ICANN is processing their data? GDPR provides that data subjects can inquire how their data is processed.
  - Expanded on original ALAC comments – added additional flavor. If the group is going to ask questions about other types of accuracy, that is something that should be discussed here – maybe want to look past what the 2013 RAA says and look at other scenarios.
  - Agree that scenario 1 doesn’t seem fruitful. Scenario 2 seems especially worthwhile, particularly if we targeted lists of phishing or abusive domain names. No objection to Scenario 3 or 4.
  - Have to be as specific as possible in order to get specific and meaningful guidance. Agree that the merit of asking about Scenario 1 is very limited. The real question is can I have a legitimate interest in data that is not publicly available. Periodic audits need more explanation (perhaps in a footnote) in order to be easily understood by the EDPB.
  - Propose to eliminate Scenario 1, that could help the drafting
  - I think this group is done at this point – propose to draw a line and end the discussion here.
  - There is an incredible rise in phishing and domain name abuse – this should be used in communications. ccTLDs have done great work in reducing ccTLDs issues – if there are examples of communications that have gone back and forth, it would be helpful to see these
  - ccTLDs may have an easier exchange with their respective DPAs, but this isn’t necessarily consistent
  - Believe review of ccTLDs to determine precedent would be very helpful
2. Confirm next steps
Write up for Section 2.1.2 – Measurement of whether current goals are met (seehttps://docs.google.com/document/d/1CYs9mLHsKcZevmZtFrQBDXbv_nkQ5PKe/edit [docs.google.com]) (15 minutes)
1. Review input received
  - There was a placeholder in the write-up regarding whether current goals are met – the conversation around EDPB engagement was one part of that; the other proposals are also covered in this write-up. The goal is to integrate this into the write-up. There have been some editorial edits that have been made. There was also a question about flagging incentives. This could be flagged as part of the survey.
  - There are two specific recommendations within this document. There might be a need to pause the work while waiting to see if proposals requiring access to data are worked out.
  - Question: how could assignment 3 start without measuring accuracy? Support Staff is interested to hear how this is envisioned.
  - CPs forgot to add their comments – they were imported into a copy of the document rather than the shared document. Will add in shortly
  - Hesitant to go down these roads and scope out possible tools and they are not in compliance with GDPR per an EPDB decision, concerned about wasting time. Question: what constructive work could we do if we do not pause?
  - Concerned that waiting would delay things even further
  - The survey to registrars should be made mandatory
  - Idea is to finalize this document soon so that it can be submitted shortly after ICANN74 – if there are any additional suggestions, these need to come in ASAP so that the group can review during ICANN74
2. Confirm next steps
Write up for assignments #1 & #2 (see https://docs.google.com/document/d/13sP-2z7rusEYrDyntrgm-tcIavPMJndU/edit[docs.google.com]) (30 minutes)
1. Continue review of input received
  - Support staff has gone through the document and made suggestions regarding how to proceed on the issues. Trying to call out a possible way to deal with disagreements. Suggest sharing the document after this call – could highlight Support Staff’s proposed approach. Ask the group to review and determine if there is anything that is unacceptable
2. Confirm next steps
Confirm action items & next meeting (Thursday 9 June at 14.00 UTC)

Content

Space Tools

Versions Compared

Old Version 10

New Version Current

Key