jennifer did remind us of this on 3 oct: ICANN Bylaws text regarding recommendations Section 4.6(a)(vii)(A) of the ICANN Bylaws<https://www.icann.org/resources/pages/governance/bylaws-en> states the following: (A) Each report of the review team shall describe the degree of consensus or agreement reached by the review team on each recommendation contained in such report. Any member of a review team not in favor of a recommendation of its review team (whether as a result of voting against a matter or objecting to the consensus position) may record a minority dissent to such recommendation, which shall be included in the report of the review team. The review team shall attempt to prioritize each of its recommendations and provide a rationale for such prioritization. it's interesting that it's tacked on to the end of the consensus transparency requirement, because i suspect we are likely to get consensus on the recommendations but not on their prioritization.. i share eric's concern that given our lack of resources to base any approach approach on trustworthy analysis of data on risks and harms to users, it will be subjective which could mislead the Board about what is most important by the time they read the report. i still suspect we should identify the risks we mean to mitigate/prevent with each recommendation, and leave it to the Board to sort these risks. when we send our draft report out for public comment, we could also explicitly solicit feedback on this issue, and even solicit pointers to sources of data/analysis on the risks we identify, to add to the report. k