Volker, Thanks for taking the time to read my memo and ask questions. See responses below. Steve On Thu, Aug 5, 2021 at 4:42 PM Volker Greimann <vgreimann@key-systems.net> wrote:

Hi Steve,

I fail to see how this admittedly succinct summary of the existing options helps us move ahead the discussion as this basically only reflects the discussions we have over the past months. At this point, we are likely either at option 7 or 8, which incidentally also describe the status quo.

7 and 8 are exact opposites. 7, i.e. {C, O, N}, says any registrar subject to this policy may choose to require the distinction, may make it optional for the registrant to provide it, or may choose not to ask the registrant at all. Thus, this puts no constraint on the registrar. 8, i.e. {}, is a red flag. It says no matter what the registrar does, it does not conform to this policy. The registrar is prohibited from collecting the data, is prohibited from making it optional, and is prohibited from not collecting it. This combination is included for logical completeness, but would not be an acceptable policy. See below for the reason for including this combination. This set of possibilities exists within a larger context. Here are four aspects of the larger context. 1. We presume the data element is defined. The existence of the data element in the data dictionary is distinct from any policy about whether it is or is not collected, whether it is or is not used in any decisions, and whether it or any other piece of data is disclosed. (We further expect the data dictionary is a publicly available structure available to and used by essentially all registration systems, i.e. throughout the address, ccTLD and gTLD communities.) 2. A separate part of the model is the level of validation applied to the data. In SSAC report SAC 058, there are three levels defined, but there is also an implicit fourth level at the bottom of the scale. The four levels are: - V0 = Accept whatever the registrant provides - V1 = Check the registrant's input for syntactic conformance - V2 = Check the registrant's input for plausible correctness - V3 = Apply very strong checks to ensure the registrant's input is verifiably correct In parallel with what I've described for collection, each registrar will have its own rule for the degree of validation, and GNSO will have its rule for what possibilities are permitted for registrars subject to its policy. For example, if the GNSO policy is V3, then every registrar would have to apply very strong checks on the data. On the other hand, if the GNSO policy is {V0, V1, V2, V3}, each registrar would be free to set its own rule for the degree of validation. (This aspect addresses part of what Stephanie has been talking about, though I think she is saying that without a uniform level of validation, it's inappropriate to use the data.) 3. A given registrar will usually be subject to multiple rules. In addition to whatever ICANN imposes, the registry may have a rule, and one or more governments may have a rule. Thus, a registrar's rule will have to conform to all of these. If the rules are presented in the form I've suggested, it's easy to see how they all interact. And it's possible for these multiple rules to be inconsistent with each other. For example, if ICANN says it's ok to offer to the registrant the option of providing the data but it is not ok to require it, i.e. Optional, but the government says it's mandatory to collect the data, then the registrar is stuck. If the registrar requires it, they would not be compliant with ICANN, and if they don't require it, they would not be compliant with the government. If you take two rules and compute the set intersection, i.e. the list that is common to both, you'll get the maximum set of possibilities. In the example above, the result will be the empty set, i.e. the eighth possibility I listed, and this would indicate an impossible position for the registrar. 4. All of the above is distinct from whether this data is used for decisions and whether it or any other data is disclosed. That's a separate part of the model and requires a bit more explanation. I'll leave this for another time. The real issues start after making these basic definitions as there are

complexities down the line following from the designations: a) In case of C or O, does that lead to partial publication based on the designation?

As I indicated in part 4 of my response above, there has to be a separate specification as to whether to disclose the data. ("Publication" is not an accurate term in this context. No data is published in the sense that word is usually used. The data is only available in response to queries, and each query, even queries from anonymous members of the public, are processed individually.)

Does it lead to forwarding the designation to the registries? How would/should the registries treat those designations received?

As with all data collected by the registrar, if the registry requires the data, the registrar has to forward it. Some data collected by a registrar, e.g. payment details, is never forwarded to the registry. Some data, e.g. DNS records and perhaps expiration date, is always forwarded to the registry. For other data, it will depend on whether the registry is a thin or thick registry.

Can they rely on them? Will they rely on them without burdening registrars with further liability and indemnification requirements?

I think you're asking whether the level of validation carried out by the registrar meets the requirements of the registry. Part of the registry's rules will include what level of validation is required.

b) What happens down the road? Will agreeing to optional fields immediately lead to calls for them to be made into requirements by future work?

There has to be a continuing governance process that manages the process of changing the rules. There's no reason to expect that decisions made by consensus at a given time will be changed later without a comparable consensus process. Hope this helps. Steve

Best, -- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*

T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net

Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner

Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.

This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.

On Thu, Aug 5, 2021 at 5:26 PM Steve Crocker via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:

...

The attached note is a summary of the possible policies regarding Natural vs Legal vs Unspecified _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.

Volker, Thanks for your reply. Re 7 vs 8, yes, the registrar can always do what it wants, and, yes, the law supersedes the contract. The point re 8, however, is the registrar will necessarily be non-compliant with the policy. Re future changes, one of the uses of this sort of documentation and analysis is to remove ambiguities. It will then much harder for the implementers or enforcers to adjust the rules without going through the formal policy development process. Steve Sent from my iPhone

On Aug 6, 2021, at 8:00 AM, Volker Greimann <vgreimann@key-systems.net> wrote:

 Hi Steve,

I do not see 7 and 8 as mutually exclusive as the net effect is the same. The status quo is that the registrar can differentiate internally if he wants to. Whether or not there is a GNSO policy saying the same is of little consequence. But I agree that policy confirming the status quo would be preferable.

With regard to SAC 058, the status quo of existing ICANN requirements, the status quo currently mainly is V1 with either the mail address or the phone number being subject to V3-level checks. Notably this applies only to the address details, not the identity data, which are a couple of magnitudes more difficult to validate (or verify).But even for the currently required V3-level checks, the choice of how to do these is entirely left to the registrar to decide. That kind of freedom of implementation is necessary to keep enabling all existing (and potentially future) registrar business models.

I do not agree that the registrar would be stuck in case there is a conflict between ICANN mandates and government mandates as applicable law always supersedes ICANN policies or contractual requirements and the registrar is thus free to ignore them. While this seems undesirable from a policy perspective, it already is the contractual reality. To avoid these conflicts however, a policy outcome that already enables a registrar to comply with any possible regulation, e.g. that gives the registrar the choice what to implement and how to implement it is preferable.

...

I think you're asking whether the level of validation carried out by the registrar meets the requirements of the registry. Part of the registry's rules will include what level of validation is required. No, my main question aimed at if either ICANN policy or Registry policies require the processing and transfer of certain data for processing and potential disclosure or publication by the registry this would with near absolute certainty lead to higher legal risks to be borne exclusively by the registrar as every registry will seek to protect itself from potentially false designations or determinations by the registrar by saddling the registrar with the entirety of the legal and financial risk.

...

There's no reason to expect that decisions made by consensus at a given time will be changed later without a comparable consensus process. Sadly, having participated in various non-PDP efforts within ICANN such as review teams and RAA negotiation groups, this is not entirely correct. There will always be strong efforts by interested parties to expand the horizons of what has already been agreed to. As an example, I will just point to the attempts to end the grandfathering rules regarding registration data verification and validation that occurred in the whois review team or the requirement to sign the 2013 RAA early if a registrar wanted to sell the new gTLDs. Interested parties will continue to lobby for their interests and attempt to get them passed in venues outside the PDP process if they perceive the chances to succeed there as slim.

Best,

-- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH

T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net

Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner

Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.

