FINAL VERSION SUBMITTED (IF RATIFIED)
The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote.
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.
ALAC Statement submitted for inclusion in the Final Report of the Temporary Specification for gTLD Registration Data Phase 2 Expedited Policy Development Process (EPDP).
v05 – 27 July 2020
The ALAC entered into the EPDP making the following statement:
- The ALAC believes that the EPDP MUST succeed and will be working toward that end.
- We have a support structure that we are organizing to ensure that what we present here is understood by our community and has their input and support.
- The ALAC believes that individual registrants are users and we have regularly worked on their behalf (as in the PDP that we initiated to protect registrant rights when their domains expire), if registrant needs differ from those of the 4 billion Internet users who are not registrants, those latter needs take precedence. We believe that GDPR and this EPDP are such a situation.
- Although some Internet users consult WHOIS and will not be able to do so in some cases going forward, our main concern is access for those third parties who work to ensure that the Internet is a safe and secure place for users and that means that law enforcement, cybersecurity researchers, those combatting fraud in domain names, and others who help protect users from phishing, malware, spam, fraud, DDoS attacks and such can work with minimal reduction in access to WHOIS data. All within the constraints of GDPR of course
We have worked valiantly to support the EPDP process and work on behalf of the now almost 5 billion Internet users.
The target of Phase 2 of the EPDP was to develop what is now called the System for Standardized Access/Disclosure to Non-Public Registration Data (SSAD) as well as address a number of issues that were not completed during Phase 1 of the EPDP.
A vast amount of work has been done, but the ALAC believes that if and when the SSAD is deployed, the probability of its meeting the goals needed by the communities whose efforts we support will be low. Those communities need access to specific accurate, usable non-public data and they need it in a timely and predictable manner.
Key methodologies to achieving this include:
- Do not expand the reach of privacy legislation. Redact only data protected by such laws;
- Ensure that data is accurate, and contact information is usable – that is the only reason that the contact information is there;
- To the extent possible and legal, process queries in an automated fashion resulting in quick responses (close to instantaneous when possible).
The Final Report unfortunately does none of this with any certainty.
Specifically:
- Phase 1 allowed the redaction of information about legal persons (companies) as well as natural persons (people) and most registrars and registries are doing such full redaction. They are also redacting regardless of geographic location.
- Phase 2 was supposed to fully address the issue of legal vs natural, but although there was some discussion, the issue is being remanded to the GNSO Council for possible addressing at some future time.
- GDPR requires data to be accurate for the purposes in which it is processed. In the case of RDS data, that is to know who the registrant is and to facilitate contact. WHOIS Accuracy studies have demonstrated that when the information was publicly available, it was woefully inaccurate. Phase 2 was supposed to fully discuss the issue of accuracy in relation to the now redacted data. That has not been done. The PDP was instructed by the GNSO Council to not address this topic and the GNSO Council will consider addressing it in an as yet undefined manner.
- Contact with registrants is currently through methods (largely web forms) which studies have shown are not effective and with no feed-back to the sender on the extent to which the message may have gone to the registrant. Further discussion is remanded to the GNSO Council for possible addressing at some future time.
- There are a few use cases which the SSAD will automatically respond to. The intent was that as laws and jurisprudence and contractual issues advance, an “evolution” mechanism would allow more use-cases to be handled in an automated way. The recommended evolution mechanism is a GNSO Standing Committee (SC) which requires that new use cases be approved not only by the contracted parties (who may be liable to penalties if not done properly), but also by the GNSO Council. The SC is allowed to recommend both pure implementation (requiring GNSO Council approval to proceed to implementation) and Policy (which would require GNSO policy process such as a PDP before it could proceed). It is unclear whether new SSAD decision use-case recommendations would be treated as implementation, or if a new PDP (or equivalent) would have to be chartered to actually allow such automation (potentially adding years to allow new use-cases).
The ALAC, along with several other groups, accepted the current SSAD model despite strong reservations because we were assured that the evolution mechanism would allow change in a practical and timely manner. Such changes were not guaranteed due to legal and liability issues, but they were possible. Based on what is now known about the evolution mechanism, and the lack of clarity about how it will work and how its recommendation will be treated by the GNSO Council, the ALAC would certainly never have agreed to the current SSAD model.
Moreover, although a Standing Committee Recommendation by default requires a standard majority vote of the GNSO Council, it is possible that this could be changed to require a super-majority[1].
- The financial model is troublesome. At first glance, it may not be unreasonable for users of the SSAD to bear a significant part of the operational costs, but in setting prices to attempt to ensure that, it is possible that they may be set so high so as to discourage use. This would not only result in not meeting those financial objectives but effectively nullifying the entire effort. There must be flexibility in pricing to ensure that the SSAD is truly usable. To that end, it is currently unclear to what extent ICANN may need to subsidize the service.
All of these issues are due to either issues the EPDP was instructed not to address, or chose not to address, or left the recommendation wording sufficiently vague as to not provide any level of confidence in the outcomes.
All of these issues COULD be suitably addressed by the GNSO Council as it deliberates over this Final Report.
Accordingly, the ALAC is CONDITIONALLY supporting this report subject to the GNSO Council actions specified below.
If these outcomes cannot be met, the ALAC believes that this report would result in a multi-year-implementation resulting in a system which would effectively be a glorified, overly complex and very expensive ticketing system. As such, the Final Report, in its totality but excluding Recommendations #19-22, would not have our support[2].
GNSO Council outcomes required for the ALAC to support the EPDP Final Report:
- GNSO Council agrees that any Evolution Standing Committee recommendation on additional SSAD decision use-cases (that are in full accordance with the EPDP Policy Recommendation 9.3) will be treated as Implementation and not require further policy deliberations.
- Legal vs Natural, Accuracy, WHOIS Accuracy Reporting System and Anonymized contact email will be fully addressed with full participation in all aspects of discussions by the ICANN Advisory Committees that wish to participate. If these issues are deemed to be policy, they must be addressed by a group empowered to make policy recommendations, led by a qualified, non-conflicted chair. The GAC, ALAC and SSAC must be involved in setting the mandate or charter of such groups. The target for completion of all work should be no later than April 2021.
- The GNSO Council agrees that ratifying the Evolution Standing Committee recommendations will only require a GNSO Majority as currently called for in the GNSO Policy Manual.
- The GNSO Council acknowledges that deliberations during implementation setting of prices for the SSAD must involve the future potential users of the SSAD and not only look at cost recovery but the actual ability and willingness of SSAD users to pay the prices being set.
[1] A supermajority vote allows a single Stakeholder Group plus one other member of the House to veto any GNSO action.
[2] For avoidance of doubt, should the conditions not be met, the ALAC will still support Recommendations 19-22 but not the rest of the report.
DRAFT SUBMITTED FOR DISCUSSION
The first draft submitted will be placed here before the call for comments begins. The Draft should be preceded by the name of the person submitting the draft and the date/time. If, during the discussion, the draft is revised, the older version(S) should be left in place and the new version along with a header line identifying the drafter and date/time should be placed above the older version(s), separated by a Horizontal Rule (available + Insert More Content control).