<div dir="ltr"><div>All,</div><div>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. <br></div><div><br></div><div>Sincerely,<br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span lang="EN-US">-- <br>Volker A. Greimann<br>General Counsel and Policy Manager<br><b>KEY-SYSTEMS GMBH</b><br><br>T: +49 6894 9396901<br>M: +49 6894 9396851<br>F: +49 6894 9396851<br>W: </span><a href="http://www.key-systems.net/" style="color:rgb(17,85,204)" target="_blank"><span lang="EN-US">www.key-systems.net</span></a><span lang="EN-US"><br><br>Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835<br>CEO: Oliver Fries and Robert Birkner<br><br>Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.<br><br></span><span style="font-family:Roboto,sans-serif;font-size:14px;white-space:pre-wrap;background-color:rgb(248,249,250)">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.</span></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 9, 2021 at 1:50 PM Hadia Abdelsalam Mokhtar EL miniawi via Gnso-epdp-team <<a href="mailto:gnso-epdp-team@icann.org">gnso-epdp-team@icann.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_781500731030694227WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Thanks Steve for this work and this brief.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">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.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Best<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Hadia<u></u><u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10pt;font-family:"Tahoma","sans-serif""> Gnso-epdp-team [mailto:<a href="mailto:gnso-epdp-team-bounces@icann.org" target="_blank">gnso-epdp-team-bounces@icann.org</a>]
<b>On Behalf Of </b>Steve Crocker via Gnso-epdp-team<br>
<b>Sent:</b> Monday, August 09, 2021 12:06 AM<br>
<b>To:</b> EPDP<br>
<b>Subject:</b> Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue"><u></u> <u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, Aug 6, 2021 at 10:05 AM Mueller, Milton L <<a href="mailto:milton@gatech.edu" target="_blank">milton@gatech.edu</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor rgb(204,204,204) currentcolor currentcolor;border-style:none solid none none;border-width:medium 1pt medium medium;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black">I also appreciate the nice logical summary of options, Steve.<u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue">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.<u></u><u></u></span></p>
</div>
<blockquote style="border-color:currentcolor rgb(204,204,204) currentcolor currentcolor;border-style:none solid none none;border-width:medium 1pt medium medium;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black">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).<u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue">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.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue">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.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue"><u></u> <u></u></span></p>
</div>
<blockquote style="border-color:currentcolor rgb(204,204,204) currentcolor currentcolor;border-style:none solid none none;border-width:medium 1pt medium medium;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black">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. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black">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.<u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue">"Something like #6," eh?  Well, 6 is:<u></u><u></u></span></p>
</div>
</div>
</div>
<blockquote style="margin-left:30pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:rgb(34,34,34)">6 = {O, N}, a registrar must either make it optional or not collect it but may not require it</span><span style="font-family:"Arial","sans-serif";color:blue"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue"><u></u> <u></u></span></p>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">Meanwhile,
</span></span><u></u><u></u></p>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black">1 =
</span></span><span style="font-size:7.5pt;font-family:"Calibri","sans-serif";color:black">C, i.e. every registrar collects this value</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black">2 =
</span></span><span style="font-size:7.5pt;font-family:"Calibri","sans-serif";color:black">O, i.e. every registrar is required to make this optional</span><u></u><u></u></p>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue">I wonder if they might have wanted<u></u><u></u></span></p>
</div>
</div>
</div>
</div>
<blockquote style="margin-left:30pt;margin-right:0in">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black">4 = </span><span style="font-size:7.5pt;font-family:"Calibri","sans-serif";color:black">{C, O}, a re</span><span style="font-size:7.5pt;font-family:"Calibri","sans-serif";color:rgb(34,34,34)">gistrar
 must either collect it or make it optional</span><span style="font-family:"Arial","sans-serif""><u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue"><u></u> <u></u></span></p>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">I'll come back to this later in this note, but first let's look at two other parts of this puzzle.</span></span><u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">First, there are logically
