One of the reasons it can be relevant to know whether the “public” information pertains to an “affiliate” of the registrar vs not is that it has the potential to significantly alter the degree to which the registrar has access to the real information about the person who registered the domain name. Some registrars’ terms of use with their customers make it explicit that information given to their affiliate shall count as given to them. Knowing the degree to which this is occurring can inform us as to whether/not we need concern ourselves with other scenarios (such as 3rd party proxy services unaffiliated with the registrar, which I’ve heard exist but have not encountered). For RDRS purposes, public = seems to indicate that one of the following applies: * Affiliated proxy service * Non-affiliated proxy service * Affiliated privacy service * Non-affiliated privacy service * Reseller But absent consensus to collect this information, we’re going to remain blind as to what the relative proportions are, and to what degree we need to care about how they influence successor system requirements. G From: Gnso-rdrs-sc <gnso-rdrs-sc-bounces@icann.org> On Behalf Of Alan Greenberg Sent: Monday, March 25, 2024 1:25 PM To: Steve Crocker <steve@shinkuro.com> Cc: gnso-rdrs-sc@icann.org Subject: [EXTERNAL EMAIL] - Re: [Gnso-rdrs-sc] Proposed agenda - RDRS Standing Committee Meeting #4 - Monday, 25 March at 17:30 UTC Unfortunately, according to the RAA, the Registered Name Holder (sometimes referred to as the "Registrant of Record") is indeed the Proxy Service. Even with PPSAI as currently drafted, that will not change. It is a silly game that we play. I have domains protected by a Proxy service. If this was a truly arms-length proxy service, the registrar would send various noticed required in the RAA to the Registrant of Record, the proxy service. But it sends them to me. They could use a similar pass-through for reveal requests, but they don't. Alan On Mon, Mar 25, 2024 at 3:33 PM Steve Crocker <steve@shinkuro.com<mailto:steve@shinkuro.com>> wrote: Thanks for this helpful description of privacy and proxy services. I still do not understand how it's appropriate for registrar to respond with “all the data is publicly available” when the registrar has explicit knowledge this not the case. Why not simply respond with a straightforward message: “The registration data is protected via a [privacy, proxy] service. The requester is advised to contact the [privacy, proxy] <name of service> for additional information.”? Steve Sent from my iPhone On Mar 25, 2024, at 12:16 PM, Lisa Carter <lisa.carter@icann.org<mailto:lisa.carter@icann.org>> wrote: Hi Steve, Here’s a bit of clarification I can provide: A Proxy Service is a service where the use of the domain name is licensed to the beneficial user and the Registrant is the Proxy Service itself. Under the current requirements of the Interim Registration Data Policy for gTLDs (requiring contracted parties to continue implementing measures consistent with the Temporary Specification for gTLD Registration Data – see Appendix A, Section 2.6<https://www.icann.org/resources/pages/gtld-registration-data-specs-en/#appen...>), registrars must display the full Registration Data of the Registrant/Proxy Service, ensuring such information is publicly available in the RDDS. Appendix A, Section 2.6 of the Temporary Specification explicitly maintains the “status quo” of the public WHOIS for registrations utilizing a Proxy Service. This is not the case for a Privacy Service. A Privacy Service is a service where the beneficial user is still the Registrant. However, alternative contact information is displayed in the public RDDS (e.g., postal address, email, telephone). Therefore, the Registrant identity (i.e., Registrant Name) may be redacted and subject to contractual requirements concerning disclosure requests. In this case, all data is NOT publicly available, only the contact information. The Temporary Specification was designed to maintain contractual requirements to the greatest extent possible in light of existing data protection/privacy laws. It does not modify the requirements and obligations set forth in the Specification on Privacy Proxy Registrations under the Registrar Accreditation Agreement (RAA), which does not currently require Registrars to provide reasonable access to the contact information of a Privacy or Proxy customer in the manner prescribed by Appendix A, Section 4.1<https://www.icann.org/resources/pages/gtld-registration-data-specs-en/#appen...> of the Temporary Specification. Thanks Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN <image001.png> From: Gnso-rdrs-sc <gnso-rdrs-sc-bounces@icann.org<mailto:gnso-rdrs-sc-bounces@icann.org>> on behalf of Steve Crocker <steve@shinkuro.com<mailto:steve@shinkuro.com>> Date: Friday, March 22, 2024 at 6:39 AM To: Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> Cc: "gnso-rdrs-sc@icann.org<mailto:gnso-rdrs-sc@icann.org>" <gnso-rdrs-sc@icann.org<mailto:gnso-rdrs-sc@icann.org>> Subject: Re: [Gnso-rdrs-sc] Proposed agenda - RDRS Standing Committee Meeting #4 - Monday, 25 March at 17:30 UTC I'm confused. The following seems contradictory. 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. Doesn't the use of a PP provider imply the data is NOT publicly available? Steve On Thu, Mar 21, 2024 at 5:04 PM Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear RDRS Standing Committee Members, Please find below the agenda for the next meeting of the Standing Committee on Monday, 25 March 2024 at 17:30 UTC. Thank you. Best regards, Feodora and Caitlin -- RDRS Standing Committee Meeting #4 Monday, 25 March 2024 at 17:30 UTC Proposed Agenda 1. Welcome 2. RDRS Usage Report • Overview of Changes from Last Report (ICANN org Support Staff) • Reactions from Standing Committee 1. RDRS Usage Metrics Report Summary Data CSV 2. Privacy/Proxy responses in RDRS (Sebastien's 14 March email – see attached) 3. Denial responses and explanation in RDRS 4. AOB _______________________________________________ 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. -- Sent by a Verified [wallet.unumid.co] <https://urldefense.com/v3/__https:/wallet.unumid.co/authenticate?referralCod...> sender<https://urldefense.com/v3/__https:/wallet.unumid.co/authenticate?referralCod...> _______________________________________________ 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.<https://urldefense.com/v3/__https:/wallet.unumid.co/authenticate?referralCod...>