ICANN/DNSO
DNSO Mailling lists archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] policy-making options


On 2002-04-09 02:20:57 +0200, Alexander Svensson wrote:

>> - Interaction with the board: Through intermediate body (DNSO
>>   process via names council; may or may not have power to modify
>>   input from WG); directly (board committees).

>This is perhaps the most interesting question. Do intermediate 
>bodies refine the policies and work as a checks-and-balances 
>system -- or do they blur responsibilities, alter the bottom-up 
>nature of the process and create a superfluous layer inbetween? 
>(Both probably?)

The original design of the names council makes some sense to me - 
after all, why shouldn't those who participate in the policy-making 
process also manage it, collectively?  However, I don't believe that 
any council should go further than management, and the most basic 
checks - such as, does the report accurately reflect the outcome of 
discussions, or does it just represent the author's wishes?  

The DNSO's current approach bears the temptation to the council to 
duplicate discussions which have (or should have) happened on the 
task force level, already.

Now, the _really_ interesting part is actually how to apply this 
argument to the board...

>>  Additional options (orthogonal to that):
>>
>>  * Output may be considered binding/non-binding/almost-binding.
>
>If the output of the task force is considered binding for
>all bodies, there is no need for other bodies. 

What do you mean by "binding" at this point?  Unconditionally 
binding?  Binding if process is properly applied?  I was actually 
thinking about the latter.

>If it is considered non-binding, there is little need for the task 
>force. 

Task forces would degrade to a combined outreach and 
"option-finding" mechanism, with any actual decisions still 
happening at the board level.  The ALSC is a nice example for the 
pros and cons of this.  Quite frankly, I don't find this kind of 
mechanism too appealing.

>I think that an overall oversight is needed, and it's hard to 
>imagine any (public or private) corporation without some form of 
>intervention/review to make sure the policies are at least not 
>contradicting themselves, too costly and follow the procedures 
>properly. 

No objection on my side; see above. ;-)

>Operationalizing "almost binding" could mean to require some sort 
>of supermajority to turn down a policy developed in accordance 
>with the procedures.

I suppose we have to further split up the discussion of this for 
different kinds of policy which may emanate from the SOs:

 - Policy proper in the sense of (for instance) the registry 
   agreement, which contains specific process requirements for a 
   policy to be binding for a third party.  It should be noted that 
   ICANN is currently not able to come up with any binding policy in 
   this sense due to the lack of an independent review panel.  (Note 
   that Lynn's proposal would imply a renegotiation of this part of 
   the agreements.  That will be interesting to watch.)

 - Policy in a more general sense, such as with the dot-org 
   divestiture.  This is the area where the board has the largest 
   discretion, since the only question is when policy is considered 
   to bind ICANN (and its board).  What would most likely be needed 
   here is a well-defined mechanism how the board should handle such 
   output from SOs, and what such output should look like. (E.g.: 
   Should the TF draft a board resolution, or should they give a 
   general statement which is going to be translated into a board 
   resolution by the board or by staff?  Should they just outline the 
   contents of a board resolution in very general terms, or should 
   they make much more specific recommendations?  I believe that some 
   of the current confusion over the dot-org resolution is caused by 
   unclarity on this part of the process.)

>>  * Board may interact with TF while work is going on.  Similar to
>>    relationship between public and WG.

>The task forces/working groups need some way of communicating and 
>explaining their findings to the Board, I think -- probably during 
>the work, definitely when the final results are ready. It's not 
>only about misunderstandings (deliberate or not), but the Board 
>may also be interested in specific aspects which the TF/WG only 
>mentions briefly.

Once again, dot-org illustrates some of the things which may happen, 
when Louis Touton provided advice on agreements at a rather late 
point of the task force's work.  I suppose that input would have 
been much more helpful at an earlier stage of the task force's work. 
So we are most likely looking for several kinds of staff and board 
support:

 - editorial/organizational support for task forces
 - compliance checking
 - liaison to the board's thinking

I suppose if anyone has the time for it, the entire dot-org story 
may be an excellent research topic which could produce textbook 
examples for almost all aspects of ICANN process.

>>One thing which should be kept in mind while thinking about 
>>these options is that different circles of stakeholders may 
>>imply the need for different mechanisms.  What is appropriate 
>>for consensus-building in the PSO concerning their policy area 
>>may be entirely inappropriate for the DNSO (or its successor), 
>>or for a ccSO.  Also, cross-SO discussions may require a process 
>>different from discussions within individual SOs.

>Very much agreed, and I think /we/ should look for solutions which 
>are appropriate for (gTLD) domain name policy development and 
>cross-policy/ICANN overall issues. It's highly unlikely that the 
>appropriate solution for gTLD names is also ideal for WAVE and AVI 
>Codec numbering (should it ever become controversial).

Of course.  But don't you think that we should also look for a 
replacement for the board's highly transparent ;-) committees?

-- 
Thomas Roessler                          http://log.does-not-exist.org/
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html



<<< Chronological Index >>>    <<< Thread Index >>>