[Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified

Fri Aug 6 12:14:48 UTC 2021

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 at 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 at 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 at 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 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/20210806/35dd6548/attachment-0001.html>