This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.

...

On Fri, Aug 6, 2021 at 12:14 AM Steve Crocker <steve@shinkuro.com> wrote: Volker,

Thanks for taking the time to read my memo and ask questions. See responses below.

Steve

...

...

On Thu, Aug 5, 2021 at 4:42 PM Volker Greimann <vgreimann@key-systems.net> wrote: Hi Steve,

I fail to see how this admittedly succinct summary of the existing options helps us move ahead the discussion as this basically only reflects the discussions we have over the past months. At this point, we are likely either at option 7 or 8, which incidentally also describe the status quo.

7 and 8 are exact opposites. 7, i.e. {C, O, N}, says any registrar subject to this policy may choose to require the distinction, may make it optional for the registrant to provide it, or may choose not to ask the registrant at all. Thus, this puts no constraint on the registrar.

8, i.e. {}, is a red flag. It says no matter what the registrar does, it does not conform to this policy. The registrar is prohibited from collecting the data, is prohibited from making it optional, and is prohibited from not collecting it. This combination is included for logical completeness, but would not be an acceptable policy. See below for the reason for including this combination.

This set of possibilities exists within a larger context. Here are four aspects of the larger context. We presume the data element is defined. The existence of the data element in the data dictionary is distinct from any policy about whether it is or is not collected, whether it is or is not used in any decisions, and whether it or any other piece of data is disclosed. (We further expect the data dictionary is a publicly available structure available to and used by essentially all registration systems, i.e. throughout the address, ccTLD and gTLD communities.)

A separate part of the model is the level of validation applied to the data. In SSAC report SAC 058, there are three levels defined, but there is also an implicit fourth level at the bottom of the scale. The four levels are: V0 = Accept whatever the registrant provides V1 = Check the registrant's input for syntactic conformance V2 = Check the registrant's input for plausible correctness V3 = Apply very strong checks to ensure the registrant's input is verifiably correct

In parallel with what I've described for collection, each registrar will have its own rule for the degree of validation, and GNSO will have its rule for what possibilities are permitted for registrars subject to its policy. For example, if the GNSO policy is V3, then every registrar would have to apply very strong checks on the data. On the other hand, if the GNSO policy is {V0, V1, V2, V3}, each registrar would be free to set its own rule for the degree of validation. (This aspect addresses part of what Stephanie has been talking about, though I think she is saying that without a uniform level of validation, it's inappropriate to use the data.)

A given registrar will usually be subject to multiple rules. In addition to whatever ICANN imposes, the registry may have a rule, and one or more governments may have a rule. Thus, a registrar's rule will have to conform to all of these.

If the rules are presented in the form I've suggested, it's easy to see how they all interact. And it's possible for these multiple rules to be inconsistent with each other. For example, if ICANN says it's ok to offer to the registrant the option of providing the data but it is not ok to require it, i.e. Optional, but the government says it's mandatory to collect the data, then the registrar is stuck. If the registrar requires it, they would not be compliant with ICANN, and if they don't require it, they would not be compliant with the government.

If you take two rules and compute the set intersection, i.e. the list that is common to both, you'll get the maximum set of possibilities. In the example above, the result will be the empty set, i.e. the eighth possibility I listed, and this would indicate an impossible position for the registrar.

All of the above is distinct from whether this data is used for decisions and whether it or any other data is disclosed. That's a separate part of the model and requires a bit more explanation. I'll leave this for another time. The real issues start after making these basic definitions as there are complexities down the line following from the designations: a) In case of C or O, does that lead to partial publication based on the designation?

As I indicated in part 4 of my response above, there has to be a separate specification as to whether to disclose the data. ("Publication" is not an accurate term in this context. No data is published in the sense that word is usually used. The data is only available in response to queries, and each query, even queries from anonymous members of the public, are processed individually.)

...

Does it lead to forwarding the designation to the registries? How would/should the registries treat those designations received?

As with all data collected by the registrar, if the registry requires the data, the registrar has to forward it. Some data collected by a registrar, e.g. payment details, is never forwarded to the registry. Some data, e.g. DNS records and perhaps expiration date, is always forwarded to the registry. For other data, it will depend on whether the registry is a thin or thick registry.

...

Can they rely on them? Will they rely on them without burdening registrars with further liability and indemnification requirements?

I think you're asking whether the level of validation carried out by the registrar meets the requirements of the registry. Part of the registry's rules will include what level of validation is required.

...

b) What happens down the road? Will agreeing to optional fields immediately lead to calls for them to be made into requirements by future work?

There has to be a continuing governance process that manages the process of changing the rules. There's no reason to expect that decisions made by consensus at a given time will be changed later without a comparable consensus process.

Hope this helps.

Steve

...

Best, -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH

T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net

Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner

Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.

This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.

...

On Thu, Aug 5, 2021 at 5:26 PM Steve Crocker via Gnso-epdp-team <gnso-epdp-team@icann.org> wrote: The attached note is a summary of the possible policies regarding Natural vs Legal vs Unspecified _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.

On Fri, Aug 6, 2021 at 10:05 AM Mueller, Milton L <milton@gatech.edu> wrote:

I also appreciate the nice logical summary of options, Steve.

A slightly revised version of my memo is attached. The content is exactly the same, but I have included a table showing which the three possible registrar rules are consistent with each of the eight possible GNSO rules. I have also introduced "ø" as the notation for the empty set instead of "{}." This is purely a change in notation, not in meaning.

Like Volker, however, I believe that you are overlooking the fact that we have debated these options for months and have arrived firmly at option 7 (there is no distinction between 7 and 8, by the way).

In 7, each registrar is permitted to have whichever rule it chooses. In 8, no rule is acceptable. 8 is a logical possibility but, quite obviously, it leads to an impossible situation. If such a policy were ever adopted, everyone would most likely ignore it. In that event, yes, 7 and 8 would have similar effects, i.e. impose no constraint. However, when we take into account the effect of multiple policies, the combined effects of multiple rules might indeed be 8. Detecting that in advance is important. See more on this below. In the meantime, the current state of agreement is 7, i.e. the GNSO will not impose any constraint on whether a registrar always collects the registrant's status, never collects the registrant's status, or makes it optional for the registrant to state its status. Only 7 is possible, because that was the agreed outcome of phase 1 while we

explored other options in Phase 2. In Phase 2 we discovered we cannot attain sufficient agreement to move off of that equilibrium.

Some EPDP members will recall that I personally indicated a willingness to move toward something like #6. This did not fly. Neither the Contracted Parties nor my own SG would accept it, and the GAC, ALAC and two CSG constituencies still wanted something more like 1 or 2.

