Re: [council] NC conclusions on structure - draft version 5

[Thomas Roessler <roessler@does-not-exist.org>]

On 2002-04-11 12:19:26 +0200, Philip Sheppard wrote:

>Further to the second NC call and e-mail correspondence please 
>find the latest version of our draft conclusions in progress.

Thanks for that.  

(Note, BTW, that the "call to arms" in Alexander's and my previous 
message should not be read to be directed at the chair alone.... ;-)

>Recommendation 9 - policy making. ICANN policy advisory bodies 
>should formulate policy recommendations based on a bottom-up, 
>consensus process of the affected stakeholders.

>Recommendation 10 - impact. The policy recommendations from such 
>policy advisory bodies should be ordinarily binding on the ICANN 
>Board but with rejection possible subject to a 2/3 Board majority.

For what kind of policy-making?  I believe that we need to 
differentiate between consensus policies as defined, for instance, 
in the .com registry agreement, and other SO policy output, such as 
the dot-org task force's work product.

For your reference, let me quote the definition of a "consensus 
policy" in the agreement:

	1. "Consensus Policies" are those specifications or policies 
	established based on a consensus among Internet stakeholders 
	represented in the ICANN process, as demonstrated by (1) 
	action of the ICANN Board of Directors establishing the 
	specification or policy, (2) a recommendation, adopted by at 
	least a two-thirds vote of the council of the ICANN 
	Supporting Organization to which the matter is delegated, 
	that the specification or policy should be established, and 
	(3) a written report and supporting materials (which must 
	include all substantive submissions to the Supporting 
	Organization relating to the proposal) that (i) documents 
	the extent of agreement and disagreement among impacted 
	groups, (ii) documents the outreach process used to seek to 
	achieve adequate representation of the views of groups that 
	are likely to be impacted, and (iii) documents the nature 
	and intensity of reasoned support and opposition to the 
	proposed specification or policy.
 
(<http://www.icann.org/tlds/agreements/verisign/registry-agmt-com-25may01.htm>)

Note, in particular, that a 2/3 majority of the COUNCIL is a 
necessary for a consensus policy to exist.  (Also note that an 
independent review panel is necessary to make any consensus policy 
binding under the current contract language.)

I believe that any recommendation from the council should answer the 
following questions:

 - Should the contractual requirements for consensus policies be 
   modified?  If yes, how?  How do the council's recommendations 
   interact with the contracts?

 - How should the development of (1) consensus and (2) other policies 
   be coordinated with the board, and with ICANN high-level staff?

   The experiences with the dot-org task force may indicate that an 
   early involvement of active liaisons to board and staff may be 
   very reasonable.  In particular, there should be early warnings 
   when a task force is about to produce results inconsistent with 
   existing policy. 

   This may be covered by staff support, but I'd prefer if the 
   council would be more explicit about it.

 - What, precisely should the council's role be?  How is it going to 
   interact with the board and with staff?  How is it going to 
   interact with the GA?

   Options for council's role:

   - Council can oversee consensus development.
   - Council can perform consensus development itself
     (Risk: Work overload of active members)
   - Council can oversee consensus development in general, but 
     provide fast track for simple decisions.

   Options for relationship to board and staff:

   - More or less strict separation (status quo; not free of 
     problems).
   - Board selects (directly or indirectly) some portion of the 
     councils [Lynn proposal].
   - Add staff or board member as dedicated liaison; most likely 
     non-voting.
   - Have staff or board member as non-voting chair of council, but 
     continue election of members like what happens now.

   (I could imagine that a closer link between the board and the 
   council could help to streamline the council's work, and provide 
   an improved feed-back channel from ICANN's daily work.)

   Options for relationship to GA:

   - GA chairs may be made voting members of council
   - GA chairs may be made non-voting members of council
   - stick with the current situation

 - Relationship between funding and participation.  The council 
   should think and make a recommendation about how to deal with 
   problems like the NCDNHC's.

I suppose these are enough questions for the moment.  One other 
suggestion I'd like to make to the council is that it may lend more 
credibility to any recommendations made if they come together with a 
REALISTIC appraisal of the current process, which points out where 
the problems actually are.  (You may call me an optimist.)

-- 
Thomas Roessler                          http://log.does-not-exist.org/