for SSR2 team member review and edit
Per the SSR2 team’s conversation, below is a first draft of comments on the proposed implementation of the CCT Review (https://www.icann.org/public-comments/cct-rt-implementation-plan-2019-09-11-...). Red-line comments are welcome by Oct. 8 and Mr. Matogoro and I will work on an updated draft. Regards, Denise Denise Michel denisemichel@fb.com<mailto:denisemichel@fb.com> **DRAFT ** SSR2 Team comments on the ICANN draft implementation plan for CCT review recommendations. Thank you for the opportunity to provide comments on the Board’s draft implementation plan for the Competition, Consumer Trust and Consumer Choice Review, 2019. The SSR2 applauds and thanks the members of the CCT Review who worked tirelessly over a three year period to produce their final report. The report clearly documents issues relating to competition, consumer trust and consumer choice, and presents focused recommendations aimed at driving ICANN to make key improvements. Several recommendations made by the CCT team are relevant to the work of the SSR2 review. We will, however, take this opportunity to comment on the role of community reviews and how the ICANN Board and staff approach reveiws. The SSR2 takes this opportunity, again, to express its concern and disappointment that the Board chose to accept only six out of the 35 recommendations contained in the CCT report. Prior to the IANA transition, the Board accepted all recommendations of community review teams (ATRT, WHOIS/RDS, SSR) and these reviews were intended to be the key tool for transparency and accountability in the post-transition ICANN. With the first community review post-transition, the CCT Review, however, the Board took a surprisingly different approach to community reviews and has not accepted a majority of the CCT Review’s recommendations. Aside from the substantive implications, the SSR2 Review team is concerned about the implications this has for the Board’s treatment of the RDS and SSR2 Review reports, as well as for the integrity of the community review process overall. Only these six accepted CCT recommendations are mentioned in the draft implementation plan. The Board resolution (2019.03.01.03) directs staff to plan for the implementation of ‘accepted recommendations’. It remains unclear what is planned for the 17 recommendations marked as ‘pending’ The only hint comes at resolution 2019.03.01.04, where the Board ‘directs the ICANN President and CEO, or his designee(s) to provide the Board relevant information, as requested in the Scorecard, and advise if additional time is needed within six months from this Board action.’ (emphasis added). The implementation plan was published on 23 August 2019, and in relation to the pending recommendation notes (p22) that ICANN Org is to advise if additional time is needed by 1 September (a week after publication of the implementation plan). The draft gives no indication as to whether such requests are anticipated. It gives no timeframe for implementation, nor does it provide an update on the status of the ICANN org investigations or activity of ‘pending’ resolutions. These are important and should be immediately, publicly provided. Following the SSR2 team’s meetings with Board members and CCT Review team members in Kobe, and subsequent written updates, the SSR2 team was told that the Board’s response to the CCT Review recommendations and its rationale for failing to adopt the majority of the recommendations was: * Impact on the ICANN budget * A need for community developed definitions of key terms (such as ‘DNS Abuse’) * A need for further research by ICANN org to understand issues, such as the value of publicly available data * Certain recommendations were properly directed to stakeholders other than the ICANN Board, including the community or staff. In the SSR2 Team’s opinion, the above reasons are should not be used to delay Board acceptance or staff action. The CCT Review team kept the community and the Board updated throughout the period of its review. However, the Board provided no feedback to the CCT on possible issues (budgetary or otherwise) at the time when the CCT was developing the recommendations. 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. The CCT Report references community-developed definitions to ‘DNS Abuse’ and ‘DNS Security Abuse’[1], which have been in place for a decade. There is no excuse to delay implementation of CCT recommendations pending further definitional work on DNS Abuse. If further analysis were really required, the correct response would have been for the Board to use the six month period between receipt of the report (March 2019) and publication of its response (June 2019), to conduct due diligence and investigate ways to implement the recommendations, or raise questions and concerns with the relevant parties. Where recommendations are directed at other groups, the proper response (based on past Board action) would have been for the Board to adopt the recommendations, note that a PDP (or other appropriate action) is required, and send the recommendation to the responsible entity with a request for expedited consideration/action. None of the above steps were taken. The Board’s response to the CCT Review came as a shock to the CCT Review team and to the community, and it was especially demoralizing for members of other community reviews, such as the SSR2. We are now deeply concerned that our years of volunteer effort on behalf of the ICANN community will be similarly wasted and disrespected. Whether by intent or by poor communication, the Board response to the CCT Review raises concerns among the SSR2 membership that the ‘pending’ status was adopted as a means for ICANN to avoid implementing the majority of CCT recommendations. Aside from the demoralizing effect on SSR2 members, the Board’s attitude to specific review recommendations should raise red flags among the ICANN community. The specific reviews are the most tangible mechanism to provide accountability for the ICANN Board and Staff to the ICANN multistakeholder community. The reviews evolved from the Affirmation of Commitments between the United States and ICANN and were inserted into the ICANN Bylaws as part of the IANA transition. In the opinion of the SSR2 Review Team, the expectation would be that, absent compelling justification, the Board would accept all the recommendations in specific reviews. Of greater concern is the message the Board’s actions send to external audiences, including those who are sceptical of the value of multistakeholder processes following the IANA transition. The specific reviews are failing as an accountability mechanism, leaving the Board and ICANN Org free from external or internal constraints. ________________________________ [1] The CCT final report adopts the following, community-developed definitions for DNS Abuse and DNS Security Abuse: “DNS Abuse” is a term used by the Review Team that refers to “intentionally deceptive, conniving, or unsolicited activities that actively make use of the DNS and/or the procedures used to register domain names” (see p. 3 of the “New gTLD Program Safeguards Against DNS Abuse: Revised Report”). “DNS Security Abuse” in the context of this report refers to specific, technical forms of abusive behavior: malware distribution, phishing, pharming, botnet command-and-control, and spam in the DNS. For more on how abuse has been characterized by the ICANN Community, see the Registration Abuse Policies Working Group’s Final Report (29 May 2010). The glossary to the CCT report also reflects those definitions.
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
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
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.
Hi all, My comments below. Didn’t think I would say this but would have been easier if this had been a google doc. In general, I feel we have to be careful re our claims; we should focus on the team and the ssr2 review, not on the community as we cannot know everyone’s position and because they cannot comment on this text. All the best Laurin
On Oct 1, 2019, at 17:59, Denise Michel <denisemichel@fb.com> wrote:
Per the SSR2 team’s conversation, below is a first draft of comments on the proposed implementation of the CCT Review (https://www.icann.org/public-comments/cct-rt-implementation-plan-2019-09-11-...).
Red-line comments are welcome by Oct. 8 and Mr. Matogoro and I will work on an updated draft.
Regards, Denise
Denise Michel denisemichel@fb.com
**DRAFT ** SSR2 Team comments on the ICANN draft implementation plan for CCT review recommendations.
Thank you for the opportunity to provide comments on the Board’s draft implementation plan for the Competition, Consumer Trust and Consumer Choice Review, 2019.
The SSR2 applauds and thanks the members of the CCT Review who worked tirelessly over a three year period to produce their final report. The report clearly documents issues relating to competition, consumer trust and consumer choice, and presents focused recommendations aimed at driving ICANN to make key improvements. Several recommendations made by the CCT team are relevant to the work of the SSR2 review. We will, however, take this opportunity to comment on the role of community reviews and how the ICANN Board and staff approach reveiws.
The SSR2 takes this opportunity, again, to express its concern and disappointment that the Board chose to accept only six out of the 35 recommendations contained in the CCT report. Prior to the IANA transition, the Board accepted all recommendations of community review teams (ATRT, WHOIS/RDS, SSR) and these reviews were intended to be the key tool for transparency and accountability in the post-transition ICANN. With the first community review post-transition, the CCT Review, however, the Board took a surprisingly different approach to community reviews and has not accepted a majority of the CCT Review’s recommendations. Aside from the substantive implications, the SSR2 Review team is concerned about the implications this has for the Board’s treatment of the RDS and SSR2 Review reports, as well as for the integrity of the community review process overall.
Only these six accepted CCT recommendations are mentioned in the draft implementation plan. The Board resolution (2019.03.01.03) directs staff to plan for the implementation of ‘accepted recommendations’. It remains unclear what is planned for the 17 recommendations marked as ‘pending’ The only hint comes at resolution 2019.03.01.04, where the Board ‘directs the ICANN President and CEO, or his designee(s) to provide the Board relevant information, as requested in the Scorecard, and advise if additional time is needed within six months from this Board action.’ (emphasis added).
The implementation plan was published on 23 August 2019, and in relation to the pending recommendation notes (p22) that ICANN Org is to advise if additional time is needed by 1 September (a week after publication of the implementation plan). The draft gives no indication as to whether such requests are anticipated. It gives no timeframe for implementation, nor does it provide an update on the status of the ICANN org investigations or activity of ‘pending’ resolutions. These are important and should be immediately, publicly provided.
Following the SSR2 team’s meetings with Board members and CCT Review team members in Kobe, and subsequent written updates, the SSR2 team was told that the Board’s response to the CCT Review recommendations and its rationale for failing to adopt the majority of the recommendations was: • Impact on the ICANN budget • A need for community developed definitions of key terms (such as ‘DNS Abuse’) • A need for further research by ICANN org to understand issues, such as the value of publicly available data • Certain recommendations were properly directed to stakeholders other than the ICANN Board, including the community or staff.
In the SSR2 Team’s opinion, the above reasons are should not be used to delay Board acceptance or staff action. The CCT Review team kept the community and the Board updated throughout the period of its review. However, the Board provided no feedback to the CCT on possible issues (budgetary or otherwise) at the time when the CCT was developing the recommendations.
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.
Not sure the last sentence adds much; also there might be other “correct” options. (There is a whole paragraph below)
The CCT Report references community-developed definitions to ‘DNS Abuse’ and ‘DNS Security Abuse’[1], which have been in place for a decade. There is no reason to delay implementation of CCT recommendations pending further definitional work on DNS Abuse. If further analysis were really required, the correct response would have been for the Board to use the six month period between receipt of the report (March 2019) and publication of its response (June 2019), to conduct due diligence and investigate ways to implement the recommendations, or raise questions and concerns with the relevant parties.
Replace excuse with reason
Where recommendations are directed at other groups, the proper response (based on past Board action) would have been for the Board to adopt the recommendations, note that a PDP (or other appropriate action) is required, and send the recommendation to the responsible entity with a request for expedited consideration/action.
I would again not use proper but note what has been done in the past, again there might be other appropriate approaches one could take.
The board chose to not follow established procedure with the CCT review.
The Board’s response to the CCT Review came as a shock to the CCT Review team and to the community, and it was especially demoralizing for members of other community reviews, such as the SSR2. We are now deeply concerned that our years of volunteer effort on behalf of the ICANN community will be similarly wasted and disrespected.
Replace community with SSR2, we should not speak for anyone beyond the team that can approve this.
Whether by intent or by poor communication, the Board response to the CCT Review raises concerns among the SSR2 membership that the ‘pending’ status was adopted as a means for ICANN to avoid implementing the majority of CCT recommendations. Aside from the demoralizing effect on SSR2 members, the Board’s attitude to specific review recommendations should raise red flags among the ICANN community.
I would rephrase this a bit more neutrally, stating that we fear that this will mean that these recs won’t be implemented, rather than going with “avoid implementing” Last sentence I am unsure about again, as this makes claims about people who cannot see and approve of this text.
The specific reviews are the most tangible mechanism to provide accountability for the ICANN Board and Staff to the ICANN multistakeholder community. The reviews evolved from the Affirmation of Commitments between the United States and ICANN and were inserted into the ICANN Bylaws as part of the IANA transition. In the opinion of the SSR2 Review Team, the expectation would be that, absent compelling justification, the Board would accept all the recommendations in specific reviews.
This could go higher up. I would phrase the first sentence more along the fact that they were designed and meant to be accountability mechanisms. Would start last sentence with “ Based on this fact and historical precedent, the ssr2 team expected that, absent […]
Of greater concern is the message the Board’s actions send to external audiences, including those who are sceptical of the value of multistakeholder processes following the IANA transition. The specific reviews are failing as an accountability mechanism, leaving the Board and ICANN Org free from external or internal constraints.
Would start with, “we are also concerned that the board’s actions might signal to external audiences (including those sceptical of post-transition multistakeholder processes) that the specific reviews are failing as an accountability mechanism.
[1] The CCT final report adopts the following, community-developed definitions for DNS Abuse and DNS Security Abuse: “DNS Abuse” is a term used by the Review Team that refers to “intentionally deceptive, conniving, or unsolicited activities that actively make use of the DNS and/or the procedures used to register domain names” (see p. 3 of the “New gTLD Program Safeguards Against DNS Abuse: Revised Report”). “DNS Security Abuse” in the context of this report refers to specific, technical forms of abusive behavior: malware distribution, phishing, pharming, botnet command-and-control, and spam in the DNS. For more on how abuse has been characterized by the ICANN Community, see the Registration Abuse Policies Working Group’s Final Report (29 May 2010). The glossary to the CCT report also reflects those definitions. _______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fssr2-review&data=02%7C01%7Claurin.weissinger%40yale.edu%7Cc3e7b3d69d3543945e4f08d746bab5b8%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637055640047245479&sdata=XHk2nqKT2KAg5XxGf7lePbwAHOB0%2FKDs3z%2BsQSdFjwA%3D&reserved=0
_______________________________________________ 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://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Claurin.weissinger%40yale.edu%7Cc3e7b3d69d3543945e4f08d746bab5b8%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637055640047245479&sdata=s9PmH%2FFFqBW931Z3ZUXXIax%2FSfH%2BgE%2BTXTYz%2FoFF7Is%3D&reserved=0) and the website Terms of Service (https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Claurin.weissinger%40yale.edu%7Cc3e7b3d69d3543945e4f08d746bab5b8%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637055640047245479&sdata=8rqAXr7%2FOvddFXWWtzmTbxMPwA64nZ%2BIspraU%2BSF%2FCE%3D&reserved=0). 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.
http://www.domainpulse.com/2019/09/29/request-for-information-icann-contract... should be mentioned in the doc. e.g., is the RFI clear enough about what is needed.. (no i've not read yet..) k
participants (5)
-
Denise Michel -
k claffy -
Matogoro Jabera -
Russ Housley -
Weissinger, Laurin