"Something like #6," eh? Well, 6 is: 6 = {O, N}, a registrar must either make it optional or not collect it but may not require it Meanwhile, 1 = C, i.e. every registrar collects this value 2 = O, i.e. every registrar is required to make this optional I wonder if they might have wanted 4 = {C, O}, a registrar must either collect it or make it optional I'll come back to this later in this note, but first let's look at two other parts of this puzzle. First, there are logically *four* possible values regarding the status. - "Natural," indicating the registrant has declared itself to be a natural person, i.e. an individual - "Legal," indicating the registrant has declared itself to be a legal person, i.e. a business - "Unspecified," indicating the registrant has affirmatively refused to declare as either a Natural or Legal person - "Blank," indicating the question has not been asked. Is there a distinction between the third and fourth status, and does it matter? In some cases it could well matter. In cases where it doesn't matter, there's no harm in allowing for both possibilities and then treating them the same. Second, we come to the really big question: How will this piece of information be used? I think we all expect this may play a role in what data is returned when there is a request for registration data, but this hasn't been fleshed out. In very approximate terms, the general thinking is that data about Legal persons will be publicly available and data about Natural persons will not be. But this is only the beginning of the conversation, not the end. It is helpful to think in terms of two distinct processes. One is the process of collecting the data during the time of registration. The other is the process of responding to requests for information about the registration. Let's begin with the second process. *The Request Process* Requests for registration data will come from many different parties. Some will come from the general public, and the requester will not be required to identify itself nor adhere to any rules governing use or protection of the data. Others will come from identified, authenticated and authorized requesters who have agreed to abide by a set of rules governing the use and protection of the data they receive. Requesters in the latter category are not all the same. The data they receive will likely depend on who they are and how they will be using the data. Examples of different subgroups of requesters are network operators, individual researchers, law enforcement, and IP attorneys, and within each of these subgroups there will likely be different kinds of requests. For example, we know from interviewing the members of the Public Safety Working Group they can identify five different kinds of requests, one of which is a request available to anyone and four others that request more data and come with a specific set of rules governing use and protection. At least one kind of request will come with legal paperwork, e.g. a warrant or subpoena, but other kinds of requests will not. And they aren't the only subgroup that might have different kinds of requests. What distinguishes these various kinds of requests? In the work we've been doing, it appears reasonable to express requests in terms of two concepts. One is some way of specifying which data elements are being requested. The other is to specify the level of sensitivity, a term we've been using to include whether data is marked "public" or "private." Are there more than just two levels? Well, yes, it seems so. In listening to the extended policy discussions, we have heard that if a requester is only authorized to see data elements marked "public" and the actual data element existings but is not publicly available, the response will be "redacted." However, we have also heard there are some data elements that are more sensitive, and requests from someone not authorized to see them will not be told anything about the data element. This suggests there are at least three levels of sensitivity. As a working hypothesis, we use four levels. If this turns out to be too many, it's easy to reduce the number. To recap, we think of a request as specifying the set of data elements requested and the authorized sensitivity level. The response will not include any data elements outside of the requested set nor any data elements more sensitive than the authorized sensitivity level. Of course, all of this is in addition to the identification of the requester, the statement of purpose, a pointer to the requester's credential, and agreement regarding use and protection of the requested data. Specifying the requested data elements is not a small matter. The data dictionary has around 100 distinct data elements. Each contact is a dozen or data elements, with the name, organization, phone number, fax number, email, street address, city, province or state, postal code and country treated separately. Added to these are the data elements for the DNS records, for the payment data, for the IP address used at the time of registration, the dates of registration and expiration, register locks, etc. To make it more manageable, each data element is grouped into one of several categories. A request then specifies which of these categories are requested. *The Registration Process* With the above description of the request process, we can now fill in a few details of the registration process. In broad terms, the registration process consists of collecting data from the registrant and assigning a sensitivity level to each of the collected data elements. (And, of course, reserving the domain name and getting it delegated if the registrant wants to put the domain name into service.) To accomplish this process, the registrar has a set of rules governing which data elements are required, optional or not to be collected, and what sensitivity level to assign to each collected data element. Once this process is complete, the registrar then stores the data elements and is then in a position to process requests in accordance with the agreed upon terms in a request. A further and all important addition to this short description is the registrar might have one set of rules for registrants that are Natural Persons, a different set of rules for registrants that are Legal Persons, and perhaps even a different set of rules for registrants of Unspecified status. Moreover, the status of the registrant might not be the only factor that determines which set of rules the registrant will use to complete the registration. For example, some registrars may treat registrants that need a higher level of protection differently from ordinary registrants. Celebrities and public figures are examples of Natural Persons who may need extra protection. Registrations associated with an impending business deal, e.g. product announcements, tentative mergers, etc. are examples of registrations by Legal Persons that may need extra protection. Taking the above into account, the registration process can be thought of as having an initial phase to determine which set of rules to use for the registration, and then the main phase to collect and label the rest of the registration data. *So What About Natural vs Legal?* The putative purpose in collecting the registrant's status is to restrict the disclosure of some portion of a Natural Person's registration data from being publicly accessible. In the terms described above, this means marking those data elements as more sensitive than "public." But what happens if... 1. ... the registrar doesn't collect the status? 2. ... the registrant refuses to give its status, i.e. responds "Unspecified?"As As was stated at the beginning of this note, the current GNSO policy leaves the decision about collecting the status up to the registrar, so there's no guarantee the registrar will have this data. Even so, we might imagine a GNSO policy that says something to the effect of: if you collect the registrant's status, if the registrant's status is Natural, then apply rule set 1, otherwise, if the registrant's status is Legal, the apply rule set 2, otherwise, if the registrant's status is Unspecified, apply rule set 3 if you don't collect the registrant's status, apply rule set 4 So far, I haven't seen any discussion that goes into this level of detail, nor have I seen any discussion about taking into account other aspects of the registrant such as whether they require a higher level of protection. *T**he GNSO is not the only source of rules* The GNSO is the venue for setting the rules included in ICANN's contracts with the contracted parties. The registrars and registries are obligated to adhere to the terms of the contract. However, there are other bodies that can also set rules. Governments are the obvious examples, but there might be others. Suppose a registrar is beholden to three authorities, ICANN, Government 1 (G1) and Government 2 (G2). Further, let's suppose that each body imposes its own rule. The ICANN rule will be {C, O, N}, i.e. anything is ok. Let's suppose G1's rule is {O, N}, i.e. registrars are permitted but not required to make it optional. And let's suppose G2's rule is {C}, i.e. every registrar subject to this government's rules must collect this data. The combined effect of all three rules is ø, i.e. the empty set, and there is no way a registrar can be in compliance with all of them. On the other hand, if G2's rule were loosened to {C, O}, a registrar would be in compliance if its rule were O, i.e. making it optional for the registrant to supply this data. *Conclusion* The process of specifying the rules for collection and responses to requests has only just begun. As we noted in prior comments and in our SSAC report, the focus on which data is to be marked "public" is just a small part of the overall puzzle. The extended discussions about Natural vs Legal are motivated, at least in part, by the attempt to make as much of the registration data publicly accessible because there is not yet any credible path toward an efficient and effective access system for non-public data. Steve

------------------------------ *From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Volker Greimann via Gnso-epdp-team <gnso-epdp-team@icann.org> *Sent:* Thursday, August 5, 2021 4:41 PM *To:* Steve Crocker <steve@shinkuro.com> *Cc:* EPDP <gnso-epdp-team@icann.org> *Subject:* Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified

Hi Steve,

I fail to see how this admittedly succinct summary of the existing options helps us move ahead the discussion as this basically only reflects the discussions we have over the past months. At this point, we are likely either at option 7 or 8, which incidentally also describe the status quo.

The real issues start after making these basic definitions as there are complexities down the line following from the designations: a) In case of C or O, does that lead to partial publication based on the designation? Does it lead to forwarding the designation to the registries? How would/should the registries treat those designations received? Can they rely on them? Will they rely on them without burdening registrars with further liability and indemnification requirements? b) What happens down the road? Will agreeing to optional fields immediately lead to calls for them to be made into requirements by future work?

Best, -- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*

T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net

Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner

Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.

This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.

On Thu, Aug 5, 2021 at 5:26 PM Steve Crocker via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:

The attached note is a summary of the possible policies regarding Natural vs Legal vs Unspecified _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.

