Following up on Gabe's comment to get the ball rolling and to be more precise about my endorsement of the Greenberg model. Here are my comments on each of its 7 commandments. 1. Since there does not seem to be any appetite for designing and implementing a P/P accreditation program separate from the RAA, all P/P providers should be accredited via clauses in the RAA. We can later work out whether this is not by Opt-out, Opt-in or simply by having the appropriate clauses apply IF a P/P service is to be offered. Either of the last two will probably be easier to implement, given the rest of my proposal → Agreed. The accreditation framework should take the form of a simple annex to the RAA, allowing registrars that already offer P/P services, or intend to do so, to opt in without friction. 2. P/P providers are defined as those entities that provide P/P services and are bound by the aforementioned provisions of the RAA. Any registration must therefore either provide the name and contact information of the beneficial user, or provide the equivalent information of the P/P provider. → Agreed. Accredited P/P providers supply the underlying registrant data to the registrar, which in turn escrows it with the ICANN-approved escrow agent. 3. This removes any concern with “knowingly”, because the only P/P providers meeting the definition ARE known. → Agreed. Any registration NOT making use of an accredited registrar P/P service is automatically treated as a standard registration, with the registrant being the person identified in the RDDS (which may also be redacted but that’s a story for another day). 4. The sections of the RAA that require obligations to be passed down to resellers will apply to any P/P provisions as well. → Agreed. Resellers offering the registrar's P/P service are bound by those same terms. Conversely, a reseller operating an unaccredited service is treated as a regular registrant: their details are escrowed, they bear registrant liability, and no underlying data is disclosed to UDRP providers. 5. These same provisions must require these same obligations to be passed down to any resellers of resellers (and all the way down the chain). → Same as 4. The chain-of-obligation principle applies at every level, without exception. 6. P/P providers associated with the reseller chain must notify their registrar and thus ICANN. Presumably, there will also be a flag in the public registration data indicating that a P/P provider is involved. → Same as 4 on the notification obligation. On the flag: I reiterate my proposal that P/P providers be required to include their IANA number, or a specific accreditation number allocated by ICANN, in the RDDS registrant name field. This would allow the public to know there is an underlying registrant and where to contact the PP provider (their details being published on the ICANN website along with the registrar they are affiliated with). 7. Since all of these possible P/P providers are bound by the applicable RAA clauses, all registration data, including those with P/P provided by resellers, will be subject to Escrow requirements protecting registrants, in the case of reseller failure. → Same as 4. The escrow obligation follows the P/P service accreditation, regardless of where in the reseller chain the P/P service originates. From: Gabriel Andrews <gfandrews@fbi.gov> Date: Thursday, 21 May 2026 at 17:07 To: gdd-gnso-ppsai-impl@icann.org <gdd-gnso-ppsai-impl@icann.org> Cc: Luc SEUFER <lseufer@namespace.com>; Alan Greenberg <greenberg.alan@gmail.com>; Jessica Puccio <jessica.puccio@icann.org> Subject: RE: [Gdd-gnso-ppsai-impl] Re: REMINDER: PPSAI IRT Task PPSAI Colleagues – I suggest we further explore ALAC’s proposal. Of particular interest to myself and GAC colleagues are: • Exactly how contractual obligations – belonging to the Registrar – would be propagated “downstream”. • Clearly identifying how proxy programs operated by Resellers (at any point in the domain resale chain) or any third parties are addressed by policy. • Ensuring that important customer-protecting ICANN initiatives – such as data escrow and informing customers of their rights and responsibilities – are fit for purpose. • Clarity as to whether/how ICANN Compliance can meaningly enforce pass-through requirements. We anticipate GAC conversation on these issues and principles in Seville. We wished to note our interest early so as to encourage further discussion of this proposal. From: Luc SEUFER via Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>> Sent: Wednesday, May 6, 2026 12:53 PM To: PPSAI IRT members, including observers <gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>> Cc: Jessica Puccio <jessica.puccio@icann.org<mailto:jessica.puccio@icann.org>>; Alan Greenberg <greenberg.alan@gmail.com<mailto:greenberg.alan@gmail.com>>; Luc SEUFER <lseufer@namespace.com<mailto:lseufer@namespace.com>> Subject: [EXTERNAL EMAIL] - [Gdd-gnso-ppsai-impl] Re: REMINDER: PPSAI IRT Task Can we implement Alan’s proposal and finalise this IRT? I am very supportive of it. Luc From: Alan Greenberg via Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>> Date: Wednesday, 6 May 2026 at 05:39 To: PPSAI IRT members, including observers <gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>> Cc: Jessica Puccio <jessica.puccio@icann.org<mailto:jessica.puccio@icann.org>>; Alan Greenberg <greenberg.alan@gmail.com<mailto:greenberg.alan@gmail.com>> Subject: [Gdd-gnso-ppsai-impl] Re: REMINDER: PPSAI IRT Task I've lost track of which documents are still open for comments and which are closed. And despite Jessica's suggestion that we continue the discussion on the list, I have seen no traffic. So in preparation for our meeting this week, I thought I would recap the proposal that I made towards the end of our last meeting. 1. Since there does not seem to be any appetite for designing and implementing a P/P accreditation program separate from the RAA, all P/P providers should be accredited via clauses in the RAA. We can later work out whether this is not by Opt-out, Opt-in or simply by having the appropriate clauses apply IF a P/P service is to be offered. Either of the last two will probably be easier to implement, given the rest of my proposal 2. P/P providers are defined as those entities that provide P/P services and are bound by the aforementioned provisions of the RAA. Any registration must therefore either provide the name and contact information of the beneficial user, or provide the equivalent information of the P/P provider. 3. This removes any concern with “knowingly”, because the only P/P providers meeting the definition ARE known. 4. The sections of the RAA that require obligations to be passed down to resellers will apply to any P/P provisions as well. 5. These same provisions must require these same obligations to be passed down to any resellers of resellers (and all the way down the chain). 6. P/P providers associated with the reseller chain must notify their registrar and thus ICANN. Presumably, there will also be a flag in the public registration data indicating that a P/P provider is involved. 7. Since all of these possible P/P providers are bound by the applicable RAA clauses, all registration data, including those with P/P provided by resellers, will be subject to Escrow requirements protecting registrants, in the case of reseller failure. Alan On Wed, Apr 29, 2026 at 8:59 AM Jessica Puccio via Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>> wrote: Hello PPSAI IRT - A quick reminder to continue the conversation on the PPSAI email list regarding potential solutions to the outstanding issues for alignment. Your input is important to help better understand the IRT perspectives and further develop proposed next steps. Current materials for reference are listed below: * Review of Feedback on Outstanding Issues for Alignment<https://docs.google.com/document/d/182kwPsXtyjZ2zPrhlcdtdM1NWsyp0XKt/edit> * The Zoom recording and transcript are available here<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/spaces...>. Note: ICANN org is in the process of developing proposed next steps for resolving outstanding issues based on 23 April discussion and responses on list. Our upcoming session will be Thursday, 07 May at 15:30 UTC (timezone converter here<https://www.timeanddate.com/worldclock/converter.html>). Meeting Objective: Review proposed next steps and determine the path forward. Attached is the .ics file for your records. Kind Regards -- Jessica Puccio Sr Coordinator, Review Support and Accountability Projects Internet Corporation for Assigned Names and Numbers (ICANN<http://www.icann.org/>) _______________________________________________ Gdd-gnso-ppsai-impl mailing list -- gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org> To unsubscribe send an email to gdd-gnso-ppsai-impl-leave@icann.org<mailto:gdd-gnso-ppsai-impl-leave@icann.org> _______________________________________________ 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.