ICANN/DNSO
DNSO Mailling lists archives

[ga-full]


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

RE: [ga] DNSO Constituency Structure


Patrick,

Please note my responses below.

Chuck

> -----Original Message-----
> From: Patrick Corliss [mailto:patrick@quad.net.au]
> Sent: Sunday, November 25, 2001 10:08 AM
> To: Gomes, Chuck
> Cc: [ga]
> Subject: 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.

As I have communicated before, in person in GA meetings and on this list, I
believe that a new constituency should organize itself and demonstrate
strong representativeness of the community involved and then submit its
proposal for recognition.  Just because the idea of an individuals
constituency makes sense to many of us, that is not enough to approve it.
If I was a board member I would want to see evidence of an organization that
is functioning or at least ready to function and one that can show that it
represents a reasonable sample of the population it claims to represent.  In
my opinion that has never happened.

I personally think that a legitimate proposal that is backed up by a solid
organizational structure and clear evidence of fairly broad representation
from the involved community would be hard to deny even by those who may
philosophically oppose such a constituency.

> 
> 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.

As I understand the bylaws, a proposal from the board is allowable, but it
certainly does not seem to be forthcoming.  So sitting around waiting for
this seems futile.  It seems smarter to self-organize.  I say that
understanding the enormity of the task which brings me to the ALSC
recommendations.  The users SO may be the most realistic way of
accomplishing the objectives related to an individuals constituency.

> 
> 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.

In my opinion voting and consensus do not go together.  Voting could be used
to sample peoples' positions (e.g., straw polls) and it can be used by the
NC and the Board to determine whether they believe the evidence was
presented supports consensus but the latter should only happen after
complete documentation of the consensus recommendation is provided.

Everyone wants consensus development to be easy.  I don't think it should or
can be.  If consensus cannot be reached, let the market forces work instead
of trying to regulate everything.  That has been a very successful approach
in the successful economies of the world.  Consensus in my opinion is not
voting on what idea is most popular but rather working together to develop a
position that reasonably takes into consideration the major concerns and
that will be supported by the majority of stakeholders.

> 
> 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.

I like the concept of a Users SO, a Producers SO and a Developers SO like
the ALSC proposed, although I have not particularly fond of the name
"developers" as applied to the ASO and PSO.

> 
> > 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.

I also have come to the conclusion that a structural change would help.

> 
> 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 >>>