All, please bear in mind that this group is not tasked with achieving a result "we like to see" but with determining whether a change from the previous result is possible, and if so, necessary. So far, no necessity has been demonstrated and even with regard to the possibility the issue of legal risk due to personal information being contained in legal entity data still remains. As such, the default stands. Sincerely, -- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Mon, Aug 9, 2021 at 1:50 PM Hadia Abdelsalam Mokhtar EL miniawi via Gnso-epdp-team <gnso-epdp-team@icann.org> wrote:

Thanks Steve for this work and this brief.

In relation to the collection rules and just to note, ultimately we would have liked to see rule number one {C} applied. Bearing in mind that rule number one does not necessary need to say "Legal" or " Natural" it can also say " unspecified". However, we do recognize that no consensus in this regard is possible. Therefore our compromised position is rule number 4 {C, O} and honestly speaking I do not understand why we cannot agree to this. The difference between 4 {C,O} and 7 {C,O,N} is that 7 allows the registrar to not offer the registrant the ability to specify. GDPR as we all know makes this distinction and therefore it is only fair to give the data subject the ability to specify if it wishes and please note here that we should not conflate what is being offered by the registrar or collected from the registrant with what is going to be available through the public RDDS.

What is going to be available through the public RDDS and the rules associated with any type of disclosure, are governed by a different set of rules which we could discuss and possibly agree to.

As for option 8, my understanding is that this option refers to a deadlock position, which is an uncommon position, however it is not 7.

Best

Hadia

*From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] *On Behalf Of *Steve Crocker via Gnso-epdp-team *Sent:* Monday, August 09, 2021 12:06 AM *To:* EPDP *Subject:* Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified

On Fri, Aug 6, 2021 at 10:05 AM Mueller, Milton L <milton@gatech.edu> wrote:

I also appreciate the nice logical summary of options, Steve.

A slightly revised version of my memo is attached. The content is exactly the same, but I have included a table showing which the three possible registrar rules are consistent with each of the eight possible GNSO rules. I have also introduced "ø" as the notation for the empty set instead of "{}." This is purely a change in notation, not in meaning.

Like Volker, however, I believe that you are overlooking the fact that we have debated these options for months and have arrived firmly at option 7 (there is no distinction between 7 and 8, by the way).

In 7, each registrar is permitted to have whichever rule it chooses. In 8, no rule is acceptable. 8 is a logical possibility but, quite obviously, it leads to an impossible situation. If such a policy were ever adopted, everyone would most likely ignore it. In that event, yes, 7 and 8 would have similar effects, i.e. impose no constraint. However, when we take into account the effect of multiple policies, the combined effects of multiple rules might indeed be 8. Detecting that in advance is important. See more on this below.

In the meantime, the current state of agreement is 7, i.e. the GNSO will not impose any constraint on whether a registrar always collects the registrant's status, never collects the registrant's status, or makes it optional for the registrant to state its status.

Only 7 is possible, because that was the agreed outcome of phase 1 while we explored other options in Phase 2. In Phase 2 we discovered we cannot attain sufficient agreement to move off of that equilibrium.

Some EPDP members will recall that I personally indicated a willingness to move toward something like #6. This did not fly. Neither the Contracted Parties nor my own SG would accept it, and the GAC, ALAC and two CSG constituencies still wanted something more like 1 or 2.

"Something like #6," eh? Well, 6 is:

6 = {O, N}, a registrar must either make it optional or not collect it but may not require it

Meanwhile,

1 = C, i.e. every registrar collects this value

2 = O, i.e. every registrar is required to make this optional

I wonder if they might have wanted

4 = {C, O}, a registrar must either collect it or make it optional

I'll come back to this later in this note, but first let's look at two other parts of this puzzle.

First, there are logically *four* possible values regarding the status.

- "Natural," indicating the registrant has declared itself to be a natural person, i.e. an individual - "Legal," indicating the registrant has declared itself to be a legal person, i.e. a business - "Unspecified," indicating the registrant has affirmatively refused to declare as either a Natural or Legal person - "Blank," indicating the question has not been asked.

Is there a distinction between the third and fourth status, and does it matter? In some cases it could well matter. In cases where it doesn't matter, there's no harm in allowing for both possibilities and then treating them the same.

Second, we come to the really big question: How will this piece of information be used? I think we all expect this may play a role in what data is returned when there is a request for registration data, but this hasn't been fleshed out.

In very approximate terms, the general thinking is that data about Legal persons will be publicly available and data about Natural persons will not be. But this is only the beginning of the conversation, not the end.

It is helpful to think in terms of two distinct processes. One is the process of collecting the data during the time of registration. The other is the process of responding to requests for information about the registration. Let's begin with the second process.

*The Request Process*

Requests for registration data will come from many different parties. Some will come from the general public, and the requester will not be required to identify itself nor adhere to any rules governing use or protection of the data. Others will come from identified, authenticated and authorized requesters who have agreed to abide by a set of rules governing the use and protection of the data they receive.

Requesters in the latter category are not all the same. The data they receive will likely depend on who they are and how they will be using the data. Examples of different subgroups of requesters are network operators, individual researchers, law enforcement, and IP attorneys, and within each of these subgroups there will likely be different kinds of requests. For example, we know from interviewing the members of the Public Safety Working Group they can identify five different kinds of requests, one of which is a request available to anyone and four others that request more data and come with a specific set of rules governing use and protection. At least one kind of request will come with legal paperwork, e.g. a warrant or subpoena, but other kinds of requests will not. And they aren't the only subgroup that might have different kinds of requests.

What distinguishes these various kinds of requests? In the work we've been doing, it appears reasonable to express requests in terms of two concepts. One is some way of specifying which data elements are being requested. The other is to specify the level of sensitivity, a term we've been using to include whether data is marked "public" or "private." Are there more than just two levels? Well, yes, it seems so. In listening to the extended policy discussions, we have heard that if a requester is only authorized to see data elements marked "public" and the actual data element existings but is not publicly available, the response will be "redacted." However, we have also heard there are some data elements that are more sensitive, and requests from someone not authorized to see them will not be told anything about the data element. This suggests there are at least three levels of sensitivity. As a working hypothesis, we use four levels. If this turns out to be too many, it's easy to reduce the number.

To recap, we think of a request as specifying the set of data elements requested and the authorized sensitivity level. The response will not include any data elements outside of the requested set nor any data elements more sensitive than the authorized sensitivity level.

Of course, all of this is in addition to the identification of the requester, the statement of purpose, a pointer to the requester's credential, and agreement regarding use and protection of the requested data.

Specifying the requested data elements is not a small matter. The data dictionary has around 100 distinct data elements. Each contact is a dozen or data elements, with the name, organization, phone number, fax number, email, street address, city, province or state, postal code and country treated separately. Added to these are the data elements for the DNS records, for the payment data, for the IP address used at the time of registration, the dates of registration and expiration, register locks, etc.

To make it more manageable, each data element is grouped into one of several categories. A request then specifies which of these categories are requested.

*The Registration Process*

With the above description of the request process, we can now fill in a few details of the registration process.

In broad terms, the registration process consists of collecting data from the registrant and assigning a sensitivity level to each of the collected data elements. (And, of course, reserving the domain name and getting it delegated if the registrant wants to put the domain name into service.)

To accomplish this process, the registrar has a set of rules governing which data elements are required, optional or not to be collected, and what sensitivity level to assign to each collected data element.

Once this process is complete, the registrar then stores the data elements and is then in a position to process requests in accordance with the agreed upon terms in a request.

