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

Steve Crocker steve at shinkuro.com
Thu Aug 5 22:14:17 UTC 2021


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


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

> 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.


> Best,
> --
> Volker A. Greimann
> General Counsel and Policy Manager
> 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/20210805/b65db76b/attachment-0001.html>

More information about the Gnso-epdp-team mailing list