[Ssr2-review] Questions re: the Recommendations from the Abuse/Compliance sub-team

[Heather Flanagan]

Hello all

These questions relate specifically to the Recommendations section offered by the Abuse/Compliance sub-team, starting on page 31 of the Google doc. As mentioned in my note with questions re: the findings, I am happy to put these questions in the doc itself, but am uncertain who should be assigned to the comments to make sure they are addressed.

https://docs.google.com/document/d/10KOW2F6oqR3OdV7hfuWmnYo6gtE0d0wOZHOQzXmijx4/edit# <https://docs.google.com/document/d/10KOW2F6oqR3OdV7hfuWmnYo6gtE0d0wOZHOQzXmijx4/edit#>

—

1. Does this mean separate the registrar/registry compliance activities from all other ICANN activities, or separate them from each other?

 "Since ICANN derives most of its funding from registrars and registries, it should separate its registrar and registry compliance activities to ensure neutral and effective compliance with contracts.” (Page 32 of the Google doc)

—

2. I’m increasingly confused in how the team uses the word “Compliance”. Sometimes that seems to refer to an action, sometimes a department, sometimes an initiative. For example:

"The ICANN Board must empower the Compliance Office to react to complaints and require Compliance to initiate investigation and enforce against those aiding and abetting systemic abuse.”

Do you have any suggestions on how I might differentiate between the different uses of Compliance? It feels a lot like the differences between ICANN, ICANN Org, ICANN community…

—

3. I can parse this sentence right up to the “act now” component. The recommendation seems to suggest that ICANN should use the current definition while also support redefining it by using the definitions outlined in the Convention on Cybercrime. Can someone help clarify what’s expected here?

"Abuse Definitions & Reporting - ICANN Board and ICANN Org should overhaul ICANN’s approach to DNS abuse definitions, tracking and reporting, including implementing community review recommendations and other security-related actions, act now using the current “DNS abuse” definition and in parallel use international conventions to evolve the definition, create a single portal for all complaints, and make public reporting mandatory.” (Page 33 of the Google doc)

And

"Use the current DNS Abuse definition and take into account the processes and definitions outlined in the Convention on Cybercrime.[38]. Forego new efforts to have ICANN Org or the ICANN community re-define DNS Abuse and instead adopt the additional term and evolving external definition of “security threat”—a term used by the ICANN DAAR project, the GAC (in its Beijing Communique and for Spec 11), and operational security communities – to use in conjunction with ICANN DNS Abuse definition.” (Page 33 of the Google doc)


—

4. Is this level of specificity appropriate for the report, or should this be summarized into "ICANN should establish and maintain a single complaint portal for all complaints, that which automatically directs reports to relevant parties, including appropriate Registrars. All reports and their responses should be viewable to the public, and ICANN should include information regarding these reports in their annual report."

"The process would work as follows: 1) Complaint submitted, ticket number created, sent to registrar; 2) Registrar responds, ticket closed. Registrar does not, goes to registry; and 3) Registry responds, ticket closed. Registry does not respond, it goes to ICANN.  Reports to non-participating ccTLDs to be forwarded via email.

—

5. I am unclear about the use of “Contracted Parties” in this recommendation. Does this always refer to the parties that contract directly with ICANN, or does it also refer to any subcontracts formed by the direct contracted parties?

"Policies and agreements with Contracted Parties – adopt new ones that meaningfully impact mitigation of DNS abuse and security threats[14] , including changes to WHOIS, incentives for contracted parties for abuse mitigation, incorporate measures to mitigate “DNS abuse” and  “security threats” in agreements with contracted parties, estalish a performance metrics framework, and institutionalize training and certifications for contracted parties and key stakeholders.” (Page 35 of the Google doc)

—

6. Is there a particular date or date range that should be added here? Also, [16] does not point to anything applicable ([16] was used earlier in the examples for the findings - see "Verisign blog, Q2 2018 DDOS Trends Report: 52 Percent of Attacks Employed Multiple Attack Types”). Should there be a different reference used? Is a reference needed here at all?

"ICANN org must enforce norms within XXX[16] .” (Page 35 of the Google doc)

—

7. There are several items that look like they should be citation pointers (as in [16] above) that do not point to an appropriate reference. Is there a master list somewhere of what was intended in the Recommendation section, or should these citation tags be removed?

—

8. Is this level of specificity appropriate to the report, or should this be left as a business decision detail for ICANN?

“..., and provide a Registrar with a discount down to the current $0.18 per domain name for low abuse levels.” (Page 36 of the Google doc)

"This should include, as a priority, provisions that establish thresholds of abuse (3% of registration or 30 total whichever is the higher) at which compliance inquiries are automatically triggered, with a higher threshold (10% of all registrations) at which registrars and registries are presumed to be in default of their agreements.” (Page 37 of the Google doc)

—

9. The first set of recommendations refers to ICANN making improvements to SSR by updating contracts. In the third set of recommendations, it states that "ICANN’s legal authority to address compliance, security, and/or stability of the DNS, is based on the bylaws and in relation to compliance by Registrars the Service Level Agreements.”  Are these items in conflict in any way?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ssr2-review/attachments/20190927/9e9ac2ac/attachment.html>