[Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified
Steve Crocker
steve at shinkuro.com
Sun Aug 8 22:05:55 UTC 2021
On Fri, Aug 6, 2021 at 10:05 AM Mueller, Milton L <milton at 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 at icann.org> on behalf of
> Volker Greimann via Gnso-epdp-team <gnso-epdp-team at icann.org>
> *Sent:* Thursday, August 5, 2021 4:41 PM
> *To:* Steve Crocker <steve at shinkuro.com>
> *Cc:* EPDP <gnso-epdp-team at 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 at 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 at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-team/attachments/20210808/4934d652/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Notes on Natural vs Legal vs Unspecified 2021-08-08.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 21160 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-epdp-team/attachments/20210808/4934d652/NotesonNaturalvsLegalvsUnspecified2021-08-08-0001.docx>
More information about the Gnso-epdp-team
mailing list