Appreciate the efforts to resolve this issue, though I still have some confusion about what is being proposed below. May I clarify: 1. Sara You suggest below that “already public” is in (nearly?) all cases functionally equivalent to “Proxy exists”. If we accept this at face value, and agree that (nearly) all situations of “already public” are expected to be equivalent to “Proxy exists”, can you advise what the reasoning is against a name change? <<arguments for a name change would include clarity and accuracy in our data collection, in addition to clarity of messaging to end users>> 2. Sarah+Seb+John * When proxies exist, is there any method within what you propose below to track which instances are affiliated proxies vs. which are third party? <<this information would seem especially relevant to inform future decision-making>> * ICANN Org has recently stated that all or nearly all proxy providers they are aware of were affiliates of registrars. If we accept that determination, what difference exists between the way RDRS routes requests to the registrar vs routing to the affiliate (as your bullet #2 indicates should be done)? * In the model you propose below, what would a registrar mark if both of the following are true: a) The proxy is an affiliate, & b) The registrar conducts a balancing test and choses to disclose the real information behind the proxy to the requestor? G From: Gnso-rdrs-sc <gnso-rdrs-sc-bounces@icann.org> On Behalf Of Sarah Wyld Sent: Thursday, March 14, 2024 12:08 PM To: gnso-rdrs-sc@icann.org Subject: [EXTERNAL EMAIL] - Re: [Gnso-rdrs-sc] RDRS - PP issue response. Hi Steve, I would think that we are tracking this statistic by using the "already public" option. The only other circumstance where "already public" is applicable is when the registrant has opted to publish their registration data, in which case there's no reason to submit an RDRS request, so there should be a vanishingly small number of those requests (if any). Thanks, Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com<mailto:swyld@tucows.com> On 2024-03-14 3:04 p.m., Steve Crocker wrote: Sebastian, Thanks for this update and thanks to Sarah Wyld, John McElwaine and you for the additional effort. Your point about Privacy and Proxy being out of scope is clear and understood. That said, this issue is likely to greatly skew the statistics. When a requestor fails to get the needed data because it's hidden behind a privacy or proxy provider, the registrar is likely to count this as a successful transaction in the sense that it conforms to the rules, but the requestor is likely to count it as a failure. When the dust settles and it's time to evaluate whether the RDRS has been a successful experiment and whether we should or should not move forward with a fuller system akin to the SSAD, we might find ourselves with strongly divergent opinions. I think we would be best served by distinguishing responses that are technically correct within the specifications of the RDRS experiment but are nonetheless unsatisfactory for the requestors. It would be but a small but important improvement in the reporting to keep track of this statistic. Thanks, Steve On Thu, Mar 14, 2024 at 10:55 AM Sebastien@registry.godaddy<mailto:Sebastien@registry.godaddy> <Sebastien@registry.godaddy><mailto:Sebastien@registry.godaddy> wrote: Dear Standing Committee and ICANN Colleagues, Sarah Wyld, John McElwaine and I had a call today to review the issue of responses to Privacy and Proxy. It transpired during the ICANN79 week, on and off mic, that a substantial part of the denials received by Requestors were due to PP, but were not captured in a consistent manner across all responding Registrars. The Standing Committee is not going to resolve the issue of PP; there is a bespoke group looking into it and currently working next steps out between Staff and Council. The SC obviously should not influence Registrars’ balancing test and decisions around disclosure. This said, we agreed that efforts are required into ensure that same outcomes should be returned to the Requestors via the system in same statistically trackable answers. We agree and submit to the Committee that: 1. The gamut of existing available answers exists on the current platform, there is no need to add any PP specific answer. If the registrar is aware that the domain uses a P/P service and will not disclose any further data, they should use the checkbox labelled "If all of the data is publicly available, please check this box" . 2. Requestor FAQ/User Guide should be adapted to clearly indicate that “all data is publicly available” typically refers to a registration under PP which the Registrar is unable to disclose and for which disclosure should be requested directly from the PP provider. 3. Registrar FAQ/User Guide should be adapted to clearly indicate that the “If all of the data is publicly available, please check this box” checkbox should be used in the case of data Requests under known PP which a Registrar cannot disclose directly. 4. In-line tips in the Registrar interface should be added (pop-up additional information, or directly in-line) as a reminder to the same. This is redundant information, but we see it as important to ensure existing Registrars who are not likely to regularly consult the FAQs, be aware of this new guideline. 5. Communicate on the same with Requestor and Registrar communities via already established channels. We look to Staff for help and guidance for items 2, 3 and 4. 5 should be relayed to ICANN Account Managers in charge of participating Registrars. This will neither resolve the issue of PP nor change the level of data disclosure, but aims at: * Offering a clearer answer to requestors, and limit the diversity of answers given to a same issue, * Allowing to more clearly track Requests under PP and avoid having them weighing on disclosure/non-disclosure statistics. We look forward to your comments. Kindly, Sebastien Ducos GoDaddy Registry | Senior Client Services Manager [signature_1782455406] +33612284445 France & Australia sebastien@registry.godaddy<mailto:sebastien@registry.godaddy> _______________________________________________ Gnso-rdrs-sc mailing list Gnso-rdrs-sc@icann.org<mailto: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. _______________________________________________ Gnso-rdrs-sc mailing list Gnso-rdrs-sc@icann.org<mailto: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.
