ICANN/DNSO
DNSO Mailling lists archives

[ga-full]


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

Re: [ga] DNSO Constituency Structure


On Sun, 25 Nov 2001 08:54:10 -0500, Chuck Gomes wrote:
http://www.dnso.org/clubpublic/ga/Arc08/msg03049.html

Hi Chuck

Thank you for you very relevant email.  I agree entirely.  Let me make a few
points first then respond to your comments.  It's long but reasonably
straightforward.

As far as the substantive argument is concerned, I feel the concept of
"consensus" may be designed, or perhaps misused, to thwart genuine reform.
That reform could, of course, work in favour or against any one's interests.
It could even be (more or less) neutral.

Let's hypothesise, for a moment, that somebody in the GA proposes a policy
such as an Individuals Constituency.  You know quite well, I am sure, how
hard it is to get such a proposition debated properly.  Let's say that it
was successful and then went to the Names Council.  They could amend it or
whatever.

Even if the NC supported the proposition, the need for consensus means it
needs to be supported by each of the seven DNSO constituencies.  Should that
occur, the proposition must then be ratified by the ASO and the PSO.  This
is no mean feat in itself.

Assuming all of that has been done, there is still no consensus without
"outreach".  Finally it must go before the ICANN Board who will naturally
refer it to the ICANN staff.  They in turn may seek a legal advice from
their attorneys.

Any changes along the way and the whole process needs to start over !!

It seems to me that there are several ways in which the system may be
improved.  Firstly, a proposal can come from the top i.e. the ICANN Board
can initiate a policy which is simultaneously referred to the ASO, DNSO and
PSO Councils.

A second alternative is to simplify the meaning of "consensus" i.e. change
it to a majority or two thirds vote.  I think Milton made this suggestion.
The Catch 22 here, of course, is that such a proposal requires "consensus"
(in the present sense) before it can be adopted.

The third alternative is to simplify the structure through which the
proposal needs to be processed.  That probably the toughest option.  But it
is what I am looking at here.

Clearly fewer than three SOs would improve the process.  As would fewer
constituencies.  Of course, the country codes are pushing for a new SO and
that works the other way i.e. it increases the number of supporting
organisations.  Even the GA itself is moving in that direction.

So I am starting at the top.  How many supporting organisations do you think
would be ideal?  I have suggested TWO only (hardware and software, or
physical and logical, or engineering and business) as it closely matches
with the underlying reality.

> But, whereas I do believe that structurally changes could definitely
> improve the consensus development process, I do not agree that the
> problems are primarily structural versus procedural.

True.  But see above.

<snip>
> In a global and hugely diverse environment like the Internet, consensus
> will always be hard to reach.

Yes, Chuck, but it shouldn't be impossible (cf the debates about the
"individuals" constituency, the ALSC and the ICANN Board numbers).

> Therefore, if there are not clearly defined policies and
> procedures with regard to what should be expected outcomes of the
> consensus development efforts, it seems highly unlikely that it will be
> successful.

Of course I agree that policies need to be clearly defined.  That is not
particularly easy when the underlying processes (like special purpose
mailing lists, voting procedures or Best Practices etc) need to be worked
out first.

> I personally believe that is why many people currently are trying to take
> shortcuts with regard to consensus development (e.g., task forces).  They
> are easier and take less effort and it's not too hard to convince some
> people that they are legitimate,

Very true.  Hence my recent email about Task Force legitimacy at:
http://www.dnso.org/clubpublic/ga/Arc08/msg03041.html

> but in reality they are a far cry from what
> the bylaws and contracts between ICANN and registries demand.

Also true (again see above).  However, the "consensus" process would be
improved significantly if the ICANN structure made more sense.

At present it is much like spaghetti code.

Best regards
Patrick Corliss







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



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