[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