A further and all important addition to this short description is the registrar might have one set of rules for registrants that are Natural Persons, a different set of rules for registrants that are Legal Persons, and perhaps even a different set of rules for registrants of Unspecified status. Moreover, the status of the registrant might not be the only factor that determines which set of rules the registrant will use to complete the registration. For example, some registrars may treat registrants that need a higher level of protection differently from ordinary registrants. Celebrities and public figures are examples of Natural Persons who may need extra protection. Registrations associated with an impending business deal, e.g. product announcements, tentative mergers, etc. are examples of registrations by Legal Persons that may need extra protection.

Taking the above into account, the registration process can be thought of as having an initial phase to determine which set of rules to use for the registration, and then the main phase to collect and label the rest of the registration data.

*So What About Natural vs Legal?*

The putative purpose in collecting the registrant's status is to restrict the disclosure of some portion of a Natural Person's registration data from being publicly accessible. In the terms described above, this means marking those data elements as more sensitive than "public." But what happens if...

1. ... the registrar doesn't collect the status? 2. ... the registrant refuses to give its status, i.e. responds "Unspecified?"As

As was stated at the beginning of this note, the current GNSO policy leaves the decision about collecting the status up to the registrar, so there's no guarantee the registrar will have this data. Even so, we might imagine a GNSO policy that says something to the effect of:

if you collect the registrant's status,

if the registrant's status is Natural, then apply rule set 1,

otherwise, if the registrant's status is Legal, the apply rule set 2,

otherwise, if the registrant's status is Unspecified, apply rule set 3

if you don't collect the registrant's status, apply rule set 4

So far, I haven't seen any discussion that goes into this level of detail, nor have I seen any discussion about taking into account other aspects of the registrant such as whether they require a higher level of protection.

*The GNSO is not the only source of rules*

The GNSO is the venue for setting the rules included in ICANN's contracts with the contracted parties. The registrars and registries are obligated to adhere to the terms of the contract. However, there are other bodies that can also set rules. Governments are the obvious examples, but there might be others.

Suppose a registrar is beholden to three authorities, ICANN, Government 1 (G1) and Government 2 (G2). Further, let's suppose that each body imposes its own rule.

The ICANN rule will be {C, O, N}, i.e. anything is ok.

Let's suppose G1's rule is {O, N}, i.e. registrars are permitted but not required to make it optional.

And let's suppose G2's rule is {C}, i.e. every registrar subject to this government's rules must collect this data.

The combined effect of all three rules is ø, i.e. the empty set, and there is no way a registrar can be in compliance with all of them.

On the other hand, if G2's rule were loosened to {C, O}, a registrar would be in compliance if its rule were O, i.e. making it optional for the registrant to supply this data.

*Conclusion*

The process of specifying the rules for collection and responses to requests has only just begun.

As we noted in prior comments and in our SSAC report, the focus on which data is to be marked "public" is just a small part of the overall puzzle. The extended discussions about Natural vs Legal are motivated, at least in part, by the attempt to make as much of the registration data publicly accessible because there is not yet any credible path toward an efficient and effective access system for non-public data.

Steve

------------------------------

*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Volker Greimann via Gnso-epdp-team <gnso-epdp-team@icann.org> *Sent:* Thursday, August 5, 2021 4:41 PM *To:* Steve Crocker <steve@shinkuro.com> *Cc:* EPDP <gnso-epdp-team@icann.org> *Subject:* Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified

Hi Steve,

I fail to see how this admittedly succinct summary of the existing options helps us move ahead the discussion as this basically only reflects the discussions we have over the past months.

At this point, we are likely either at option 7 or 8, which incidentally also describe the status quo.

The real issues start after making these basic definitions as there are complexities down the line following from the designations:

a) In case of C or O, does that lead to partial publication based on the designation? Does it lead to forwarding the designation to the registries? How would/should the registries treat those designations received? Can they rely on them? Will they rely on them without burdening registrars with further liability and indemnification requirements?

b) What happens down the road? Will agreeing to optional fields immediately lead to calls for them to be made into requirements by future work?

Best,

-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*

T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net

Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner

Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.

This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.

On Thu, Aug 5, 2021 at 5:26 PM Steve Crocker via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:

The attached note is a summary of the possible policies regarding Natural vs Legal vs Unspecified

_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.

