Dear RDA Scoping Team Members, Please find below the notes and action items from today’s call. The next RDA Scoping Team Meeting will take place at ICANN74 on Tuesday 14 June from 11.15 – 12.30 UTC (13.15 – 14.30 local time) – we wish safe travelers to all members who will be attending in person! Best regards, Marika, Berry, and Caitlin -- Action Items 1. Support Staff to produce updated version of the write-up, which will include (i) resolutions of remaining comments that were not flagged and/or agreed to during today’s meeting; (ii) added text from section 2.1.2 (measurement of whether current goals are met). Note: the text from 2.1.2 still includes bracketed text for further feedback from GAC regarding what further work could be done while input from registrars and the EDPB is outstanding. (Please see action item 2.) 2. GAC colleagues (or other members in agreements) to provide further information on what work could be done in the interim b/w assignments 2 and 3 instead of pausing work while additional data is collected/EDPB response is outstanding in advance of the next meeting on Tuesday, 14 June. 3. Laureen K. to populate newly-introduced proposal to register names with purposefully inaccurate information as an experiment into the proposal Google Doc: https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit in advance of the next meeting on Tuesday, 14 June. Registration Data Accuracy Scoping Team – Meeting #33 Thursday 9 June at 14.00 UTC 1. Welcome & Chair Updates (5 minutes) * Group will be meeting in person for the first time at ICANN74 * Proposed agenda is displayed as part today’s meeting agenda (see item 2) * For item c, this is largely dependent on today’s conversation – this may need to be tweaked based on what is or is not discussed and agreed to during today’s meeting. 1. ICANN74 Proposed Agenda (10 minutes) * Welcome * Brief recap – Scoping Team assignment, current state of work & planned outreach to the EDPB * Finalize write up for assignments #1 and #2 for delivery to GNSO Council · Consider any outstanding items · Confirm deadline for final review · Confirm next steps * AOB 1. 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]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1CYs9mLHsKcZev...>) (15 minutes) * Review any further input received * This section of the document was discussed during last week’s meeting. * Lori and Susan inquired about incentives – Support Staff included a new sentence, “The Scoping team encourages ICANN org to consider incentives that could be provided to encourage responses to the survey.” As there is no objection to this addition, Support Staff will add. * GAC reps made a comment regarding a concern about pausing this group’s work while data is gathered/EDPB input is outstanding – there was an action item for GAC colleagues to provide further context as to the concern and propose further work, but nothing further was received. * Additionally, CPH colleagues mentioned they had further comments, but, to date, nothing further was added. * GAC reps request further time to provide input on the impact of pausing. * Will the work of this group be allocated any time during GAC’s session? Would not approve a finalization of this document without the GAC providing input on this. * As the GAC has noted, this is a priority topic and reps are mindful of timelines. There will be further discussion at ICANN74, so plan to discuss a view that reflects the GAC’s priorities here. * For Assignment 3, there is a reference to data collected during assignments 1 and 2 – so far, no data was collected for assignments 1 and 2. There is a belief by some expressed here – whether current measures are implemented sufficiently is not necessarily contingent on data. This hinges on if the assignment is interpreted verbatim or is based on what the group has discussed in the interim. * In other words, are we conducting the assignment based on the letter or the spirit of the assignment? If the spirit, perhaps additional work can continue while the data is being gathered. * The group discussed whether what is currently in the RAA is a definition of accuracy. This may not be the optimum definition of accuracy for the purposes of the data we’re collecting with regard to registrants. Is there something better that we can be doing? We could potentially have a PDP to alter the requirements in the RAA. * It’s difficult to proceed without understanding the effect of the current state of accuracy. * Since there are no comments on this specific section, Support Staff proposes to include this section 2.1.2 into the write-up for sections 1-2. If the group agrees, it would need to articulate what could be done in the interim – this will need to be called out, as this document needs to go back to the Council before work commences on the next assignment. * With respect to pausing and waiting, if the group will wait to see if we get an answer from the EDPB, it will still have to wait to actually conduct the data analysis after a “yes” is potentially received. Does the group realistically want to pause the work of the group for 1-2 years? * If we are not sure if we can measure the success of current requirements and we are waiting to measure the current requirements, what exactly could we do? What work would this entail? * In addition to getting an assessment of the accuracy of what’s there, the other question is – what measures are in place to ensure that someone cannot register a name with inaccurate information. That is something that could be tested – for example, registrars could be tested by providing information that is accurate and inaccurate and see if a name can be registered with inaccurate information. * Finding out what measures are in place to ensure registrants cannot register names with inaccurate information – isn’t that part of assignment 2? Could that be added to assignment 2? * Contractual compliance previously looked into if new hires could use ICANN funds to register domain names as tests, but this was rejected at the time due to multiple concerns. * ICANN has registered domain names in the past. * There is an original proposal document, which included pros and cons of the provided proposal so that the group could have a more fulsome discussion on taking that proposal forward. This proposal could go through the same path if others think this could be a useful path forward: https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit. * It may be reasonable to review earlier ideas since we were asked what we could do. The concept of registering domain names with bad information is interesting – not sure if this is a good or bad idea. However, are there other things we could consider? For example, one question we asked ICANN if registrars are obliged to monitor bounces, and we were informed they are not. Knowing the bounce-back rates would be valuable intel – maybe it’s time to revisit this before turning in the assignment to the Council. * Confirm next steps 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!40FU6vqkaFAqU4HOLMrHV1rgB7rjjprUhkVuXT5c0dLORQrAQCFB8tlukLaoYhlPcN05NnalskuSfJcm__2hAlowWL-xuZ9STrnr$>) (30 minutes) * Consider any ‘cannot live with’ items flagged and/or alternative proposals put forward * Support Staff provided proposed paths forward to close out items and flag if there were any items where an alternative proposal should be considered. * Beth flagged two items via the list – (i) the first is cross-field validation work (AFAV) – suggestion would be to incorporate that status update here. Work has been undertaken in this area, but it has been paused until the end of EPDP work. (ii) the second is a footnote regarding patently inaccurate. * For cross-field validation, recall that RFIs were collected, and the chair’s understanding – it was agreed that it was not economically viable at the time. * There were two RFIs from 2014 and 2017 regarding if AFAV would be possible. There were concerns that if may not be applicable everywhere, and there were also some cost considerations. In the interim, the Temp Spec became effective. ICANN org and Registrars agreed to revisit this once EPDP recs have been implemented. * It would be helpful to include this documentation where ICANN and registrars agreed to this so this could be included in the write-up. * Has ICANN ever thought of getting a service and allowing registrars to access that service? * This was considered in 2014, so it would be difficult to speculate how it would operate now, and this is not in scope for this group. * The 2013 RAA refers to AFAV and refers to accuracy, so this is in scope. * There was a suggestion to add an explanation as to what is going on with that work – CPH colleagues have suggested text that could be used for this: AFAV was paused in light of the EPDP on Registration Data. There were two RFIs (2014 and 2017), however the solutions were not practical or applicable globally. Pending the implementation of all phases of the EPDP, the RrSG and ICANN agree to review whether a new RFI is needed in light of the changes since 2014/2017. Further implementation is paused. Apart from that proposed text, not sure anything else is needed here. * It is easy to pause – how can it be un-paused? There is such a minimum set of requirements in the 2013 RAA – seems like we should not lose sight of the AFAV requirements. * Agree that this is in scope. There was a conscious decision made that Compliance would not enforce this b/c it was not economically viable. Maybe this can be done for countries where it is possible. * In 2013, this was part of the 2013 RAA negotiation. The cross-field address validation came down from law enforcement. At the time, the registrars said they do not think this is possible but are willing to put it in the agreement on the theory that we could see if it is possible. It came down to the 90/10 rule – you can do this in the US and Canada, but probably not other parts of the world. * For the UPU S42 standard, with the address format – this has been implemented in all 192 member states that have signed the postal treaty. * Please verify with ICANN org – when ARS was in place, ICANN had a contract with the UPU to do address validation. Can you please confirm how the UPU was involved. * When discussing cross-field validation previously, others had discussed that this was not commercially feasible. Is this something that ICANN’s economist could review? * The Whois ARS did use the UPU for its work, and all postal addresses reviewed were deliverable and contactable. * Question – there was a 90% - of the addresses that were sampled, over 90% of addresses in the data set were deliverable addresses. * The ARS survey was around 1000. * The ARS survey was more. The NORC (provider for the analysis) – original sample was over 100,000 names to encompass a broad sample of legacy TLDs, new gTLDs, and others. It was sub-sampled down from there. Several thousand domain names were sampled – the confidence levels were still over 90%. * Lori’s comment was about a status update, and we are now evaluating the work done by a different working group. Not sure this is relevant – seems to have strayed from the point. Speculating about how it was done and whether it was appropriate is out of scope for this work. Can we agree to this edit, and if more work needs to be done, this could be done in an appropriate way and not speculate about a report that is not in front of the group. * Asking questions because there are people on the call that are in a position to answer these questions. * One other item: Concern about the placement of a footnote for patently. This footnote was a compromise from when the description discussion was held. * CPH was not able to discuss Melina’s new comment, and Melina is not able to attend today. Support Staff’s summary was accurate – agreed that this would be a footnote. Prefer this to be a footnote as was previously agreed. * The gist of this – if there is agreement of the content here, cannot understand why this can’t be part of the main body of the text. * This was the subject of a previous compromise. * Encourage the team to reach out to one another or have hallway conversations in The Hague to deal with this specific point * Objected to having this in the main text because patently is not part of the RAA text – patently false examples are an extreme outlier, so this is more appropriately relegated to a footnote * Confirm next steps * Support Staff to produce updated version of the write-up, which will include (i) resolutions of remaining comments that were not flagged and/or agreed to during today’s meeting; (ii) added text from section 2.1.2 (measurement of whether current goals are met). Note: the text from 2.1.2 still includes bracketed text for further feedback from GAC regarding what further work could be done while input from registrars and the EDPB is outstanding. (Please see action item 2.) * GAC colleagues (or other members in agreements) to provide further information on what work could be done in the interim b/w assignments 2 and 3 instead of pausing work while additional data is collected/EDPB response is outstanding. * Laureen K. to populate newly-introduced proposal to register names with purposefully inaccurate information as an experiment into the proposal Google Doc: https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit. 1. Confirm action items & next meeting (ICANN74 session on Tuesday 14 June from 11.15 – 12.30 UTC (13.15 – 14.30 local time) * If you are attending ICANN74 in person and responded to the survey, you will be marked as an in room attendee and can sit at the table * If you are in person, do not connect your microphone * Everyone must connect to the Zoom room * All participants must raise hands in Zoom, both in person and remote * Please remember to state your name and speak slowly