[Ssr2-review] attempt at prioritization (and rationale) of recs required by bylaws

k claffy kc at caida.org
Sun Nov 3 15:14:30 UTC 2019



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



More information about the Ssr2-review mailing list