All, As a reminder according to Bird & Bird memo, if personal information is disclosed by mistake due to the disclosure of a legal person's data that includes personal information, the risk in relation to fines is much less than if third parties personal information is disclosed by mistake based on the consent of the registrant. I stop now because I know this was discussed before, but this is just to reply to the possibility issue raised by Volker. Kind regards Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Steve Crocker via Gnso-epdp-team Sent: Monday, August 09, 2021 5:04 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified Volker, Is it your position that even if the registrant declares they are a business, i.e. a Legal Person, it is nonetheless necessary to restrict access to their contact data because it might contain personal information? If so, then it would seem there's no reason to ask the status and all registrant data should be treated as if it contains personal information. I'm not arguing whether this is a good or bad policy. I'm just asking if this is your interpretation. If so, it's a very clean, simple and easy to administer policy. I would also imagine it would engender an increase in efforts to obtain non-public data. Thanks, Steve On Mon, Aug 9, 2021 at 9:57 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: All, please bear in mind that this group is not tasked with achieving a result "we like to see" but with determining whether a change from the previous result is possible, and if so, necessary. So far, no necessity has been demonstrated and even with regard to the possibility the issue of legal risk due to personal information being contained in legal entity data still remains. As such, the default stands. Sincerely, -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net/> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Mon, Aug 9, 2021 at 1:50 PM Hadia Abdelsalam Mokhtar EL miniawi via Gnso-epdp-team <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> wrote: Thanks Steve for this work and this brief. In relation to the collection rules and just to note, ultimately we would have liked to see rule number one {C} applied. Bearing in mind that rule number one does not necessary need to say "Legal" or " Natural" it can also say " unspecified". However, we do recognize that no consensus in this regard is possible. Therefore our compromised position is rule number 4 {C, O} and honestly speaking I do not understand why we cannot agree to this. The difference between 4 {C,O} and 7 {C,O,N} is that 7 allows the registrar to not offer the registrant the ability to specify. GDPR as we all know makes this distinction and therefore it is only fair to give the data subject the ability to specify if it wishes and please note here that we should not conflate what is being offered by the registrar or collected from the registrant with what is going to be available through the public RDDS. What is going to be available through the public RDDS and the rules associated with any type of disclosure, are governed by a different set of rules which we could discuss and possibly agree to. As for option 8, my understanding is that this option refers to a deadlock position, which is an uncommon position, however it is not 7. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>] On Behalf Of Steve Crocker via Gnso-epdp-team Sent: Monday, August 09, 2021 12:06 AM To: EPDP Subject: Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified On Fri, Aug 6, 2021 at 10:05 AM Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>> wrote: I also appreciate the nice logical summary of options, Steve. A slightly revised version of my memo is attached. The content is exactly the same, but I have included a table showing which the three possible registrar rules are consistent with each of the eight possible GNSO rules. I have also introduced "ø" as the notation for the empty set instead of "{}." This is purely a change in notation, not in meaning. Like Volker, however, I believe that you are overlooking the fact that we have debated these options for months and have arrived firmly at option 7 (there is no distinction between 7 and 8, by the way). In 7, each registrar is permitted to have whichever rule it chooses. In 8, no rule is acceptable. 8 is a logical possibility but, quite obviously, it leads to an impossible situation. If such a policy were ever adopted, everyone would most likely ignore it. In that event, yes, 7 and 8 would have similar effects, i.e. impose no constraint. However, when we take into account the effect of multiple policies, the combined effects of multiple rules might indeed be 8. Detecting that in advance is important. See more on this below. In the meantime, the current state of agreement is 7, i.e. the GNSO will not impose any constraint on whether a registrar always collects the registrant's status, never collects the registrant's status, or makes it optional for the registrant to state its status. Only 7 is possible, because that was the agreed outcome of phase 1 while we explored other options in Phase 2. In Phase 2 we discovered we cannot attain sufficient agreement to move off of that equilibrium. Some EPDP members will recall that I personally indicated a willingness to move toward something like #6. This did not fly. Neither the Contracted Parties nor my own SG would accept it, and the GAC, ALAC and two CSG constituencies still wanted something more like 1 or 2. "Something like #6," eh? Well, 6 is: 6 = {O, N}, a registrar must either make it optional or not collect it but may not require it Meanwhile, 1 = C, i.e. every registrar collects this value 2 = O, i.e. every registrar is required to make this optional I wonder if they might have wanted 4 = {C, O}, a registrar must either collect it or make it optional I'll come back to this later in this note, but first let's look at two other parts of this puzzle. First, there are logically four possible values regarding the status. * "Natural," indicating the registrant has declared itself to be a natural person, i.e. an individual * "Legal," indicating the registrant has declared itself to be a legal person, i.e. a business * "Unspecified," indicating the registrant has affirmatively refused to declare as either a Natural or Legal person * "Blank," indicating the question has not been asked. Is there a distinction between the third and fourth status, and does it matter? In some cases it could well matter. In cases where it doesn't matter, there's no harm in allowing for both possibilities and then treating them the same. Second, we come to the really big question: How will this piece of information be used? I think we all expect this may play a role in what data is returned when there is a request for registration data, but this hasn't been fleshed out. In very approximate terms, the general thinking is that data about Legal persons will be publicly available and data about Natural persons will not be. But this is only the beginning of the conversation, not the end. It is helpful to think in terms of two distinct processes. One is the process of collecting the data during the time of registration. The other is the process of responding to requests for information about the registration. Let's begin with the second process. The Request Process Requests for registration data will come from many different parties. Some will come from the general public, and the requester will not be required to identify itself nor adhere to any rules governing use or protection of the data. Others will come from identified, authenticated and authorized requesters who have agreed to abide by a set of rules governing the use and protection of the data they receive. Requesters in the latter category are not all the same. The data they receive will likely depend on who they are and how they will be using the data. Examples of different subgroups of requesters are network operators, individual researchers, law enforcement, and IP attorneys, and within each of these subgroups there will likely be different kinds of requests. For example, we know from interviewing the members of the Public Safety Working Group they can identify five different kinds of requests, one of which is a request available to anyone and four others that request more data and come with a specific set of rules governing use and protection. At least one kind of request will come with legal paperwork, e.g. a warrant or subpoena, but other kinds of requests will not. And they aren't the only subgroup that might have different kinds of requests. What distinguishes these various kinds of requests? In the work we've been doing, it appears reasonable to express requests in terms of two concepts. One is some way of specifying which data elements are being requested. The other is to specify the level of sensitivity, a term we've been using to include whether data is marked "public" or "private." Are there more than just two levels? Well, yes, it seems so. In listening to the extended policy discussions, we have heard that if a requester is only authorized to see data elements marked "public" and the actual data element existings but is not publicly available, the response will be "redacted." However, we have also heard there are some data elements that are more sensitive, and requests from someone not authorized to see them will not be told anything about the data element. This suggests there are at least three levels of sensitivity. As a working hypothesis, we use four levels. If this turns out to be too many, it's easy to reduce the number. To recap, we think of a request as specifying the set of data elements requested and the authorized sensitivity level. The response will not include any data elements outside of the requested set nor any data elements more sensitive than the authorized sensitivity level. Of course, all of this is in addition to the identification of the requester, the statement of purpose, a pointer to the requester's credential, and agreement regarding use and protection of the requested data. Specifying the requested data elements is not a small matter. The data dictionary has around 100 distinct data elements. Each contact is a dozen or data elements, with the name, organization, phone number, fax number, email, street address, city, province or state, postal code and country treated separately. Added to these are the data elements for the DNS records, for the payment data, for the IP address used at the time of registration, the dates of registration and expiration, register locks, etc. To make it more manageable, each data element is grouped into one of several categories. A request then specifies which of these categories are requested. The Registration Process With the above description of the request process, we can now fill in a few details of the registration process. In broad terms, the registration process consists of collecting data from the registrant and assigning a sensitivity level to each of the collected data elements. (And, of course, reserving the domain name and getting it delegated if the registrant wants to put the domain name into service.) To accomplish this process, the registrar has a set of rules governing which data elements are required, optional or not to be collected, and what sensitivity level to assign to each collected data element. Once this process is complete, the registrar then stores the data elements and is then in a position to process requests in accordance with the agreed upon terms in a request. A further and all important addition to this short description is the registrar might have one set of rules for registrants that are Natural Persons, a different set of rules for registrants that are Legal Persons, and perhaps even a different set of rules for registrants of Unspecified status. Moreover, the status of the registrant might not be the only factor that determines which set of rules the registrant will use to complete the registration. For example, some registrars may treat registrants that need a higher level of protection differently from ordinary registrants. Celebrities and public figures are examples of Natural Persons who may need extra protection. Registrations associated with an impending business deal, e.g. product announcements, tentative mergers, etc. are examples of registrations by Legal Persons that may need extra protection. Taking the above into account, the registration process can be thought of as having an initial phase to determine which set of rules to use for the registration, and then the main phase to collect and label the rest of the registration data. So What About Natural vs Legal? The putative purpose in collecting the registrant's status is to restrict the disclosure of some portion of a Natural Person's registration data from being publicly accessible. In the terms described above, this means marking those data elements as more sensitive than "public." But what happens if... 1. ... the registrar doesn't collect the status? 2. ... the registrant refuses to give its status, i.e. responds "Unspecified?"As As was stated at the beginning of this note, the current GNSO policy leaves the decision about collecting the status up to the registrar, so there's no guarantee the registrar will have this data. Even so, we might imagine a GNSO policy that says something to the effect of: if you collect the registrant's status, if the registrant's status is Natural, then apply rule set 1, otherwise, if the registrant's status is Legal, the apply rule set 2, otherwise, if the registrant's status is Unspecified, apply rule set 3 if you don't collect the registrant's status, apply rule set 4 So far, I haven't seen any discussion that goes into this level of detail, nor have I seen any discussion about taking into account other aspects of the registrant such as whether they require a higher level of protection. The GNSO is not the only source of rules The GNSO is the venue for setting the rules included in ICANN's contracts with the contracted parties. The registrars and registries are obligated to adhere to the terms of the contract. However, there are other bodies that can also set rules. Governments are the obvious examples, but there might be others. Suppose a registrar is beholden to three authorities, ICANN, Government 1 (G1) and Government 2 (G2). Further, let's suppose that each body imposes its own rule. The ICANN rule will be {C, O, N}, i.e. anything is ok. Let's suppose G1's rule is {O, N}, i.e. registrars are permitted but not required to make it optional. And let's suppose G2's rule is {C}, i.e. every registrar subject to this government's rules must collect this data. The combined effect of all three rules is ø, i.e. the empty set, and there is no way a registrar can be in compliance with all of them. On the other hand, if G2's rule were loosened to {C, O}, a registrar would be in compliance if its rule were O, i.e. making it optional for the registrant to supply this data. Conclusion The process of specifying the rules for collection and responses to requests has only just begun. As we noted in prior comments and in our SSAC report, the focus on which data is to be marked "public" is just a small part of the overall puzzle. The extended discussions about Natural vs Legal are motivated, at least in part, by the attempt to make as much of the registration data publicly accessible because there is not yet any credible path toward an efficient and effective access system for non-public data. Steve ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Volker Greimann via Gnso-epdp-team <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Sent: Thursday, August 5, 2021 4:41 PM To: Steve Crocker <steve@shinkuro.com<mailto:steve@shinkuro.com>> Cc: EPDP <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified Hi Steve, I fail to see how this admittedly succinct summary of the existing options helps us move ahead the discussion as this basically only reflects the discussions we have over the past months. At this point, we are likely either at option 7 or 8, which incidentally also describe the status quo. The real issues start after making these basic definitions as there are complexities down the line following from the designations: a) In case of C or O, does that lead to partial publication based on the designation? Does it lead to forwarding the designation to the registries? How would/should the registries treat those designations received? Can they rely on them? Will they rely on them without burdening registrars with further liability and indemnification requirements? b) What happens down the road? Will agreeing to optional fields immediately lead to calls for them to be made into requirements by future work? Best, -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net/> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Thu, Aug 5, 2021 at 5:26 PM Steve Crocker via Gnso-epdp-team <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> wrote: The attached note is a summary of the possible policies regarding Natural vs Legal vs Unspecified _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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, to your first question, it really depends on a number of factors, but the default would be not to publish in any automated process as the data may contain personal information. In certain circumstances and depending on their own legal risk assessment this default may be changed by each registrar entity or even by each portal a registrar operates. This does not preclude: - a different default for certain registrant classifications - disclosure based on manual review of the data But yes, in all our previous discussions, our position has been that all data should be treated as personal data unless we have sufficient reason to believe and a sufficient degree of certainty that it does not contain personal information. In my envisioned SSAD, each registrar would be able to make their own risk assessment for the various data sets it processes and mark it for manual review or automated disclosure for the time a request comes in. Most corporate portals will for example have a higher risk tolerance and certainty level on the quality of their data than most wholesale portals would have (with retail portal operators being somewhere in between those two). I referenced this issue years ago at public forums at ICANN and during WG meetings: "Registrant type is a red herring as it does not answer the question that is actually relevant: Does the data set contain personal information, or does it not?" Best, -- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Mon, Aug 9, 2021 at 5:04 PM Steve Crocker <steve@shinkuro.com> wrote:

