[discuss] governments and rule of law (was: Possible approaches to solving...)
jcurran at istaff.org
Thu Feb 27 00:27:41 UTC 2014
On Feb 26, 2014, at 3:03 PM, Alejandro Pisanty <apisanty at gmail.com> wrote:
> in an ideal world you'd do that iteration after iteration until the result is perfectly clear and actionable and the consensus is unequivocally established. But then, in that ideal world, that would be the case from the very beginning.
I was not asking about the ideal world, but those specific cases you referenced earlier where the
"bottom-up advice (wasn't always) clear and precise enough for the ICANN Board to just approve."
In order to save time, perhaps it would best to just accept such cases at face value, and move on
to consider its relevance of this discussion on the role of governments, GAC input, and Board
consideration of same.
The discussion on this topic has revealed quite a bit of "Board wisdom" regarding handling of issues
(e.g. usefulness of stimulating further discussion and new approached where the community has not
come up with something sufficiently clear, the Board's vision of a limited role in the course of normal
policy development efforts, desirability of the Board not serving as its own experts, use of expert
working groups when needed, etc.)
Perhaps it would be helpful for the Board to enshrine some of this wisdom into a more detailed process
and criteria than the current GNSO policy development process? Presently, the entire Board wisdom is
enshrined in a single line regarding whether "the Board determines that such policy is not in the best
interests of the ICANN community or ICANN."
There is a complete absence of any criteria (even representative) about what might constitute a policy
being "not in the best interests of the ICANN community or ICANN.", for example -
- Policy statement is insufficiently clear to allow for implementation
- Policy development did not follow the approved policy development process
- Policy would result in ICANN doing something contrary to prevailing law
- Policy was not clearly supported by the ICANN community
- Policy was strongly opposed by one significant segment of the ICANN community
and there is not documentation that those views have been fully considered.
- Policy could pose significant technical risk
Obviously having such a set of formal criteria may also be helpful in preparation of the staff report,
but the main benefit would be in documenting a shared understanding over some of the significant
types of issues that the Board will weigh in its determination.
Clearly, the Board will always retain the freedom to identify other concerns due to its weighty responsibility
to the mission of the organization, but setting clear expectations about the normal evaluation process and
criteria (to match what has been discussed on this list) would probably be helpful in dispensing with some
of the Board perception issues, and certainly help in anchoring accountability aspects of the organization.
Disclaimer: My views alone.
More information about the discuss