[CPWG] Fwd: [Gnso-epdp-team] Consensus calls, SSAC - Bundle 3

Sat Feb 16 00:39:41 UTC 2019

For those of you who are not subscribed to the EPDP mailing list, here
are some Interesting points made by the SSAC.

-------- Forwarded Message --------
Subject: 	[Gnso-epdp-team] Consensus calls, SSAC - Bundle 3
Date: 	Fri, 15 Feb 2019 23:41:45 +0000
From: 	Ben Butler <bbutler at godaddy.com>
To: 	Kurt Pritz <kurt at kjpritz.com>
CC: 	gnso-epdp-team at icann.org <gnso-epdp-team at icann.org>

Hi Kurt,

As requested, and after deliberating with SSAC members, here are the
consensus call positions from SSAC for Bundle 3/3B.  I have grouped the
recommendations based on our position.  We have provided comments on a
few for inclusion/consideration in the report to GNSO Council.  SSAC
will likely provide additional comments next week as well based on the
extended deadline referred to in your last correspondence.

*_Supported Recommendations:_*

* *

*Recommendation #5*(old #4) - Data elements to be collected by
Registrars – *SSAC concurs with the recommendation with the
understanding that Registrars must support / process Tech Contact data
if it is provided by the RNH* 

*_ _*

*_Explanation:_*

There is some confusion whether Recommendation 5 requires registrars to
offer the Tech Contact fields to their Registered Name Holders or not. 
This is because Recommendation 5's table marks the Tech Contact fields
as mandatory to collect, but Recommendation 5 also says "if the
Registrar provides this option". 

SSAC understands that there are legal requirements for collecting and
transferring the Tech Contact data which will need to be discussed in
the implementation phase. 

SSAC believes that the ePDP Team's discussion was: Registrars MUST offer
the Registered Name Holder the opportunity to provide Technical Contact
data.  Technical Contact data should be optional for the Registered Name
Holder to provide. If Technical Contact data is provided to the
registrar, the data must be provisioned to the registry.   If that is
what Recommendation 5 delivers, SSAC can endorse Recommendation 5. If
Recommendation 5 does not deliver that, SSAC cannot endorse
Recommendation 5.

*Recommendation #7*(old #5)– Data elements to be transferred from
Registrars to Registries – *SSAC concurs with the recommendation as written*

*Recommendation #9*(old #7) – Contractual Compliance  – *SSAC concurs
with the recommendation as written*

*Recommendation #10*(old #8) – Data Redaction  – *SSAC concurs with the
recommendation as written*

*Recommendation #12*(old #9) – Organization field – *SSAC concurs with
the recommendation as written*

*Recommendation #13*(old #10) – Email communication  – *SSAC concurs
with the recommendation as written*

*Recommendation #14*  – Privacy/Proxy Registrations  – *SSAC concurs
with the recommendation as written*

*Recommendation #19*(old #13) - Controller Agreement  – *SSAC concurs
with the recommendation as written*

*Recommendation #20*(old #14) - Responsible Parties  – *SSAC concurs
with the recommendation as written*

*Recommendation #27*(old #22) – Impact on other policies  – *SSAC
concurs with the recommendation as written*

*Recommendation #29*– Admin Contact Transition  – *SSAC concurs with the
recommendation as written*

*Recommendation #2*–Additional Purposes  – *SSAC concurs with the
recommendation as written*

*_Dissentions:_*

* *

*Recommendation #16*–  Geographic Basis – *SSAC cannot support the
recommendation as written (See Below)*

*Recommendation #17*–  Natural vs. legal – *SSAC cannot support the
recommendation as written (See Below)*

*_Reasoning:_*

Recommendations 16 and 17 have a negative effect on security and
legitimate contactability.  Recommendation 16 allows significant
over-redaction of

data not required by GDPR (or other laws currently in place), and
enables a race to the bottom, allowing venue-shopping without respect to
the actual

location of registrars or registrants.  Recommendation 17 enables
ongoing redaction of information about legal persons that do not have
the rights of

natural persons.  These outcomes are not balanced, and are neither
necessary nor desirable.  We believe that better, more balanced
solutions are both

legally and technically possible and should be discussed. 

It is the SSAC's position that:

  * Recommendation 16: Registrars and Registry Operators must be
    obligated to differentiate between registrants on a geographic --
    i.e. legal jurisdiction basis, after a suitable implementation period.
  * Recommendation 17: Registrars and Registry Operators must be
    obligated to differentiate between registrations of legal and
    natural persons, after a suitable implementation period.

