I am apology for today as well. ________________________________ From: Gnso-rdrs-sc <gnso-rdrs-sc-bounces@icann.org> on behalf of Steve Crocker <steve@shinkuro.com> Sent: Monday, March 25, 2024 8:54 AM To: Caitlin Tubergen <caitlin.tubergen@icann.org>; 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 Apologies for today. Despite my absence today, I remain interested in clarification of the meaning of "all data is publicly available." Thanks, Steve On Fri, Mar 22, 2024 at 6:38 AM Steve Crocker <steve@shinkuro.com<mailto:steve@shinkuro.com>> wrote: 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 [Sent by a Verified sender] <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y> sender -- Sent by a Verified [Sent by a Verified sender] <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y> sender

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), 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 of the Temporary Specification. Thanks Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN 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 Welcome RDRS Usage Report · Overview of Changes from Last Report (ICANN org Support Staff) · Reactions from Standing Committee RDRS Usage Metrics Report Summary Data CSV Privacy/Proxy responses in RDRS (Sebastien's 14 March email – see attached) Denial responses and explanation in RDRS 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] sender

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

[image: Image removed by sender. Sent by a Verified sender] [wallet.unumid.co] <https://urldefense.com/v3/__https:/wallet.unumid.co/authenticate?referralCod...>

sender

_______________________________________________ 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.

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

Hi Alan, I wanted to respond to your questions regarding the metrics. Apologies for the delay. Please see in line comments to your questions in red below. Thanks Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN From: Gnso-rdrs-sc <gnso-rdrs-sc-bounces@icann.org> on behalf of Alan Greenberg <greenberg.alan@gmail.com> Date: Monday, March 25, 2024 at 8:41 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 For discussion under item 2: I am still having problems reconciling Metric 9 and the chart on page 11. Presuming that the column count refers to the number at the left of the column, the total number of requests comes to 756 but the number reported under Metric 5 is 754. The numbers balanced for last month but were out by 19 in the first report. This table is important, because it allows one to derive the number of active requestors each month (by totalling the heights of the columns), a figure not otherwise reported. Regarding reconciling Metric 9 with chart on page 11, this is a histogram which is based on a range of data. The bars represent a range of values between the two numbers, so adding numbers together does not get you the actual totals. The histogram is live as of time of pulling (preparing the report for publication), so comparing/reconciling with Metric 5 (that is date bound) isn’t really possible. On another topic, unless I am missing something (quite possible!), I do not see reported the number of requests attempts rejected due to non-participating registrars or other non-applicable TLDs (perhaps broken down by gTLD, ccTLD, other) nor do I see a report of the number of registrars who received requests in the month. These would seem to be important metrics. There isn’t really a rejection due to non-participating registrar. The user is prompted up front in the event of a non-participating registrar that they can still fill out the form and download it to send it to the non-participating registrar directly. We have metrics on lookup status (Metric 10)  and on the PDF export portion for non-participating registrars (Metric 6.1) and we’ve now added Metric 6.2 for PDF export for participating registrars. Lastly, and perhaps related, I am having trouble reconciling Metrics 3/4 to the total number of disclosure requests.  Metric 3/4 is the numbers of users having accessed RDRS in a given time frame only. If you are trying to determine the total number of users that submitted requests in a given time frame, that is not a metric we currently show. Alan On Thu, Mar 21, 2024 at 8: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 Welcome RDRS Usage Report · Overview of Changes from Last Report (ICANN org Support Staff) · Reactions from Standing Committee RDRS Usage Metrics Report Summary Data CSV Privacy/Proxy responses in RDRS (Sebastien's 14 March email – see attached) Denial responses and explanation in RDRS 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.