Volker,

Thanks for your thoughtful reply. That said, I disagree on multiple points.

Declaring my points out of order because they have already been decided is one of the seriously broken aspects of the ICANN policy development process. If a policy decision has been made in the past, and it was based on a careful consideration of the issues and competing values, that's fine. I'm not arguing that every policy decision should be open for review and change. On the other hand, in my view, there are previous decisions that have been based on poor or incomplete reasoning, and the effect leads to continuing complications. At what point and by what means do we, as a community, step back and say we need to straighten out the underpinnings? Seemingly small accommodations along the way sometimes create much larger problems in future years. Overloading the use of data elements is an example of this sort of problem. (Using the whether organization field is filled in or blank to determine whether the registrant is a natural or legal person is an example. Using the registrant's contact data elements to fill in the privacy provider contacts is another.). And there are other examples where mistakes in the underlying structure are ignored because no one wants to change the existing structure, with consequences that the overall system becomes unwieldy or unable to deal with important distinctions.

On Tue, Aug 5, 2025 at 9:32 AM Volker Greimann <volker.greimann@centralnic.com> wrote:

Hi Steve,

thank you for your questions, but I feel this IRT is not really the place for them. We are not here to discuss the question of whether such services should exist at all, as that would be the scope of a new PDP. We are here to discuss how to best ensure that the same rules apply to providers as to other parties in the ecostructure. This was partially covered by the new contractual framework included in the 2013 RAA but it was missing a piece of the puzzle as this only applied to such providers that were affiliated with a registrar.

The nature of privacy and proxy providers has been extensively covered in the orginal PDP and there really is no course of action or need to re-open that part of our work.

If the registrant's contact data elements are used for the privacy provider's contact info, where is the registrant's contact data? And if you say, that's out of scope or it's perfectly ok for the registrant's contact data not to be provided, how do you reconcile that with a requirement for accurate information about the registrant? Depending on the jurisdiction, some registrars are required to have accurate contact data and to provide that data to appropriate requestors.

I am willing to indulge your points and would like to present the following counter-points.

You call the provision of a different correspondence address "a mistake". It is not a mistake: It is a completely legitimate and policy-compliant service to protect the privacy of a registrant while at the same time ensuring contactibility - the original purpose of what used to be whois. For this purpose, it frankly does not matter whose addres it is, it only matters whether the registrant can be reached through this address. We need no new role for this as the existing role fulfills this function already.

Proxy providers (and by extention: local presence service providers) are indeed the registrants, even though they are not the beneficial owners or users of a domain name. For this role, it is mostly irrelevant whether they are advertised as such or not, but it may make a difference for legal liability purposes "in the real world". Their responsibilities towards the beneficial owner are usually regulated by an agreement that is internal to their relationship.

How is the requestor supposed to know whether the listed registrant is or is not a proxy provider?

"Potential policy conflict": Frankly, I can see no such conflict. The registrar is fully compliant with its obligations, as is the registrant of record.

The registrar is fully compliant only superficially. If the registrar knows the registrant is a proxy provider, responding with the name of the proxy provider but not making it clear to the requestor that the registrant is a proxy provider is disingenuous.

Thanks,

Steve

Sincerely,

Volker Greimann
General Counsel & Head of Policy and Compliance - Online Division

volker.greimann@centralnic.com
Office: +49-172-6367025
Web: www.teaminternet.com

Team Internet Group PLC (AIM:TIG). Registered Office: 4th Floor, Saddlers House, 44 Gutter Lane, London, United Kingdom, EC2V 6BR. Team Internet is a company registered in England and Wales with the company number 8576358.

From: Steve Crocker via Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl@icann.org>
Sent: 05 August 2025 3:17 AM
To: gdd-gnso-ppsai-impl@icann.org <gdd-gnso-ppsai-impl@icann.org>
Cc: Steve Crocker <steve@shinkuro.com>
Subject: [Gdd-gnso-ppsai-impl] Solution for privacy and proxy registrations

PPSAI folks,

I've given some thought to Privacy and Proxy Providers.

Privacy and Proxy providers are qualitatively different.

Privacy providers provide alternative contact details -- email, phone, physical address -- but do not obscure the registrant's identity. The purpose is to route correspondence to people who are designated to accept and act on the registrant's behalf, and to avoid disclosing the registrant's direct contact details.

In the normal physical world, this is accomplished by explicitly designating a correspondence address.

In the current implementations of registration data, inserting the correspondence address into the data elements allocated to the registrant's contact is mistake that has two consequences.

It obscures the fact that the contact data is not related to the registrant but is, instead, contact data for a different role.

It makes it impossible to include registrant contact information in the database that may -- or should -- be available to authorized requestors.

The correct path forward is to define a new role, Correspondent. This role is optional. If it is included, it indicates where correspondence should be directed. This data should usually be public. In contrast, the registrant's address, etc. can be private and not disclosed in response to normal requests.

Proxy providers fall into two categories, known and unknown.

Unknown proxy providers should be treated as ordinary registrants. That is, they should be presumed to be the actual registrant, with all of the rights, privileges, responsibilities and obligations as any other registrant.

Known proxy providers should be identified as such. One possible way to do so is to extend the distinction between Natural and Legal Persons to include a third category, Known Proxy Provider. They are the legal registrants, with the full set of rights, privileges, responsiblities and obligations as other registrants, but it will be important to many requestors to know that the registrant is actually a proxy provider.

The concept of Known Proxy Provider is not the same as an accredited proxy provider. Accreditation presumably implies an agreement with the proxy provider to adhere with some rules regarding disclosure to appropriate requestors. The concept of a Known Proxy Provider simply conveys to the requestor that the registration has been carried out by a proxy provider, but there is no implication as to what the proxy provider will do when asked to reveal the beneficial registrant.

If it is desired to institute a process of accrediting Known Proxy Providers, we need a careful understanding of the intended purpose and a good argument as to why it will work. In the current environment, there are no rules barring someone from using a proxy provider and no rules requiring that proxy providers be identified. Registrars are likely to be able to identify well known proxy providers and add that detail to their registration data, but I do not see any reliable mechanism for identifying a proxy registration when the proxy provider does not want to be known as a proxy provider.

Proxy providers pose a potential policy conflict

Registrars have obligations to collect accurate registration data, and they have an obligation to protect that data from inapprpriate disclosure. Where does a proxy provider fit into this picture? What service does it provide that is not in conflict with the registrar's role?

Thanks,

Steve

--

Sent by a Verified

sender