Dear RDA Scoping Team, Please find below the notes and action items from today’s meeting. The next meeting will be Thursday, 13 January at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items 1. GAC colleagues to come prepared to respond to questions raised during 23 December call. (Please refer to meeting transcript and notes: https://community.icann.org/pages/viewpage.action?pageId=180027627 2. Scoping Team to consider what is needed and from whom to obtain information identified as necessary to measure whether current goals are met. Additionally, scoping team members to begin identifying specific ways in which measurement can be undertaken. As noted during today’s meeting, Support Staff has begun inputting the responses received from the Gap Analysis here: https://docs.google.com/document/d/11msexuoqWSUsFj8ZjVvWF-XHpcMJntWH/edit?pl... 3. OUTSTANDING: BC colleagues to input feedback into Gap Analysis as soon as possible. Registration Data Accuracy Scoping Team – Meeting #12 Thursday 6 January at 14.00 UTC 1. Welcome & Chair Updates (5 minutes) * Status of questions to ICANN org * Expect the ICANN org answers to come back by mid-next week, hopefully before the next meeting * Relevant subject matter experts have expressed willingness to attend the meeting and answer follow-up questions * Vice-chair – proposed next steps * Propose to open the floor for the vice-chair position – interested members can speak up now on the call or write to the list if interested in the position * Is the vice-chair open to the entire community, or just members/alternates? * Members/alternates should be given the first chance to express interest; however, members and alternates may not wish to give up their neutrality. It may have to be opened to everyone if no members or alternates steps forward. 1. Gap Analysis (50 minutes) * Responses to questions raised in relation to GAC input during meeting #11 * Postponed until next meeting to allow sufficient time for GAC colleagues to collaborate * Note: the notes and transcript of the last meeting will provide the specific questions that arose during the meeting * Continue review of remaining input (SSAC, still missing: BC, ISPCP, NCSG):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!uPJMvPfyP0FqeLe6RXO7ev7GZ9yRK-o1iqIfwQlDprCxZCBiSi0ZylW36ixz2keAAXSRSCzhOy8$> * SSAC sent additional input to the group earlier this week * SSAC input: * There appears to be a fundamental split in the discussion. There is a distinction b/w stated purposes from EPDP vs. what are felt to be legitimate needs felt by various users. * When the group is finished, it will need to communicate what is done and what is not done. * What are the operational requirements imposed on CPs? This is intended to implement these purposes, but the question remains – do they effectively implement these purposes * Understand it is important to stick to Council instructions, but it’s important to identify problems if the group observes them * Important not to conflate purposes and uses – purposes were settled under EPDP; subsequent use of information is what the group can discuss. * Believe the EPDP Team was approaching the problem in the wrong way - engineers, lawyers, and policy folks have a different approach to scope * The picket fence does limit what can be put in contracts and made binding on contracted parties. The issue of maintenance of accurate and up-to-date registration data is squarely within the picket fence. * ICANN should regain access to reg data and resume ARS * ICANN access to registration data is a basic example of a GDPR-compliant service * Oversight of accuracy – this should be spelled out in a co-controller agreement of some kind – this group needs to see the agreement * The agreement is a subordinate matter * How exactly does SSAC anticipate that ICANN can check the accuracy of data? It seems it was suggested that it could work with a third party on this. * The current rules are vague on two points: which data elements needs to be validated at which levels. The actual validation that is carried out should be disclosed. If there is a choice to verify the email or phone number – the verification level should be returned. When was the validation/verification done? * (per element accuracy requirement) – which elements do not have any requirements? * Name and org * These have validation requirements – they are in the appropriate format, but not verification requirements, so they should fall under V1 * Syntactic requirements are pretty weak. What they ultimately should fall under is a policy issue. * Believe V1 is the appropriate level for name and org * Both RDAP and EPP are extensible with respect to what fields are included – that is different than a new platform * When verification request is sent to a phone or email, the registrant is asked to confirm that all fields are accurate (and this is additionally confirmed on an annual basis under the WDRP) * NCSG Input * Goals: operational and syntactic accuracy (contactability) * Registrars are in the best position to measure these goals since they hold the data * No additional goals identified – the registrar has requirement to ensure data is accurate throughout its lifecycle * BC’s input is forthcoming * Scoping team input * Confirm next steps * BC’s input is forthcoming 1. Measurement of current goals identified (30 minutes) * EPDP Team to consider what is needed and from whom to obtain information identified as necessary to measure whether current goals are met * Within the table, Support Staff has input the responses from groups * The idea is to start having a practical conversation around confirming if these goals are met, and, further, what is needed to confirm this? * Does further research need to be undertaken? Do additional parties need to be involved? How much time would be needed for this? Steve’s Document: * There is a tremendous amount of repeating points that have been made in the past. Keep track of these to shorten repetition and be forthright about what the group is doing and NOT doing. * This is now in a google doc format to allow collaboration * Some items in this document were discussed earlier via the SSAC input * EPDP2A recommended no change because of no consensus, but there were a substantial number of minority views – this can be recorded here. * It would be helpful to identify who the user is, as not all users have a need to identify the registrant * Security researchers do not have delegated authority to act as if they are law enforcers * Confirm next steps 1. Confirm action items & next meeting (Thursday 13 January at 14.00 UTC)