Thanks for this Sarah. I’ll take this back to discuss internally with the ICANN team as well. Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN From: Gnso-rdrs-sc <gnso-rdrs-sc-bounces@icann.org> on behalf of Sarah Wyld <swyld@tucows.com> Organization: Tucows Date: Monday, April 1, 2024 at 6:47 AM To: "gnso-rdrs-sc@icann.org" <gnso-rdrs-sc@icann.org> Subject: [Gnso-rdrs-sc] RDRS Requestor data - required vs optional Hello team, As discussed recently, this email is to confirm the RrSG's request to adjust the required/optional status of RDRS requestor data, making the address and phone number required instead of optional and collecting the org/affiliation (requestor can provide as applicable). These two changes were previously shared in the Impressions Document [docs.google.com] (making the address mandatory was our very first request in the sheet!) so shouldn't be a surprise to anyone. To summarize: Requestor data - required (no change) Name Email Requestor data - currently optional -> make this required Address Phone number Requestor data - currently not collected -> collect, optional Organization or affiliation I think ICANN had also requested further explanation about why this data is necessary for registrars. In order to evaluate a request, the registrar must know who is making the request; this has become even more important with so many people submitting "law enforcement" requests despite not being law enforcement officers. Even setting that aside, a balancing test as required under the GDPR or other data protection laws cannot be done appropriately without full knowledge of who is doing the requesting and would be receiving the data. In addition, many registrars have a legal obligation to disclose to the data subject the facts of the disclosure of their personal data; this cannot be done appropriately without information about who did the requesting. Name is required because it is a person and not a company that may make the request. Organization/Affiliation (Company) should be an optional field, so that IF it is relevant (as it often is) the requestor can add that info to the request. Phone number is required so that a registrant may reach out to the requestor with any questions. Address is required to validate against the asserted organization/affiliation and name, as well as so that the registrant may serve legal process against the requestor if they need to do so. Finally, I'm not sure that RDRS can control for this, but the email address should be a direct email address and not a role (or group/shared) account, because it is a person who is allowed access to the previously-public registration data, not a company or role. I hope that helps clarify things, and look forward to hearing about the level of effort/time it would take to make these changes. Thank you, Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com On 2024-03-26 4:36 p.m., Lisa Carter wrote: Thanks Sarah. These prioritized ratings are helpful. I will take these to the team for LOE review. Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN From: Gnso-rdrs-sc <gnso-rdrs-sc-bounces@icann.org> on behalf of Sarah Wyld <swyld@tucows.com> Organization: Tucows Date: Tuesday, March 26, 2024 at 8:40 AM To: "gnso-rdrs-sc@icann.org" <gnso-rdrs-sc@icann.org> Subject: Re: [Gnso-rdrs-sc] 2024-03-25 RDRS Standing Committee - Follow Up Hi all, Considering the Impressions doc which was discussed at the end of yesterday's meeting, I do note that the two main requests from Registrars are already there - make requestor address (and phone) data mandatory is #1 on the list and a 'pending input' status is #16 on the list. I'm still in progress of confirming that these are RrSG-supported rather than only desired by some registrars, I am seeing strong support so far but have given Friday as a deadline so will wait until after that to tell this group officially. I have attempted to add priority ratings to the RDRS functionality requests in the registrar section of the doc. However, these might change depending on the level of effort they would require. I hope that at our next meeting or ASAP after that we can review the suggested improvements and hear from ICANN about whether they are possible, how much time they would likely take, etc. Thank you, Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com On 2024-03-25 4:00 p.m., Feodora Hamza wrote: Dear RDRS Standing Committee, Please find below the main discussion points and action items from todays meeting. The next meeting is scheduled for 8 April at 17:30 UTC. Kind regards, Feodora and Caitlin 2024-03-25 RDRS Standing Committee - Meeting #04 Action items and main discussion points Welcome RDRS Usage Report a.Overview of Changes from Last Report (ICANN org Support Staff) b.Reactions from Standing Committee 1. Metric 9 doesn’t seem to correspond to metric 2 and 3? Number seem not to match. AI: ICANN Org to share concerns with the metrics team to provide more clarification on numbers. 1. No total number of requests that are rejected. Staff pointed to Metric 10 that answers that question. 1. Number of participating registrars that received requests per month seems to be not shown in metrics. 1. Metric 3 and 4 show numbers of new requests made per month – in this case March. AI: ICANN Org to cross-check numbers as the new numbers seem too high for a month. 1. Metric 8 to 22: Is this self-reported? Or who makes that assessment in terms of requestor categorization? Category is based on request type. 1. More of the requestors data to be mandatory when submitting a request. Address and Phone number may be requested as mandatory by RrSG (Sarah Wyld will check to ensure all RrSG agrees) in order to make disclosure determination. AI: ICANN Org to investigate the effort for above change (making address and phone number required) and consider data privacy aspects of requesting additional PII. 1. Does the person creating the ICANN account confirm their Email address? ICANN Org performs Email verification. The Email is not re-verified regularly. Should the latter be reconsidered? 3.RDRS Usage Metrics Report Summary Data CSV 1. Interest in Sankey graphics to present data. Staff to discuss what is possible. AI: ICANN Org to potentially release a CSV file for members to create individual charts. 4.Privacy/Proxy responses in RDRS (Sebastien’s 14 March email – see attached) 1. How are requests involving P/P data should be handled? Metric 14 was being treated as the response was publicly available. What was the reasoning? If the answer is Privacy/Proxy is the response “success” or “failure”. There are multiple types of publicly available information. E.g.: We could add subcategories to "Public" as subcategories of "Proxy-Affiliated" and "Proxy-NonAffiliated". 1. Difficult to assess as the PPSAI discussion is not complete yet. 1. RDRS has pilot of 2 years. PPSAI might take more time, so SC must find alternative. AI: ICANN Org to help with user guides and additional wording for FAQs. Gather small group from SC to work on these. 5.Denial responses and explanation in RDRS 1. Explain further “denial- needing more information form requestor”. Pending status. At some point tickets should get closed automatically if requestor doesn’t reply with more information. What should the standardized time frame for “pending” status be? 1 month? More or less? 6.AOB AI: ICANN Org to go through impressions document [docs.google.com] to check for further list of improvements posed by SGs. AI: SC Group is encouraged to add modification requests to that document [docs.google.com] and to prioritize the list of improvements. Feodora Hamza Policy Development Support Manager (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +32 496 30 24 15 Email: feodora.hamza@icann.org Website: www.icann.org _______________________________________________ Gnso-rdrs-sc mailing list Gnso-rdrs-sc@icann.org https://mm.icann.org/mailman/listinfo/gnso-rdrs-sc _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
