<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff">Volker,</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff">Thanks for taking the time to read my memo and ask questions. See responses below.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff">Steve</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 5, 2021 at 4:42 PM Volker Greimann <<a href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.net</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 dir="ltr"><div>Hi Steve,</div><div><br></div><div>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.</div><div></div>At this point, we are likely either at option 7 or 8, which incidentally also describe the status quo.</div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)">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.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)">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.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)">This set of possibilities exists within a larger context. Here are four aspects of the larger context.</div><div class="gmail_default" style=""><ol style="color:rgb(0,0,255);font-family:arial,sans-serif;font-size:small"><li>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.)<br><br></li><li>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:</li><ul><li>V0 = Accept whatever the registrant provides</li><li>V1 = Check the registrant's input for syntactic conformance</li><li>V2 = Check the registrant's input for plausible correctness</li><li>V3 = Apply very strong checks to ensure the registrant's input is verifiably correct<br><br><div class="gmail_quote"><div><div class="gmail_default"><font color="#0000ff" face="arial, sans-serif">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.)</font></div></div></div><br></li></ul><li>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.<br><br>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.<br><br>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.<br><br></li><li>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.</li></ol></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The real issues start after making these basic definitions as there are complexities down the line following from the designations:</div><div>a) In case of C or O, does that lead to partial publication based on the designation?</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)">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.)</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Does it lead to forwarding the designation to the registries? How would/should the registries treat those designations received?</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)">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.</div></div><div> <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 dir="ltr"><div> Can they rely on them? Will they rely on them without burdening registrars with further liability and indemnification requirements?</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)">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.</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> <br></div><div>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?</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)">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.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)">Hope this helps.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)">Steve</div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> <br></div><div><br></div><div>Best,<br></div><div><div dir="ltr"><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><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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:<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 dir="ltr"><div style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,255)">The attached note is a summary of the possible policies regarding Natural vs Legal vs Unspecified</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>
</blockquote></div></div>