[discuss] governments and rule of law (was: Possible approaches to solving...)

John Curran 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:

> John,
> 
> 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
     - etc.

  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.

FYI,
/John

Disclaimer:  My views alone.





More information about the discuss mailing list