Volker,

Is it your position that even if the registrant declares they are a business, i.e. a Legal Person, it is nonetheless necessary to restrict access to their contact data because it might contain personal information?

If so, then it would seem there's no reason to ask the status and all registrant data should be treated as if it contains personal information.

I'm not arguing whether this is a good or bad policy. I'm just asking if this is your interpretation. If so, it's a very clean, simple and easy to administer policy. I would also imagine it would engender an increase in efforts to obtain non-public data.

Thanks,

Steve

On Mon, Aug 9, 2021 at 9:57 AM Volker Greimann <vgreimann@key-systems.net> wrote:

...

All, please bear in mind that this group is not tasked with achieving a result "we like to see" but with determining whether a change from the previous result is possible, and if so, necessary. So far, no necessity has been demonstrated and even with regard to the possibility the issue of legal risk due to personal information being contained in legal entity data still remains. As such, the default stands.

Sincerely,

-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*

T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net

Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner

Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.

This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.

On Mon, Aug 9, 2021 at 1:50 PM Hadia Abdelsalam Mokhtar EL miniawi via Gnso-epdp-team <gnso-epdp-team@icann.org> wrote:

...

Thanks Steve for this work and this brief.

In relation to the collection rules and just to note, ultimately we would have liked to see rule number one {C} applied. Bearing in mind that rule number one does not necessary need to say "Legal" or " Natural" it can also say " unspecified". However, we do recognize that no consensus in this regard is possible. Therefore our compromised position is rule number 4 {C, O} and honestly speaking I do not understand why we cannot agree to this. The difference between 4 {C,O} and 7 {C,O,N} is that 7 allows the registrar to not offer the registrant the ability to specify. GDPR as we all know makes this distinction and therefore it is only fair to give the data subject the ability to specify if it wishes and please note here that we should not conflate what is being offered by the registrar or collected from the registrant with what is going to be available through the public RDDS.

What is going to be available through the public RDDS and the rules associated with any type of disclosure, are governed by a different set of rules which we could discuss and possibly agree to.

As for option 8, my understanding is that this option refers to a deadlock position, which is an uncommon position, however it is not 7.

Best

Hadia

*From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] *On Behalf Of *Steve Crocker via Gnso-epdp-team *Sent:* Monday, August 09, 2021 12:06 AM *To:* EPDP *Subject:* Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified

On Fri, Aug 6, 2021 at 10:05 AM Mueller, Milton L <milton@gatech.edu> wrote:

I also appreciate the nice logical summary of options, Steve.

A slightly revised version of my memo is attached. The content is exactly the same, but I have included a table showing which the three possible registrar rules are consistent with each of the eight possible GNSO rules. I have also introduced "ø" as the notation for the empty set instead of "{}." This is purely a change in notation, not in meaning.

Like Volker, however, I believe that you are overlooking the fact that we have debated these options for months and have arrived firmly at option 7 (there is no distinction between 7 and 8, by the way).

In 7, each registrar is permitted to have whichever rule it chooses. In 8, no rule is acceptable. 8 is a logical possibility but, quite obviously, it leads to an impossible situation. If such a policy were ever adopted, everyone would most likely ignore it. In that event, yes, 7 and 8 would have similar effects, i.e. impose no constraint. However, when we take into account the effect of multiple policies, the combined effects of multiple rules might indeed be 8. Detecting that in advance is important. See more on this below.

In the meantime, the current state of agreement is 7, i.e. the GNSO will not impose any constraint on whether a registrar always collects the registrant's status, never collects the registrant's status, or makes it optional for the registrant to state its status.

Only 7 is possible, because that was the agreed outcome of phase 1 while we explored other options in Phase 2. In Phase 2 we discovered we cannot attain sufficient agreement to move off of that equilibrium.

Some EPDP members will recall that I personally indicated a willingness to move toward something like #6. This did not fly. Neither the Contracted Parties nor my own SG would accept it, and the GAC, ALAC and two CSG constituencies still wanted something more like 1 or 2.

"Something like #6," eh? Well, 6 is:

6 = {O, N}, a registrar must either make it optional or not collect it but may not require it

Meanwhile,

1 = C, i.e. every registrar collects this value

2 = O, i.e. every registrar is required to make this optional

I wonder if they might have wanted

4 = {C, O}, a registrar must either collect it or make it optional

I'll come back to this later in this note, but first let's look at two other parts of this puzzle.

First, there are logically *four* possible values regarding the status.

- "Natural," indicating the registrant has declared itself to be a natural person, i.e. an individual - "Legal," indicating the registrant has declared itself to be a legal person, i.e. a business - "Unspecified," indicating the registrant has affirmatively refused to declare as either a Natural or Legal person - "Blank," indicating the question has not been asked.

Is there a distinction between the third and fourth status, and does it matter? In some cases it could well matter. In cases where it doesn't matter, there's no harm in allowing for both possibilities and then treating them the same.

