Notes and action items - RDA Scoping Team Meeting #29 - 12 May 2022
Dear RDA Scoping Team members, Please find below the notes and action items from today’s meeting. Best regards, Marika, Berry, and Caitlin -- 1. Support Staff to translate today’s discussion of proposals into text for the write-up. 2. Support Staff to convert the draft message to the EDPB into a Google Doc<https://docs.google.com/document/d/1rCBaQ175p_VrP6DtxLUuuoO9Uv5C2qp_/edit> for further feedback from the group. Support Staff to include the feedback already provided by individuals. (Note: ideally, the group can provide a unified response to ICANN org regarding how this communication to the EPDB could assist in the Scoping Team's work.) 3. 🚨🚨 Important note: Scoping Team members to provide feedback to the draft write-up<https://docs.google.com/document/d/13sP-2z7rusEYrDyntrgm-tcIavPMJndU/edit> IN COMMENTS FORM ONLY. 🚨🚨 Registration Data Accuracy Scoping Team – Meeting #29 Thursday 12 May at 14.00 UTC 1. Welcome & Chair Updates (5 minutes) * Project Change Request submitted to the GNSO Council (see https://mm.icann.org/pipermail/council/2022-May/025662.html) * For those interested, please review the link above. * ICANN74 session scheduled for Tuesday 14 June from 11.15 – 12.30 UTC (13.15 – 14.30 local time) * Pre-registration is required, and details regarding this will be published shortly. 1. Gap Analysis Data Collection Proposals that do not involve access to registration data (30 minutes)(see https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sScP8MwgDCg4y...>) * The work is currently focused on proposals that do not involve access to non-public registration data. * One proposal being explored is to do an ICANN compliance audit – with that in mind, the group posed some initial questions to compliance * Two colleagues from compliance have joined the call today to answer the group’s questions * At the end of the review of these proposals, the group should consider if there is a recommendation for a consideration of the proposal and why or why not. a. Proposal D - Registrar Audit * Opportunity to discuss further with ICANN Compliance * Compliance developed a written response, which includes multiple options: * Auditing without personal information – this would be limited to requesting information regarding the processes registrars use for the verification and validation requirement * Based on input from the EDPB or similar authorities, Compliance would be more certain what it is allowed to do. It is correct that you can get redacted data in response to a complaint or inquiry (3.4) but not related to a compliance audit. Further information is necessary in terms of what could be asked for in an audit. * If Compliance sends an inquiry or questionnaire, this is not a true audit. A true audit is when data is verified against substantive information. * Based on this information from Compliance, would an audit like this be helpful for the group in Assignments 3 and 4? * In doing these audits, does ICANN send tailored questions based on the respective business model that the registrar is operating (retail, wholesale, etc.)? If there is only one template, how are differences accounted for? * When audit questions are sent to contracted parties, the questions are not tailored to specific business models. * Follow-up questions may be sent based on the registrar’s initial responses. For example, if there is an obligation to send a reminder to a registrant regarding the expiration of a domain, and a registrar says, “our resellers do this,” Compliance would say – please show examples of this. Compliance would not contact the reseller directly since ICANN does not have a contractual relationship with the reseller. * Does Compliance attempt any verification that the registrar is indeed telling the truth? * Under the current scenario, compliance is not in a position to measure the accuracy of data; what they could do is audit registrars to confirm if their obligations are being followed under the Accuracy Spec. Not sure how this would be helpful for assignments 3 and 4 – the measurement of accuracy. At most, this seems tangential to the task at hand. * If a DPA is asked whether ICANN has the authority to measure accuracy, then you have to follow the purpose you have stated. Data commissioners have been clear that ICANN does not have a mandate to do criminal investigation. It seems that this group is attempting to get greater accuracy in the data – it will be difficult to find a purpose here. * Just because a name has been taken out of the zone, the harmed individual may still want to seek redress and seek the underlying information * This group has not discussed criminal investigation. Registrars have made it clear that they have no need for the information in RDDS. It is clear that under the current understanding of GDPR regulations and the contract, ICANN does not have the authority to ask for information other than in pursuing a complaint. * In the course of Compliance doing its work, does Compliance end up in a dead end – is there something that would position compliance to do its job better? * During audits, prior to GDPR, Compliance would validate and verify every field in the RDDS b/c Compliance had access to it – phone number, mailing address, etc. * As auditors, Compliance audits the data it has access to. * What the group is talking about is what suggestions the group can make – the previous question from the chair was a leading question. The group hasn’t identified gaps yet. * In the previous era, during an audit, ICANN might choose to verify data it had access to. Would like to presume that ICANN was not frivolously wasting time by verifying data – if they used to audit data and now they cannot, that is a substantive change. This is important information to this group. * ICANN was previously in denial of all data protection law, so past procedures cannot be presumed to have been justified. * GDPR does not prevent ICANN from doing its job, but the job is not impossible. * Do any members believe there is value in pursuing this proposal further? * Interpreting silence as no interest in moving forward with this proposal * Proposal A - Registrar Survey * Went into this thinking it could be a useless endeavor, but after working with the small team, think this could produce value. Maybe it would not be the highest value, but believe it should be considered * This is really dependent on the quality of responses – would need to be one person per company * Is there a way to create uniform clear messages for registrars to respond to? * Could the survey focus on the steps registrars take to ensure the data is accurate? Perhaps it’s a two-part survey, where questions from the first round could help inform the second round of questions. * Proposal E – Review of Accuracy Complaints * Looking at existing complaints is only a small piece of the puzzle; however, do not have a suggestion of what data the group could get out of this * If there some notation that could be put in the report to put a pin in this and come back after assignments 3 and 4 * There does not appear to be strong support to move forward with these initiatives * The group can indicate that these are proposals that were considered, but the group is not sure if these proposals would produce valuable data for assignments 3 and 4. If the group, based on all of the proposals, is not sure if this is worth the effort, the Council could say – there is nothing to move forward with at this stage. How can the group get to assignment 3 since it was designed to be informed by a factual analysis that includes data. * There is nothing to say the group cannot bring something back to the table, but as of right now, it seems like review of accuracy complaints is a dead end. * Confirm next steps * Support Staff will translate today’s discussion into text for the write-up. 3. Scenarios for EDPB * See update from ICANN org (https://mm.icann.org/pipermail/gnso-accuracy-st/2022-May/000444.html) * Scoping Team feedback by 23 May * There have been some individual responses; is there interest for the group to work on a common response? That would be ideal from org’s perspective. * Have a hard time understanding why we would ask European data authorities about scenarios 1 and 4. Everyone has access to public data, and 4 does not require access to PII. * Confirm next steps * Support Staff to put email up in Google doc and include comments that were added in the Google doc and encourage everyone to come to a common conclusion. If anyone is willing to take up the pen to draft a response from the group’s perspective, that would also be welcome. 1. Write up for assignments #1 & #2 (see https://docs.google.com/document/d/13sP-2z7rusEYrDyntrgm-tcIavPMJndU/edit[docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/13sP-2z7rusEYrDyntrgm-tcIavPMJndU/edit__;!!PtGJab4!_z1oFWiLN7PU86nTU2NKoxlVlqZJ7FCQJHKsgoIsO056qVbmZsOqcHMyNuXnKXHaWH0OkdMMSsmXv-4WqmoAcZTcxqtO4YC-722w$>) (15 minutes) * Review input received * Consider possible recommendations * Confirm next steps 1. ICANN org responses to recent set of questions (see https://mm.icann.org/pipermail/gnso-accuracy-st/2022-April/000398.html) (If follow up questions are identified prior to the meeting) * Reactions / follow up questions * Confirm next steps 1. Confirm action items & next meeting (Thursday 19 May at 14.00 UTC)
Hi all, Hoping to add a little more colour to the suggestion on the call yesterday for a registrar survey to focus on the steps registrars take to ensure data is accurate. I have attached some possible questions that would hopefully elicit information on how current accuracy obligations are implemented by registrars, and whether registrars collect data on the accuracy of emails and phone numbers. This could then be used to inform further data gathering exercises we are considering. Thoughts and input welcome. Sophie Sophie Hey Policy Advisor Com Laude T +44 (0) 20 7421 8250 Ext 252 [cid:image001.png@01D866D3.493544B0]<https://comlaude.com/> From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces@icann.org> On Behalf Of Caitlin Tubergen Sent: 12 May 2022 18:38 To: gnso-accuracy-st@icann.org Subject: [GNSO-Accuracy-ST] Notes and action items - RDA Scoping Team Meeting #29 - 12 May 2022 Dear RDA Scoping Team members, Please find below the notes and action items from today’s meeting. Best regards, Marika, Berry, and Caitlin -- 1. Support Staff to translate today’s discussion of proposals into text for the write-up. 2. Support Staff to convert the draft message to the EDPB into a Google Doc<https://docs.google.com/document/d/1rCBaQ175p_VrP6DtxLUuuoO9Uv5C2qp_/edit> for further feedback from the group. Support Staff to include the feedback already provided by individuals. (Note: ideally, the group can provide a unified response to ICANN org regarding how this communication to the EPDB could assist in the Scoping Team's work.) 3. 🚨🚨 Important note: Scoping Team members to provide feedback to the draft write-up<https://docs.google.com/document/d/13sP-2z7rusEYrDyntrgm-tcIavPMJndU/edit> IN COMMENTS FORM ONLY. 🚨🚨 Registration Data Accuracy Scoping Team – Meeting #29 Thursday 12 May at 14.00 UTC 1. Welcome & Chair Updates (5 minutes) * Project Change Request submitted to the GNSO Council (see https://mm.icann.org/pipermail/council/2022-May/025662.html) - For those interested, please review the link above. * ICANN74 session scheduled for Tuesday 14 June from 11.15 – 12.30 UTC (13.15 – 14.30 local time) - Pre-registration is required, and details regarding this will be published shortly. 1. Gap Analysis Data Collection Proposals that do not involve access to registration data (30 minutes)(see https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sScP8MwgDCg4y...>) - The work is currently focused on proposals that do not involve access to non-public registration data. - One proposal being explored is to do an ICANN compliance audit – with that in mind, the group posed some initial questions to compliance - Two colleagues from compliance have joined the call today to answer the group’s questions - At the end of the review of these proposals, the group should consider if there is a recommendation for a consideration of the proposal and why or why not. a. Proposal D - Registrar Audit * Opportunity to discuss further with ICANN Compliance · Compliance developed a written response, which includes multiple options: · Auditing without personal information – this would be limited to requesting information regarding the processes registrars use for the verification and validation requirement · Based on input from the EDPB or similar authorities, Compliance would be more certain what it is allowed to do. It is correct that you can get redacted data in response to a complaint or inquiry (3.4) but not related to a compliance audit. Further information is necessary in terms of what could be asked for in an audit. · If Compliance sends an inquiry or questionnaire, this is not a true audit. A true audit is when data is verified against substantive information. · Based on this information from Compliance, would an audit like this be helpful for the group in Assignments 3 and 4? · In doing these audits, does ICANN send tailored questions based on the respective business model that the registrar is operating (retail, wholesale, etc.)? If there is only one template, how are differences accounted for? · When audit questions are sent to contracted parties, the questions are not tailored to specific business models. · Follow-up questions may be sent based on the registrar’s initial responses. For example, if there is an obligation to send a reminder to a registrant regarding the expiration of a domain, and a registrar says, “our resellers do this,” Compliance would say – please show examples of this. Compliance would not contact the reseller directly since ICANN does not have a contractual relationship with the reseller. · Does Compliance attempt any verification that the registrar is indeed telling the truth? · Under the current scenario, compliance is not in a position to measure the accuracy of data; what they could do is audit registrars to confirm if their obligations are being followed under the Accuracy Spec. Not sure how this would be helpful for assignments 3 and 4 – the measurement of accuracy. At most, this seems tangential to the task at hand. · If a DPA is asked whether ICANN has the authority to measure accuracy, then you have to follow the purpose you have stated. Data commissioners have been clear that ICANN does not have a mandate to do criminal investigation. It seems that this group is attempting to get greater accuracy in the data – it will be difficult to find a purpose here. · Just because a name has been taken out of the zone, the harmed individual may still want to seek redress and seek the underlying information · This group has not discussed criminal investigation. Registrars have made it clear that they have no need for the information in RDDS. It is clear that under the current understanding of GDPR regulations and the contract, ICANN does not have the authority to ask for information other than in pursuing a complaint. · In the course of Compliance doing its work, does Compliance end up in a dead end – is there something that would position compliance to do its job better? · During audits, prior to GDPR, Compliance would validate and verify every field in the RDDS b/c Compliance had access to it – phone number, mailing address, etc. · As auditors, Compliance audits the data it has access to. · What the group is talking about is what suggestions the group can make – the previous question from the chair was a leading question. The group hasn’t identified gaps yet. · In the previous era, during an audit, ICANN might choose to verify data it had access to. Would like to presume that ICANN was not frivolously wasting time by verifying data – if they used to audit data and now they cannot, that is a substantive change. This is important information to this group. · ICANN was previously in denial of all data protection law, so past procedures cannot be presumed to have been justified. · GDPR does not prevent ICANN from doing its job, but the job is not impossible. · Do any members believe there is value in pursuing this proposal further? · Interpreting silence as no interest in moving forward with this proposal * Proposal A - Registrar Survey * Went into this thinking it could be a useless endeavor, but after working with the small team, think this could produce value. Maybe it would not be the highest value, but believe it should be considered * This is really dependent on the quality of responses – would need to be one person per company * Is there a way to create uniform clear messages for registrars to respond to? * Could the survey focus on the steps registrars take to ensure the data is accurate? Perhaps it’s a two-part survey, where questions from the first round could help inform the second round of questions. * Proposal E – Review of Accuracy Complaints * Looking at existing complaints is only a small piece of the puzzle; however, do not have a suggestion of what data the group could get out of this * If there some notation that could be put in the report to put a pin in this and come back after assignments 3 and 4 * There does not appear to be strong support to move forward with these initiatives * The group can indicate that these are proposals that were considered, but the group is not sure if these proposals would produce valuable data for assignments 3 and 4. If the group, based on all of the proposals, is not sure if this is worth the effort, the Council could say – there is nothing to move forward with at this stage. How can the group get to assignment 3 since it was designed to be informed by a factual analysis that includes data. * There is nothing to say the group cannot bring something back to the table, but as of right now, it seems like review of accuracy complaints is a dead end. * Confirm next steps * Support Staff will translate today’s discussion into text for the write-up. 3. Scenarios for EDPB * See update from ICANN org (https://mm.icann.org/pipermail/gnso-accuracy-st/2022-May/000444.html) * Scoping Team feedback by 23 May * There have been some individual responses; is there interest for the group to work on a common response? That would be ideal from org’s perspective. * Have a hard time understanding why we would ask European data authorities about scenarios 1 and 4. Everyone has access to public data, and 4 does not require access to PII. * Confirm next steps * Support Staff to put email up in Google doc and include comments that were added in the Google doc and encourage everyone to come to a common conclusion. If anyone is willing to take up the pen to draft a response from the group’s perspective, that would also be welcome. 1. Write up for assignments #1 & #2 (see https://docs.google.com/document/d/13sP-2z7rusEYrDyntrgm-tcIavPMJndU/edit[docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/13sP-2z7rusEYrDyntrgm-tcIavPMJndU/edit__;!!PtGJab4!_z1oFWiLN7PU86nTU2NKoxlVlqZJ7FCQJHKsgoIsO056qVbmZsOqcHMyNuXnKXHaWH0OkdMMSsmXv-4WqmoAcZTcxqtO4YC-722w$>) (15 minutes) * Review input received * Consider possible recommendations * Confirm next steps 1. ICANN org responses to recent set of questions (see https://mm.icann.org/pipermail/gnso-accuracy-st/2022-April/000398.html) (If follow up questions are identified prior to the meeting) * Reactions / follow up questions * Confirm next steps 1. Confirm action items & next meeting (Thursday 19 May at 14.00 UTC) ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com<https://comlaude.com>
participants (2)
-
Caitlin Tubergen -
Sophie Hey