I'm not opposed to a public comment by SSR2, on what icann asked for, which was feedback on the implementation of the six they accepted. in our case SSR-related feedback. i assume this should be of the form: Recommendation 1: Our feedback on the proposed implementation of this recommenadtion is as follows @@ Recommendation 17: Our feedback on the proposed implementation of this recommenadtion is as follows @@ ... For example, I think it would be fair to say that the implementation of Recommendation 1 is not meaningful without the other specific data recommendations, and that it is problematic for icann to punt all the specific data collection to a "community input" and "budgets-permitting" process, which will have the same misaligned incentives that have allowed SSR threats to persist and escalate. also, the implementation report refers to these in the 'dependencies' section: It is also important to take into account and leverage existing work relevant to data collection for the organization, including the following: } Open Data Program. The program goals are to a) increase transparency and improved accessibility and availability of data and b) strengthen ICANN orgs procedures, processes, and standards for higher data usability and reuse. This program includes an existing platform for publication of data. gTLD Marketplace Health Indicators. This set of statistics is published on a regular basis to track the evolution of the domain name marketplace in areas such as robustness, stability, and trust. A community advisory panel is working with ICANN org to develop and refine these indicators. Identifier Technology Health Indicators. This project involves metrics to measure the health of the system of unique identifiers the organization helps to coordinate. These include metrics about the level of abuse in domain names, supported by the Domain Abuse Activity Reporting (DAAR) project. but I spent quite some time digging into each of these trying to find any data that would help mitigate or prevent SSR threats, and I could not find any. It seems likely that any sort of data collection not in the interest of a given party to collect and share will not be collected and shared without threat of, or actual, government regulation. (Or someone please suggest another example of an industry where such data was volunteered, and we can cite that in the report.) But these comments are more relevant to the recommendations that have not been accepted yet.. so i'm not sure this is appropriate. Recommendation 17: Well, this recommendation looks blown off. ICANN states they have already implemented the part of it they can implement (via the 'publicly available WHOIS', so there is reference to a unicorn in this implementation ;) ) ; the rest of it us up to other parties who do not have an incentive to share the data. ICANN says they will do nothing else, and maybe others will if they find some incentive to do so through some PDP. ICANN also notes that providing the reseller field is optional in response to queries, but does not explain why. My assumption is that CCT-RT does not think it should be, but ICANN should verify that. ICANN also states that "CCT-RT's proposed success measure for this recommendation is that it is possible for anyone to readily determine the reseller associated with any gTLD registration." -- so I think we can offer to efficiently perform CCT-RT2's future assessment of icann's implementation of this recommendation as "Not Effective." but also, icann should say, out of their hands and in the contracted parties' and EU governments' hands. and here we have another classic example of misaligned incentives. Recommendation 21: ICANN asks Org to "investigate potential negative impacts on enforcement of compliance" of actually publishing which TLD is receiving complaints and details of such complaints including resolutions. I'll note that this Recommendation was Priority High, meaning implementation within 18 months, and we're 13 months in, so we'll know whether icann managed to implement this entirely incentive-misaligned recommendation before our final report. But getting consensus on some SSR2 response would require that at least a few people actually read the report, and think about the implications for SSR.. the prospect of a critical mass of us doing that within a week given our level of participation on our own report indeed seems low. m2c k On Wed, Oct 02, 2019 at 06:48:16AM +0300, Matogoro Jabera wrote:
Dear Russ,
I support the phrasing as it was given in our comment. If budget is the main constrain then the board could approve the recommendation BUT the implementation could remain pending up to next budget when fund will be made available.
We could also give a paragraph analysing the approved, pending and rejected recommendations. It could happen that the approved recommendations favour a certain group at ICANN ecosystem. So it is better also to give a small highlights on these.
Regards, Matogoro
On Wed, 2 Oct 2019, 01:11 Russ Housley, <housley@vigilsec.com> wrote:
Denise and Matogoro:
I have some concern with this one sentence:
The correct response to budgetary concerns (based on past Board action) would have been for the Board to approve the recommendations and note that implementation would begin in the new fiscal year.
I agree with the direction that this is going, but I think it would be better for the Board action to include the implementation of the recommendation in the proposed budget for the following fiscal year, and then have the community review process of the budget determine whether or not the necessary funds are allocated.
Russ
_______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org https://mm.icann.org/mailman/listinfo/ssr2-review
_______________________________________________ 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.