Regarding Recommendation 17:

  * The EPDP Team will discuss the Legal vs. Natural issue in Phase 2,
    and SSAC looks forward to participating in that discussion.

Should Recommendation 17 be adopted by Council, SSAC notes that the
study criteria in section #2 are unbalanced and must be updated.  They

assume that the main decision-making criteria are the costs and risks to
contracted parties.  The list is missing consideration of how policy affects

third parties with legitimate interests, and how the law imposes new
responsibilities(and therefore costs) on the Contracted Parties .  As SAC104

notes: "The GDPR imposes certain new obligations and therefore risk and
costs on registrars and registry operators. It has also imposed risk and

costs on the parties who rely upon domain registration data for the wide
array of legitimate purposes.  The GDPR calls for balancing and the

accommodation of legitimate security interests, explicitly called out in
Recital 49. ICANN policy should also provide balanced solutions. In some

cases the Initial [and now the Final] Report asks what costs will be
borne by the Contracted Parties, but does not also evaluate the costs on
all other

parties, or the cost of not putting a balanced solution into place. Cost
or risk to registrars or registry operators alone is not a persuasive
argument

against balanced solutions."

*_Supporting Documentation:_*

SAC104: https://www.icann.org/en/system/files/files/sac-104-en.pdf

SAC101v2: https://www.icann.org/en/system/files/files/sac-101-v2-en.pdf

As SSAC stated in SAC104:

"The GDPR states clearly that it 'does not cover processing of personal
data which concerns legal persons.'  We recommend that registrars be
required to

deploy mechanisms that ensure a reliable declaration or determination of
natural or legal person status for new registrations going forward, and to

eventually obtain those declarations or determinations for existing
registrations and their registrants.

"Contact data associated with natural persons should be published in RDS
where such is not prohibited by local law. In SAC101, SSAC stated: 'The new

policy [The Temporary Specification] allows RDDS operators complete
freedom to choose when to redact domain contact data from publication,
whether or

not a domain contact is protected by GDPR or by any other local privacy
law. The result has been blanket redactions, hiding more data than is
legally

called for. A more balanced and justified approach is needed.. access
should not be less timely, more restricted, and less public than law
requires....

We also note that as of this writing, most ccTLD operators in the
European Union continue to publish some (and sometimes all) contact data
fields for

domains registered by legal persons. Some continue to publish some
personal data for natural person registrants in public WHOIS output.'

"SAC101 also highlights RIPE-NCC's solution, which allows for the
publication of data about natural persons contained in the contact data for

legal persons. This process provides mechanisms that RIPE-NCC says were
specifically designed to comply with GDPR.  The RIPE-NCC solution seems to

be balanced in that it provides contactability and does not overapply
the law. SSAC believes that RIPE's model deserves a full examination and
neutral

legal evaluation.... We also recommend the following:

1. Introduction of a policy requiring registrants to make a legal or
natural person declaration.

2. Obtaining declaration would be mandatory for registrars to implement
within a reasonable time.

3. A declaration would only be required during registration events, i.e.
when a new domain is registered, or when an existing domain is renewed or

transferred (by gaining registrar). This would eventually "fill in"
status data about existing/historical registrations.

4. Registrar may make declaration on behalf of registrant if the
registrar has reasonable knowledge of registrant's status and the
registrant has not

made a declaration of its own. This would be applicable to registrars
with specific business models, for instance when they only process
registrations

on behalf of organizations where it is clear that the registrant falls
into a particular category based on their relationship with the registrar.

5. Registrant may change its declaration at any time.

6. The absence of a declaration results in assumption that the
registrant is a natural person; i.e. a default redaction of data.

7. Inaccurate declarations will be subject to a revised WHOIS inaccuracy
complaint process."

*_Cluster #3B_*

* *

*Recommendation #11*City Field  – *SSAC concurs with the recommendation
as written*

*Recommendation #15*(new #11) - Data retention  – *SSAC concurs with the
recommendation as written*

*Recommendation #18*(old #12)  – Reasonable access  – *SSAC concurs with
the recommendation as written*

*Recommendation #28*- Implementation Transition Period  – *SSAC concurs
with the recommendation as written*

As always, please reach out if we can provide any additional context or
clarification.

-Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cpwg/attachments/20190216/09d82399/attachment-0001.html>
-------------- next part --------------
_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team at icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdp-team