[GNSO-Accuracy-ST] Notes and action items - RDA Scoping Team Meeting #9 - 9 December 2021

[Caitlin Tubergen]

Dear RDA Scoping Team Members,

Please find below the notes and action items from today’s meeting.

The next RDA Scoping Team meeting will be Thursday, 16 December at 13:00 UTC.

Best regards,

Marika, Berry, and Caitlin

--

Action Items

1. By the COB Friday, 10 December, Scoping Team members who submitted questions to review questions, in light of meeting discussions and other questions submitted, and determine if questions should be deleted, modified, or retained. Deletions and modifications to be applied by COB, Friday, 10 December. (https://docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit)

2. Beginning 13 December, Support Staff to review the list of questions and group similar questions together and consolidate where possible. Support Staff to share updated list of questions with the Scoping Team by Tuesday, 14 December for the Team to provide any objections by Thursday, 16 December.

3. Groups who have not provided inputs for the Gap Analysis (BC, GAC, ISPCP, NCSG, SSAC) to do so in advance of the Team's next meeting on Thursday, 16 December.

Registration Data Accuracy Scoping Team – Meeting #9
Thursday 9 December at 14.00 UTC


  1.  Welcome & Chair Updates (5 minutes)
     *   Next week’s meeting will be Thursday, 16 December at 13:00 UTC.
     *   Once the Team goes through the entire list of submitted questions, Support Staff will group similar questions together


  1.  Finalize questions to ICANN org regarding enforcement and Accuracy Reporting System (30 minutes)
     *   Input received from scoping team to date: https://docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit[docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit__;!!PtGJab4!vj0sIHIzVEjrKu1rj8Q2JZv-Ay5nO7Tr6EkTqNGARa1CfH9UAWeYGFz0L3XDy8-4cBsyiVlO8mI$>

     *   The process of Registration Data Complaints is still in use – this will be conveyed back to IPC membership
     *   Encourage everyone to listen to the one-hour Compliance update session from ICANN72: https://72.schedule.icann.org/meetings/xGs2HynAJKdXvN36G
     *   Is there any self-policing going on for registrars that could be used for best practices?
     *   The question re: due diligence for data accuracy – believe this is covered under existing contractual obligations – for example, all new data sets are verified. On an annual basis, there is a confirmation sent to the registrant that the data is still accurate.
     *   Paragraph 4 from the Whois Accuracy Spec provides that if registrar has any received any information that the information is inaccurate, additional requirements apply.
     *   In terms of suspending the ARS because the data is unavailable seems incorrect – there should be a legitimate ICANN purpose for processing the data.
     *   Have been told that registrars are not obliged to chase bounced emails – good to know this language exists. The WDRP notice is not a confirmation – it’s a reminder.
     *   With respect to ARS, it was suspended because ICANN could not perform its current process
     *   Registrars must annually self-certify that they are in compliance with the RAA. ICANN can audit registrars, which is a great way to monitor and check for compliance. A DPA is not currently in place for ICANN. There is no way to prove that a registrant has read the WDRP notice; the same issue comes about with terms of service, but the terms are still legally binding.
     *   Question 14 – specific UDRP case cited, where inaccurate data was disclosed – is there a flow between WIPO and ICANN – if so, do standards apply, or is it a case-by-case basis?
     *   Recommend every scoping team member read the WIPO decision in D2021-1050 – it’s relevant to the team’s work
     *   Question 16 – expecting ICANN to say that operational validation is required, syntactic validation is required for the country code, and no validation of any kind is imposed on any other data elements.
     *   Question 17 – focus of these contracts is what are the requirements, but there is an implicit question whether registrars can do more work – are higher levels of validation permitted?
     *   Question 18 – do registrars have to provide the level of validation with the data element – for example, tagging?
     *   The answers to these three questions can be found in the RAA. Q17 – this is answered by registries who voluntarily commit to levels of accuracy beyond what is in the RAA. Q18 – the answer is no. In the application and audits, CPs are only required to answer what answers match the requirements of the RAA, so that level of verification is not required – Rrs just have to outline how they match the requirements. Q16 – there is a difference b/w accuracy that is required of the registrant, and the accuracy that is required – requirements from registry agreement is lower. Higher levels may be triggered from an inaccuracy complaint.
     *   Accuracy and validation requirements – would recommend replacing accuracy with validation requirements.
     *   The answers to these questions are documented in the background material; accordingly, what is the purpose for asking these questions? Uncomfortable asking questions that show that the team hasn’t done its homework
     *   Question 19 notes for consistency check for some fields – in many cases, registrars do not do this. Has there been an outcome to this question?
     *   Most registrars operate on a global scale, and it is not feasible to do cross-field validation worldwide
     *   Question still stands – for many large countries, postal service offers cross-field validation for addresses. If a decision was made that this is not feasible, it needs to be documented. The fact that the only thing that can be found is an old document that says discussions that are ongoing, needs an update.
     *   For Q20 – would like confirmation that ARS was terminated because it couldn’t be done exactly as before.
     *   There was a public comment in 2015 regarding the Whois Accuracy Program Specification – no changes have happened – this is part of the community’s business even though it’s part of a contract
     *   Q21 – did not know there was a process to manually verify the information – what process is acceptable to ICANN to verify an email address manually
     *   This option was negotiated into the agreement by registrars – ICANN wanted the name to be deleted if no affirmative response – the manual verification was requested by registrars.
     *   What does “look for trends of abuse” mean?
     *   Does ICANN look at the bigger picture? It could be helpful if so.
     *   Action: Support Staff to organize the questions and group questions that focus on a similar topic and produce updated version.
     *   Question to the group: do all of these questions still need to be asked?
     *   Action: Scoping Team to review questions to confirm they are still relevant by COB Friday, 10 Dec.
     *   Will Staff Support be removing questions that are duplicative?
     *   If questions can be grouped by concept, that would be helpful.

     *   Scoping team input
     *   Confirm final questions for submission to ICANN org


  1.  Gap Analysis (50 minutes)
     *   Review input received from scoping team: https://docs.google.com/document/d/11msexuoqWSUsFj8ZjVvWF-XHpcMJntWH/edit[docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/11msexuoqWSUsFj8ZjVvWF-XHpcMJntWH/edit__;!!PtGJab4!vj0sIHIzVEjrKu1rj8Q2JZv-Ay5nO7Tr6EkTqNGARa1CfH9UAWeYGFz0L3XDy8-4cBsypdJ09fc$>
     *   Scoping team input
     *   Confirm next steps

     *   So far, we have received input from RySG, RrSG, IPC, and ALAC.
     *   Are the missing groups still planning to add feedback?
     *   GAC will have an answer by next week’s call.


  1.  Confirm action items & next meeting (Thursday 16 December at 13.00 UTC)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211209/1096f5bf/attachment-0001.html>