[Gnso-epdp-team] Formal specification of collection and labelling rules for Natural and Legal registrants

Steve Crocker steve at shinkuro.com
Thu Apr 1 13:39:49 UTC 2021


As many of you know, I've been working with a small group to develop a
framework for precisely expressing both collection and labeling rules for
collectors and access rules for requesters.  Attached are two documents.
The Excel file has two visible tabs, one for registrants who are either
known to be natural persons or whose status is unknown.  The other is for
legal persons.  Both of these represent the ICANN perspective, i.e. the
rules that gTLD registries and ICANN accredited registrars are required to
adhere to.  A couple of points that may feel slightly different from what
you're used to:

   - The collection rule may be specific, e.g. every registrar must collect
   this data element, or every registrar must make collection of this data
   element optional, or the rule may allow different registrars to have
   different rules.  The words "Neutral" and "Either" in a cell that's colored
   brown indicate ICANN imposes no constraint on the registrar or registries.

   - The data dictionary is inclusive.  There may be data elements that are
   not of interest to ICANN or some registries or registrars.  That's not a
   problem.  In these cases the ICANN rule will generally indicate no

   - In addition to whether the data is or is not collected, a validation
   level and a sensitivity level is assigned.  The validation level ranges
   from V0 to V3.  V0 indicates no validation.  V3 indicates the registrar
   fully validates the accuracy.  This scale is essentially the same as what's
   specified in SSAC's SAC 058 report.  The sensitivity level is a slight
   generalization of public vs private.  S0 is public.  S1 is private.  If
   someone with access only to public data elements attempts to retrieve data
   elements at the S1 level, the response will be "redacted."  Levels S2 and
   S3 are more sensitive.

   - The attributes V3ok and DG indicate whether the registrant is allowed
   to override the validity and sensitivity labels.  V3ok indicates the
   registrant has the option to request a high level of validation.  DGok
   indicates the registrant has the option of "downgrading" the sensitivity
   level to public.

Not included in this package is the specification of the request side of
this system.  I'll leave that for another time.

Question for the group: Is the specification provided here an accurate
representation of the past decisions and current thinking of the EPDP?

The slides are a quick briefing on the system.  I'll be happy to add
further explanation either to the group or individually to anyone who's


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20210401/a0e66407/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SSAC EPDP WP 2021-03-30.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 417165 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20210401/a0e66407/SSACEPDPWP2021-03-30-0001.pptx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SSAC EPDP 2021-03-31.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 2636780 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20210401/a0e66407/SSACEPDP2021-03-31-0001.xlsx>

More information about the Gnso-epdp-team mailing list