<u>four</u> possible values regarding the status.</span></span><u></u><u></u></p>
</div>
<blockquote style="margin-left:30pt;margin-right:0in">
<ul type="disc">
<li class="MsoNormal">
<span class="gmail-m_781500731030694227gmaildefault"><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:blue">"Natural," indicating the registrant has declared itself to be a natural person, i.e. an individual</span></span><u></u><u></u></li><li class="MsoNormal">
<span class="gmail-m_781500731030694227gmaildefault"><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:blue">"Legal," indicating the registrant has declared itself to be a legal person, i.e. a business</span></span><u></u><u></u></li><li class="MsoNormal">
<span class="gmail-m_781500731030694227gmaildefault"><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:blue">"Unspecified," indicating the registrant has affirmatively refused to declare as either a Natural or Legal person</span></span><u></u><u></u></li><li class="MsoNormal">
<span style="font-size:7.5pt;color:blue">"Blank," indicating the question has not been asked.</span><u></u><u></u></li></ul>
</blockquote>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.</span></span><u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><u><span style="font-family:"Arial","sans-serif";color:blue">The Request Process</span></u><span style="font-family:"Arial","sans-serif";color:blue"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue">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.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue">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 </span><span style="font-family:"Open Sans";color:blue" lang="EN">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.</span><span style="font-family:"Arial","sans-serif""><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif""><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Open Sans";color:blue" lang="EN">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.</span><span style="font-family:"Arial","sans-serif""><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif""><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Open Sans";color:blue" lang="EN">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.</span><span style="font-family:"Arial","sans-serif""><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif""><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Open Sans";color:blue" lang="EN">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.</span><span style="font-family:"Arial","sans-serif""><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif""><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Open Sans";color:blue" lang="EN">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</span><span style="font-family:"Open Sans";color:blue"> 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.</span><span style="font-family:"Arial","sans-serif""><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif""><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Open Sans";color:blue">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.</span><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><u><span style="font-family:"Arial","sans-serif";color:blue">The Registration Process</span></u></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">With the above description of the request process, we can now fill in a few details of the registration process.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.)</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><u><span style="font-family:"Arial","sans-serif";color:blue">So What About Natural vs Legal?</span></u></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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...</span></span><u></u><u></u></p>
</div>
<div>
<ol type="1" start="1">
<li class="MsoNormal">
<span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">... the registrar doesn't collect the status?</span></span><u></u><u></u></li><li class="MsoNormal">
<span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">... the registrant refuses to give its status, i.e. responds "Unspecified?"As </span></span><u></u><u></u></li></ol>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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:</span></span><u></u><u></u></p>
</div>
<blockquote style="margin-left:30pt;margin-right:0in">
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black">i</span><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">f you collect the registrant's status,</span></span><u></u><u></u></p>
</div>
</blockquote>
<blockquote style="margin-left:30pt;margin-right:0in">
<blockquote style="margin-left:30pt;margin-right:0in">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue">if the registrant's status is Natural, then apply rule set 1,<u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<blockquote style="margin-left:30pt;margin-right:0in">
<blockquote style="margin-left:30pt;margin-right:0in">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue">otherwise, if the registrant's status is Legal, the apply rule set 2,<u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<blockquote style="margin-left:30pt;margin-right:0in">
<blockquote style="margin-left:30pt;margin-right:0in">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue">otherwise, if the registrant's status is Unspecified, apply rule set 3<u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<blockquote style="margin-left:30pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue">if you don't collect the registrant's status, apply rule set 4<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue"><u></u> <u></u></span></p>
</div>
</div>
</blockquote>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.</span></span><u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u><span style="font-family:"Arial","sans-serif";color:blue">T<span class="gmail-m_781500731030694227gmaildefault">he GNSO is not the only source of rules</span></span></u><span style="font-family:"Arial","sans-serif";color:blue"><br>
<br>
<span class="gmail-m_781500731030694227gmaildefault">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.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">The ICANN rule will be {C, O, N}, i.e. anything is ok.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">Let's suppose G1's rule is {O, N}, i.e. registrars are permitted but not required to make it optional.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">And let's suppose G2's rule is {C}, i.e. every registrar subject to this government's rules must collect this data.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><u><span style="font-family:"Arial","sans-serif";color:blue">Conclusion</span></u></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">The process of specifying the rules for collection and responses to requests has only just begun.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">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.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span class="gmail-m_781500731030694227gmaildefault"><span style="font-family:"Arial","sans-serif";color:blue">Steve</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<blockquote style="border-color:currentcolor rgb(204,204,204) currentcolor currentcolor;border-style:none solid none none;border-width:medium 1pt medium medium;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<div class="MsoNormal" style="text-align:center" align="center">
<hr width="98%" size="2" align="center">
</div>
<div id="gmail-m_781500731030694227m_-4652745848208076716m_4978248474219254699m_-8585976474272899389m_4529742624009494684m_-1134610641933611711m_-3628728347641253549gmail-m_6495641438144883566divRplyFwdMsg">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:black">From:</span></b><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:black"> Gnso-epdp-team <<a href="mailto:gnso-epdp-team-bounces@icann.org" target="_blank">gnso-epdp-team-bounces@icann.org</a>>
 on behalf of Volker Greimann via Gnso-epdp-team <<a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a>><br>
<b>Sent:</b> Thursday, August 5, 2021 4:41 PM<br>
<b>To:</b> Steve Crocker <<a href="mailto:steve@shinkuro.com" target="_blank">steve@shinkuro.com</a>><br>
<b>Cc:</b> EPDP <<a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a>><br>
<b>Subject:</b> Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified</span>
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Hi Steve,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<p class="MsoNormal">At this point, we are likely either at option 7 or 8, which incidentally also describe the status quo.
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The real issues start after making these basic definitions as there are complexities down the line following from the designations:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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?
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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?
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Best,<u></u><u></u></p>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">-- <br>
Volker A. Greimann<br>
General Counsel and Policy Manager<br>
<b>KEY-SYSTEMS GMBH</b><br>
<br>
T: +49 6894 9396901<br>
M: +49 6894 9396851<br>
F: +49 6894 9396851<br>
W: <a href="http://www.key-systems.net/" target="_blank"><span style="color:rgb(17,85,204)">www.key-systems.net</span></a><br>
<br>
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835<br>
CEO: Oliver Fries and Robert Birkner<br>
<br>
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.<br>
<br>
<span style="font-size:10.5pt;font-family:"Arial","sans-serif";background:rgb(248,249,250) none repeat scroll 0% 0%">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.</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Aug 5, 2021 at 5:26 PM Steve Crocker via Gnso-epdp-team <<a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor rgb(204,204,204) currentcolor currentcolor;border-style:none solid none none;border-width:medium 1pt medium medium;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:blue">The attached note is a summary of the possible policies regarding Natural vs Legal vs Unspecified<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Gnso-epdp-team mailing list<br>
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a><br>
_______________________________________________<br>
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 (<a href="https://www.icann.org/privacy/policy" target="_blank">https://www.icann.org/privacy/policy</a>)
 and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" target="_blank">https://www.icann.org/privacy/tos</a>). 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.<u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>

_______________________________________________<br>
Gnso-epdp-team mailing list<br>
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a><br>
_______________________________________________<br>
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 (<a href="https://www.icann.org/privacy/policy" rel="noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). 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.</blockquote></div>