Gabe. That's a good post, but I was also expecting the most obvious case to be included, viz that "public" might also indicate the registrant has supplied actual registrant information and has chosen to make it public. (Or, equivalently, the registrar has chosen to make it publicly available.) When I sat down quite some time ago to think through the various cases, I settled on the following: - P0 = the information is the registrant's actual data. - P1 = the information is veiled behind a privacy or proxy service affiliated with the registrar - P2 = the information is veiled behind a privacy or proxy service that is not affiliated with the registrar - P3 = the information is veiled behind another party, not known to be a proxy service. (Note the absence of a privacy provider.) For all practical purposes, P3 data should be treated as P0 data in the sense that the proxy provider bears full legal responsibility and authority. If the named registrant is acting on behalf of someone else, that's a private arrangement. I've never been persuaded that resellers are a distinct case. In my view, resellers are agents of registrars, and their responses should be treated as if they came directly from the registrar. It doesn't make sense for a registrar to wash their hands of a reseller's response. Thanks, Steve On Mon, Mar 25, 2024 at 3:00 PM Gabriel Andrews <gfandrews@fbi.gov> wrote:
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> 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> 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> on behalf of Steve Crocker <steve@shinkuro.com> *Date: *Friday, March 22, 2024 at 6:39 AM *To: *Caitlin Tubergen <caitlin.tubergen@icann.org> *Cc: *"gnso-rdrs-sc@icann.org" <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> 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 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...>
-- Sent by a Verified [image: Sent by a Verified sender] <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y> sender