Second, we come to the really big question: How will this piece of information be used? I think we all expect this may play a role in what data is returned when there is a request for registration data, but this hasn't been fleshed out.

In very approximate terms, the general thinking is that data about Legal persons will be publicly available and data about Natural persons will not be. But this is only the beginning of the conversation, not the end.

It is helpful to think in terms of two distinct processes. One is the process of collecting the data during the time of registration. The other is the process of responding to requests for information about the registration. Let's begin with the second process.

*The Request Process*

Requests for registration data will come from many different parties. Some will come from the general public, and the requester will not be required to identify itself nor adhere to any rules governing use or protection of the data. Others will come from identified, authenticated and authorized requesters who have agreed to abide by a set of rules governing the use and protection of the data they receive.

Requesters in the latter category are not all the same. The data they receive will likely depend on who they are and how they will be using the data. Examples of different subgroups of requesters are network operators, individual researchers, law enforcement, and IP attorneys, and within each of these subgroups there will likely be different kinds of requests. For example, we know from interviewing the members of the Public Safety Working Group they can identify five different kinds of requests, one of which is a request available to anyone and four others that request more data and come with a specific set of rules governing use and protection. At least one kind of request will come with legal paperwork, e.g. a warrant or subpoena, but other kinds of requests will not. And they aren't the only subgroup that might have different kinds of requests.

What distinguishes these various kinds of requests? In the work we've been doing, it appears reasonable to express requests in terms of two concepts. One is some way of specifying which data elements are being requested. The other is to specify the level of sensitivity, a term we've been using to include whether data is marked "public" or "private." Are there more than just two levels? Well, yes, it seems so. In listening to the extended policy discussions, we have heard that if a requester is only authorized to see data elements marked "public" and the actual data element existings but is not publicly available, the response will be "redacted." However, we have also heard there are some data elements that are more sensitive, and requests from someone not authorized to see them will not be told anything about the data element. This suggests there are at least three levels of sensitivity. As a working hypothesis, we use four levels. If this turns out to be too many, it's easy to reduce the number.

To recap, we think of a request as specifying the set of data elements requested and the authorized sensitivity level. The response will not include any data elements outside of the requested set nor any data elements more sensitive than the authorized sensitivity level.

Of course, all of this is in addition to the identification of the requester, the statement of purpose, a pointer to the requester's credential, and agreement regarding use and protection of the requested data.

Specifying the requested data elements is not a small matter. The data dictionary has around 100 distinct data elements. Each contact is a dozen or data elements, with the name, organization, phone number, fax number, email, street address, city, province or state, postal code and country treated separately. Added to these are the data elements for the DNS records, for the payment data, for the IP address used at the time of registration, the dates of registration and expiration, register locks, etc.

To make it more manageable, each data element is grouped into one of several categories. A request then specifies which of these categories are requested.

*The Registration Process*

With the above description of the request process, we can now fill in a few details of the registration process.

In broad terms, the registration process consists of collecting data from the registrant and assigning a sensitivity level to each of the collected data elements. (And, of course, reserving the domain name and getting it delegated if the registrant wants to put the domain name into service.)

To accomplish this process, the registrar has a set of rules governing which data elements are required, optional or not to be collected, and what sensitivity level to assign to each collected data element.

Once this process is complete, the registrar then stores the data elements and is then in a position to process requests in accordance with the agreed upon terms in a request.

A further and all important addition to this short description is the registrar might have one set of rules for registrants that are Natural Persons, a different set of rules for registrants that are Legal Persons, and perhaps even a different set of rules for registrants of Unspecified status. Moreover, the status of the registrant might not be the only factor that determines which set of rules the registrant will use to complete the registration. For example, some registrars may treat registrants that need a higher level of protection differently from ordinary registrants. Celebrities and public figures are examples of Natural Persons who may need extra protection. Registrations associated with an impending business deal, e.g. product announcements, tentative mergers, etc. are examples of registrations by Legal Persons that may need extra protection.

Taking the above into account, the registration process can be thought of as having an initial phase to determine which set of rules to use for the registration, and then the main phase to collect and label the rest of the registration data.

*So What About Natural vs Legal?*

The putative purpose in collecting the registrant's status is to restrict the disclosure of some portion of a Natural Person's registration data from being publicly accessible. In the terms described above, this means marking those data elements as more sensitive than "public." But what happens if...

1. ... the registrar doesn't collect the status? 2. ... the registrant refuses to give its status, i.e. responds "Unspecified?"As

As was stated at the beginning of this note, the current GNSO policy leaves the decision about collecting the status up to the registrar, so there's no guarantee the registrar will have this data. Even so, we might imagine a GNSO policy that says something to the effect of:

if you collect the registrant's status,

if the registrant's status is Natural, then apply rule set 1,

otherwise, if the registrant's status is Legal, the apply rule set 2,

otherwise, if the registrant's status is Unspecified, apply rule set 3

if you don't collect the registrant's status, apply rule set 4

So far, I haven't seen any discussion that goes into this level of detail, nor have I seen any discussion about taking into account other aspects of the registrant such as whether they require a higher level of protection.

*The GNSO is not the only source of rules*

The GNSO is the venue for setting the rules included in ICANN's contracts with the contracted parties. The registrars and registries are obligated to adhere to the terms of the contract. However, there are other bodies that can also set rules. Governments are the obvious examples, but there might be others.

Suppose a registrar is beholden to three authorities, ICANN, Government 1 (G1) and Government 2 (G2). Further, let's suppose that each body imposes its own rule.

The ICANN rule will be {C, O, N}, i.e. anything is ok.

Let's suppose G1's rule is {O, N}, i.e. registrars are permitted but not required to make it optional.

And let's suppose G2's rule is {C}, i.e. every registrar subject to this government's rules must collect this data.

The combined effect of all three rules is ø, i.e. the empty set, and there is no way a registrar can be in compliance with all of them.

On the other hand, if G2's rule were loosened to {C, O}, a registrar would be in compliance if its rule were O, i.e. making it optional for the registrant to supply this data.

*Conclusion*

The process of specifying the rules for collection and responses to requests has only just begun.

As we noted in prior comments and in our SSAC report, the focus on which data is to be marked "public" is just a small part of the overall puzzle. The extended discussions about Natural vs Legal are motivated, at least in part, by the attempt to make as much of the registration data publicly accessible because there is not yet any credible path toward an efficient and effective access system for non-public data.

Steve

------------------------------

*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Volker Greimann via Gnso-epdp-team <gnso-epdp-team@icann.org> *Sent:* Thursday, August 5, 2021 4:41 PM *To:* Steve Crocker <steve@shinkuro.com> *Cc:* EPDP <gnso-epdp-team@icann.org> *Subject:* Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified

Hi Steve,

I fail to see how this admittedly succinct summary of the existing options helps us move ahead the discussion as this basically only reflects the discussions we have over the past months.

At this point, we are likely either at option 7 or 8, which incidentally also describe the status quo.

The real issues start after making these basic definitions as there are complexities down the line following from the designations:

a) In case of C or O, does that lead to partial publication based on the designation? Does it lead to forwarding the designation to the registries? How would/should the registries treat those designations received? Can they rely on them? Will they rely on them without burdening registrars with further liability and indemnification requirements?

b) What happens down the road? Will agreeing to optional fields immediately lead to calls for them to be made into requirements by future work?

Best,

-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*

T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net

Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner

Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.

This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.

On Thu, Aug 5, 2021 at 5:26 PM Steve Crocker via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:

The attached note is a summary of the possible policies regarding Natural vs Legal vs Unspecified

_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.