RDRS - PP issue response.
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>
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 <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
[image: signature_1782455406]
+33612284445
France & Australia
sebastien@registry.godaddy
_______________________________________________ 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.
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 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 <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 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 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.
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.
Good morning, The "already public" checkbox should not be renamed as it would change the meaning and use of the checkbox. I do think that the "already public" checkbox is used almost exclusively in cases where the domain has a Privacy or Proxy service enabled. That said, this is not the only possible use case for the checkbox; a domain could have fully public registration data, in which case there's no need for an RDRS request but one is still possible. Further, some domains with P/P services will not be known to the registrar, and in some cases a registrar may choose to use RDRS to disclose the data behind the P/P service, so some domains which do use P/P would instead end up with a different response outcome. As Sebastien said, there is another ICANN process which will set requirements relating to privacy and proxy registration services; for this project we should focus on ensuring that responses are consistent so the stats make sense. Anything getting into tracking affiliated providers etc. is outside the scope of what we should be doing in this Standing Committee. If a domain uses a P/P service and the registrar discloses underlying data then they would mark it as 'disclosed' in RDRS. I expect this scenario would be rare but not impossible. Thank you, *Sarah Wyld, CIPP/E* Policy & Privacy Manager Pronouns: she/they swyld@tucows.com On 2024-03-14 4:41 p.m., Gabriel Andrews wrote:
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 1. 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>> 2. 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)? 3. 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
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 <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 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
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.
Good morning, Upon re-read it seems I misunderstood Steve's point in the email below. I'm now understanding Steve to suggest that requestor satisfaction will be a factor in the input we give to the Board for decision about whether to move forward with the SSAD. Setting aside the question of whether this is one of the data points the Board expects, I'm not sure how the registrar could possibly track requestor satisfaction when documenting outcomes. The outcome statistics track how the request was concluded: the data was disclosed, partially disclosed, denied, or already public. Wouldn't requestor satisfaction be captured in the survey that requestors should receive in each case closure notification? Thanks, *Sarah Wyld, CIPP/E* Policy & Privacy Manager Pronouns: she/they swyld@tucows.com On 2024-03-14 3:08 p.m., Sarah Wyld wrote:
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
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 <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 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 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 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.
Sarah, Thanks for your note. See comments inline below to expand and refine the point. Steve On Mon, Mar 18, 2024 at 7:35 AM Sarah Wyld <swyld@tucows.com> wrote:
Good morning,
Upon re-read it seems I misunderstood Steve's point in the email below.
I'm now understanding Steve to suggest that requestor satisfaction will be a factor in the input we give to the Board for decision about whether to move forward with the SSAD.
Yes, requestor satisfaction should be a key factor for the board to consider. I would expect they will be interested and perhaps require input from multiple sources, not just us. We don't have the time and resources to gather requestor satisfaction, needs, etc. We're all smart, well intentioned, and thoughtful, and we're devoting quality time, so we may indeed have some useful things to say, but we're not in a position to be the ultimate arbiters of what the requestors need or the extent of their satisfaction. The only organized channels for the requestors to express themselves are the survey form and a handful of venues controlled by staff or the contracted parties. This is why some of us organized the requestor session in San Juan. There should be additional engagement with existing and potential requestors. See below. Setting aside the question of whether this is one of the data points the
Board expects, I'm not sure how the registrar could possibly track requestor satisfaction when documenting outcomes.
Complete agreement. The good news is that it is not up to the registrars to make the final judgment on requestor satisfaction.
The outcome statistics track how the request was concluded: the data was disclosed, partially disclosed, denied, or already public.
Wouldn't requestor satisfaction be captured in the survey that requestors should receive in each case closure notification?
Well, the survey responses will capture some data. That said, some basic questions come quickly to mind. 1. What sort of bias is built into the survey questions? 2. What isn't being asked for? How much room is there for anecdotal responses? 3. Of the people who use the RDRS, how many respond via the survey? What do the requestors who do not respond to the survey think? 4. How do we reach the people who are not using the RDRS but nonetheless are potential requestors? Finally, I surely hope the board's choices are broader than whether or not to proceed with SSAD in the form it was proposed. Thanks, Steve sender
participants (4)
-
Gabriel Andrews -
Sarah Wyld -
Sebastien＠registry.godaddy -
Steve Crocker