Not in a million years I thought I would get to argue with Becky Burr over the picket fence. I still wear my picket fence pin proudly and here I am a little too brave and want to disagree! But at the same time, I like Becky's suggestion. See below, This is not a picket fence issue. If it was, this whole exercise of SSAD and disclosure would be outside of the picket fence—unless you want to make it narrow and say we only oblige the registrar to respond to requests that are about security of the Internet and DNS. I like that approach, but we aint doing that here. Not all these disclosure requests contribute to the resiliency security of the Internet/DNS. So I don't agree with it and I think invoking 'picket fence' to argue against something should be done cautiously, because frankly it comes across as a bit one-sided when applied to this exercise. But I personally can live with your solution, Becky. I think it's elegant. ICANN should not put the domain name registrant human rights and privacy at risk with its policy. I can accept that. And the OECD guidelines have impact assessment framing under their accountability and risk-management frameworks. I’d like to just add a paragraph to the text so everyone is on the same page about what this baseline entails. I don't care where exactly it can be as long as it doesn't get lost. "Globally recognized privacy principles” are frameworks such as the OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data. Implementation of these principles generally requires that any data processing or disclosure be proportionate to a specified, legitimate purpose, and subject to an accountability framework that balances fundamental rights and assesses the inherent risk of harm to the data subject’s fundamental rights. I hope this is acceptable. Farzaneh On Tue, Jun 23, 2026 at 4:41 PM Becky Burr via Gnso-ssad < gnso-ssad@icann.org> wrote:
The language of Recommendations 8.3 and 8.4 is fundamentally inconsistent with the picket fence. We cannot draft a policy that constrains the registrar's ability to make lawful disclosures unless doing so would undermine the stability, security, and resilience of the DNS/Internet. We *can* draft a policy that says ICANN cannot obligate a CP to disclose personal information where doing so would violate globally recognized privacy principles, e.g., the OECD principles.
For example, the current draft says:
As part of its review, the Contracted Party MUST consider if the impact on the human rights of the data subject prevents disclosure and MAY conduct a balancing test as part of its review.
We all support respect for human rights, including privacy, but ICANN does not have authority to establish a global human rights/privacy policy for registrant data disclosure. In addition, the proposed policy is unenforceable. It literally says that ICANN Compliance can require a CP to demonstrate that it considered the human rights impact before disclosing registrant data.
The policy is simple:
The Contracted Party must disclose the requested information if it determines that doing so is (i) compliant with applicable law and (ii) does not violate globally recognized privacy principles.
We can define “globally recognized privacy principles” to mean, for example, the OECD principles.
Note, this issue (constraining the Contracted Party’s behavior within the limits of applicable law rather than constraining ICANN’s enforcement authority) reappears throughout the straw person document.
[image: Logo] <https://www.thenew.org/> *Becky Burr **| Senior Policy Advisor* *bburr@pir.org <bburr@pir.org>* | http://www.pir.org | *Power your inspiration. Connect your world.* *[image: Image]*
*From: *Steve Crocker via Gnso-ssad <gnso-ssad@icann.org> *Date: *Friday, June 19, 2026 at 12:31 PM *To: *Anderson, Marc <mcanderson@verisign.com> *Cc: *gnso-ssad@icann.org <gnso-ssad@icann.org> *Subject: *[Gnso-ssad] Re: SSAD SRT - updated Rec 8 language
Marc,
Thanks for passing this along. Rereading the recommendation, I realized something fundamental is missing. This Recommendation focuses on the obligations and latitude the Registrar has when making a disclosure determination. In my opinion, the Registrant's preference is missing. If the Registrant wants their contact details disclosed, that should be the only consideration. Further, if the Registrant wants their contact details disclosed to specific types of Requestors, that should be the only consideration for requests from those types of Requestors.
This is part of a larger and peculiarly unaddressed aspect of the overall policy: why is contact information collected in the first place, and what are the obligations and authority of the people listed in each role?
I have no issue with protecting the registrant and other contacts against various forms of abuse, from human rights violations to spam, but the registrant should have the final say and not be second-guessed if they intend for their information to be available.
The above should not be misinterpreted to suggest that each request requires a decision from the registrant. That would be very expensive and inefficient if required for every disclosure decision. Instead the registrar can provide the registrant with a clear picture of how their contact information will be handled in response to various request types. And perhaps some registrars would also be willing to give the registrants some choice when they provide their contact information.
Thanks,
Steve
Steve
On Fri, Jun 19, 2026 at 11:18 AM Anderson, Marc via Gnso-ssad < gnso-ssad@icann.org> wrote:
SSAD SRT members,
The strawperson document has been updated with revised Rec 8 language.
https://docs.google.com/document/d/17N6Y3yYUmbfbAFO6QwR8S1u0uZY0HxKYc8HaadBQ...
Please take a look and provide feedback either in the google document or on the list. If you have issues or concerns with the language; proposing new text to address is helpful. You will see in the document that staff has kept the side-by-side text with redlines. Following that, staff has added a new section with a clean version of the proposed draft recommendation to help with review. In addition, staff has also provided the following changelog of the high-level changes made following our discussion at ICANN 86:
*Recommendation 8*
- Personal Data has been capitalized and added to the glossary. (The glossary definition matches the definition in the Registration Data Policy.) - 8.1 has been crossed out due to a comment that a Contracted Party can determine how to review requests and could determine, based on its own risk assessment, that it can review certain requests in bulk. (In other words, the policy should not dictate this.) - 8.3 has been modified slightly to address multiple concerns expressed during ICANN86: - the Contracted Party MUST consider if the impact on the human rights of the data subject prevents disclosure and - MAY conduct a balancing test as part of its review. (A footnote has been added to clarify that a Contracted Party may choose to apply a GDPR balancing test for all disclosure requests, even those falling outside of GDPR, and this policy would not prevent this.) - 8.4 has been modified to clarify that Contracted Parties MUST disclose if they are able to under applicable law, subject to human rights assessment and applied balancing tests.
Thank you,
Marc Anderson _______________________________________________ Gnso-ssad mailing list -- gnso-ssad@icann.org To unsubscribe send an email to gnso-ssad-leave@icann.org
--
_______________________________________________ Gnso-ssad mailing list -- gnso-ssad@icann.org To unsubscribe send an email to gnso-ssad-leave@icann.org
