Subject: GA-DIGEST V1 #874
From: [email-masked] (GA-DIGEST)
To: [email-masked]

GA-DIGEST          Sunday, November 25 2001          Volume 01 : Number 874

----------------------------------------------------------------------

Date: Sun, 25 Nov 2001 08:34:14 -0500
From: "Gomes, Chuck" <[email-masked]>
Subject: [ga] RE: Consensus development process

Danny,

Please show me the consensus development process and then help me understand
its legitimacy in terms of representation of all stakeholders, in terms of
documentation of of both proponents and those who disagree, in terms of
effective outreach, etc.  All I have seen are efforts to skirt around such a
process.  Working Group D made a good start at identifying what needed to be
done, but little has been done to follow up on that work.

Chuck

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, November 24, 2001 11:51 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Consensus development process
> 
> 
> Chuck Gomes writes that "no valid consensus development 
> process has ever been 
> put into place."  I find this comment somewhat troubling at a 
> time when the 
> Names Council has established a Task Force charged with 
> arriving at a binding 
> consensus policy regarding the issue of transfers.
> 
> The last thing that any registrant wants is to have a 
> disgruntled set of 
> registrars challenge a consensus determination on this matter 
> and further 
> delay efforts at resolution of an ongoing problem.  If Chuck 
> has legitimate 
> concerns regarding the consensus development process, now 
> would be the time 
> to air those specific concerns so that we can move forward 
> properly and 
> finally put this issue behind us.
> 
> 
- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Sun, 25 Nov 2001 08:54:10 -0500
From: "Gomes, Chuck" <[email-masked]>
Subject: RE: [ga] RE: DNSO Constituency Structure

Patrick,

I also think Danny did a very good job in discussing consensus in the
message to reference below.  In fact I personally complemented him in this
regard after first reading it.

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.  Regardless of what structural
changes are made, if clearly defined processes and procedures are not put
into place, we will find ourselves right back where we are now.  In a global
and hugely diverse environment like the Internet, consensus will always be
hard to reach.  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.  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, but in reality they are a far cry from what
the bylaws and contracts between ICANN and registries demand.

Chuck 

> -----Original Message-----
> From: Patrick Corliss [mailto:[email-masked]]
> Sent: Saturday, November 24, 2001 12:51 PM
> To: Gomes, Chuck
> Cc: [ga]
> Subject: Re: [ga] RE: DNSO Constituency Structure
> 
> 
> On Sat, 24 Nov 2001 10:14:16 -0500, Chuck Gomes wrote:
> 
> 
> > I don't disagree with any of the arguments about the failure of the
> > consensus system within ICANN but I attribute that to the 
> fact that no
> > valid consensus development process has ever been put into place.  I
> > also recognize that such a task would be very challenging.
> 
> Hi Chuck
> 
> Danny has answered this quite well on the Names Council 
> mailing list.  It is
> a little long, and it may not be the answer, but it is worth reading.
> 
> My view is that the wording of the process (below) needs 
> tightening up to
> provide those doing the work with clearer guidance as to 
> whether they have
> satisfied the relevant criteria.
> 
> The failure of the consensus system has a number of reasons 
> which I see as
> being caused by the need to get agreement from too many 
> conflicting parties.
> 
> In other words it is more a structural problem than a procedural one.
> 
> Regards
> Patrick Corliss
> 
> On Mon, 8 Oct 2001 23:27:43 EDT, Danny Younger wrote:
> Subject: [council] Consensus defined
> 
> To the representatives of the registrar and registry constituencies:
> 
> As an individual employed by a registrar, I am reasonably 
> familiar with the
> Registrar Accreditation Agreement and with the Registry 
> Agreement, both of
> which cite the following definition of consensus policies:
> 
> "Consensus Policies" are those specifications or policies 
> established based
> on a consensus among Internet stakeholders represented in the 
> ICANN process,
> as demonstrated by (a) action of the ICANN Board of Directors 
> establishing
> the specification or policy, (b) 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 (c) 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 policy.
> 
> It would have been reasonable to assume that this definition 
> would have been
> brought to the attention of the NC Review Task Force.  
> Instead, the author
> of the Task Force report has had to resort to rather poor 
> "guidance" from
> lexicons.   This has resulted in aberrant conclusions that 
> have led to the
> misguided recommendation that "the by-laws should be changed to remove
> the obligation on the NC to "determine community consensus"".
> 
> Changing the Bylaws is a serious matter that should not be considered
> lightly.  Changing Bylaws that pertain to consensus policies, the only
> policies we have that can bind even recalcitrant participants, is
> particularly serious business.
> 
> When we review the White Paper, we note that consensus 
> requirements are
> viewed as a mechanism to be used to protect against capture by a
> self-interested faction.  The Names Council, by definition, is a
> self-interested faction.  Accordingly, the definition 
> currently used by
> ICANN establishes as a requirement the absolute need to 
> thoroughly represent
> the views of groups that are likely to be impacted.  These 
> "groups" are
> parts of the Internet community that may not have 
> representation within
> the Names Council.
> 
> One of ICANN's founding principles is fairness.  Changing the 
> Bylaws so that
> the NC no longer has the obligation to determine community consensus
> violates this founding principle.  The declaration that "the 
> NC vote itself
> on a recommendation, being reflective of the elected 
> representatives of
> DNSO stakeholders, is the "only" practical means of 
> determining community
> consensus" is spurious... there are many other stakeholders 
> in the ICANN
> world other than the DNSO stakeholders, and clearly, there 
> are indeed other
> practical means of determining community consensus.
> 
> One such method that has withstood the test of time is the 
> use of an open
> working group.  The Task Force report concludes that "DNSO 
> working groups as
> currently formed are by construction not a representative 
> sample of DNSO
> stakeholders because they are open to participation by anyone 
> who chooses."
> Again, the author of this report has completely missed the 
> point.  Every NC
> constituency  can participate in an open working group as well as
> individuals that are not currently represented in the DNSO -- 
> this makes the
> working group even more representative of the broader 
> Internet community,
> and thus more capable of arriving at true consensus than a 
> body that is only
> limited to DNSO stakeholders.
> 
> The author of the Task Force report contends that the Council has been
> provided with "no help as to how the task should be done."  
> The task to
> which he refers is to "determine that the DNSO process has produced a
> community consensus".  Help is most certainly available.  It 
> is contained in
> the current definition of a consensus policy.  To determine 
> if consensus
> exists:
> 
> a.  you must first propose a policy
> b.  you must then engage in outreach to those that are likely 
> to be impacted
> by the new policy
> c.  you must document your outreach efforts to prove that you have
> adequately represented the views of those likely to be impacted
> d.  you must ask for substantive submissions by those that 
> might be impacted
> e.  you must include all such substantive submissions in your report
> f.  based upon those submissions, you must document the extent of
> agreement/disagreement among impacted parties
> g.  you must document the nature and intensity of reasoned support or
> opposition to the proposed policy
> h.  you must provide a written report citing all the above 
> findings and
> justifying your conclusions
> i.  you must make such a complete report available for review by the
> constituencies
> j.  you must include all constituency comments in your 
> supporting materials
> k.  you must revise your report accordingly in view of 
> constituency comments
> l.  then the report must be made available for public comment
> m.  all public comments must be included in the supporting materials
> n.  the report must next by re-assessed in light of the 
> public comments, and
> then finalized.
> o.  at this point the Council is at liberty to vote on the policy
> recommendation
> p.  results of such a vote are forwarded to the Board.
> 
> All of this is necessary because a consensus policy must be able to
> withstand the prospect of examination by the Independant Review Panel,
> the American Arbitration Association and/or judicial scrutiny 
> in any court
> of competent jurisdiction (as indicated by the relevant paragraphs in
> several of ICANN's major agreements).
> 
> A hastily ratified report serves no one's best interest.  It is quite
> apparent that the Interim Review Task Force report should be returned
> to the body from which it originated for further work.  There 
> is no need
> for a shoddy report just because it is deemed necessary to 
> strictly adhere
> to a self-imposed timeline that would ensure a final 
> presentation at the
> upcoming plenary session.
> 
> There are too many deficiencies in this report at present, 
> only some of
> which are cited above. I urge you all to send this report back to the
> drafting table, and to offer the benefit of your guidance to 
> a Task Force
> that sorely needs your input on "consensus".  The Bylaws require no
> change... it is this report that requires change.
> 
> 
> 
- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Mon, 26 Nov 2001 02:03:52 +1100
From: "Patrick Corliss" <[email-masked]>
Subject: [ga] What Does the PSO "do" Except Electing ICANN Directors ??

                  ICANN Protocol Standards Organization (PSO)

                      October 26, 2001 Teleconference

     Reported by Vladimir Androuchko, PSO-PC Secretary as of August 2001

Present:
  Steve Bellovin
  Fabio Bigi
  Azucena Hernandez
  Leslie Daigle
  Tapio Kaijanen
  Brian Moore
*********************************************************
Regrets:
  Daniel Weitzner
  Philipp Hoschka

1. Protocol Council Members thoughtfully analyzed the At-Large Study
Committee Draft Report on ICANN Membership. The PSO PC has not reached
consensus on comments to the ALSC document.  That is why ETSI
representatives and IETF representatives submitted their respective
comments.  ITU-T representatives did not provided any additional comments.
W3C representatives did not provide comments. The comments sent to the ALSC
can be viewed at the following address:
  http://www.pso.icann.org/PSO_Statements/PSO-Statements-26October2001.txt

2. The issue of SRS (shared registry system) was brought to the
consideration of the Protocol Council and it was decided to further study
this issue and to discuss it again.

3. The issue of ccTLD Support organization was raised by Mr. H. Schink,
Director of the ICANN Board. There were no objections for the creation of
such organization.  ETSI representatives stressed that as long as the number
of seats allocated to PSO on the ICANN Board were not going to decrease, any
new Supporting Organization is welcome.

4. PSO-PC Report for the ICANN Meeting was discussed. Protocol Council
Members tasked the secretary to contact Mr. S. Lynn, CEO of ICANN, in order
to ask him for some clarifications concerning the procedures and matters to
be included in the report. The secretary was tasked to prepare a draft of
the report on the PSO-PC activities and to submit it to the Protocol Council
Members for their consideration.

5. Security issues in the Internet were discussed. It was decided to ask
each organization to report to PSO-PC on the activities in the security
field. After this step, Protocol Council will decide on the further actions.

6. The issue of a Nominee to the ICANN Internationalized Domain Names
Committee was discussed on the suggestion of Mr. S. Lynn, who sent the Note
to PSO-PC, asking whether PSO-PC was interested to propose its candidate to
this Committee.  The secretary was tasked to ask Mr. Stuart Lynn for some
clarifications on the procedures of elections and nominations. The Protocol
Council will need some more time to take its decision.  ETSI representatives
proposed their candidate, Mr. Roberto Laorden, member of the Board of CORE
(Council of Registrars) and member of the ICANN Group on Evaluation of new
gTLDs.

7. Mr. Fabio Bigi is going to take his retirement at the end of this month.
He will ensure his functions of Protocol Council Member until the new
representative of TSB will be appointed. All Protocol Council Members
expressed their warm friendly feelings and wished Mr. Fabio Bigi all the
best.

8. The next teleconference was scheduled on Friday, December 7, at 15h00
CET.

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

------------------------------

Date: Mon, 26 Nov 2001 02:08:25 +1100
From: "Patrick Corliss" <[email-masked]>
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.

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 [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Sun, 25 Nov 2001 07:47:36 -0800
From: Kent Crispin <[email-masked]>
Subject: Re: [ga] RE: DNSO Constituency Structure

On Sun, Nov 25, 2001 at 08:54:10AM -0500, Gomes, Chuck wrote:
> Patrick,
> 
> I also think Danny did a very good job in discussing consensus in the
> message to reference below.  In fact I personally complemented him in this
> regard after first reading it.
> 
> 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.  Regardless of what structural
> changes are made, if clearly defined processes and procedures are not put
> into place, we will find ourselves right back where we are now.  In a global
> and hugely diverse environment like the Internet, consensus will always be
> hard to reach.  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.  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, but in reality they are a far cry from what
> the bylaws and contracts between ICANN and registries demand.

That is, NSI/VSGN will feel free to ignore whatever conclusions may come
from any task force of the DNSO.  

That's very convenient for VSGN, but I don't accept your premise.  Task
forces and the like are clearly contemplated in the bylaws:

  b) The NC is responsible for the management of the consensus building
  process of the DNSO.  It shall adopt such procedures and policies as
  it sees fit to carry out that responsibility, including the
  designation of such research or drafting committees, working groups
  and other bodies of the GA as it determines are appropriate to carry
  out the substantive work of the DNSO.

And are consistent with the relevant text from the contract:

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

Working groups, such as described in the WG-D report, have simply not
worked out as a means of generating substantive work across a broad
population -- they inevitably seem to degenerate to a small core of 
contentious people who drive away all other participants, and then 
produce a report that has a very narrow base.  (It pains me to say 
this, because I am a big fan of the IETF model -- I do hope that in the 
long run, as ICANN becomes more and more mundane, that WGs will be 
possible.  But it is undeniably true that they have not worked well so 
far.) 

Task forces and so on were developed as a means of getting productive
work done in a very noisy and contentious environment, and they are
making progress.  Surveys and similar instruments, though they have
their own faults, are proving to be a much more objective and useful
means of gauging community sentiment than are noisy mailing lists. 

In sum, I think the claims you are making are groundless.  Finding
consensus policies is indeed very difficult work, but the processes
currently in use meet both the terms of the ICANN bylaws and the terms
of the registry contracts, and, though progress is slow, consensus
policies, as defined in the bylaws and contracts, are being developed.

It would of course be convenient for VSGN to be able to ignore those 
policies at whim, so I can understand why it would be in their interest 
to cast the undeniable noise as a "failure of consensus".

- -- 
Kent Crispin                               "Be good, and you will be
[email-masked]                           lonesome." -- Mark Twain
- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Sun, 25 Nov 2001 11:06:31 -0500
From: "Ross Wm. Rader" <[email-masked]>
Subject: Re: [ga] RE: DNSO Constituency Structure

Chuck,

> 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, but in reality they are a far cry from
what
> the bylaws and contracts between ICANN and registries demand.

Two things...

First, an observation - I'm guessing (based on some extrapolations of mine,
please feel free to correct me if I'm wrong) that Verisign's position on
"consensus policy" is directly tied to how preferential the consensus policy
is to Verisign? I mean, and feel free to call me a cynic, but I don't
remember Verisign's having much concern for the sanctity of the "process"
during the renegotiation of your registry/registrar contracts earlier this
year.[1] The public record seems to indicate that the only element of
consensus that touched on that deal was that of the Verisign executive - "we
must preserve our monopoly in the DNS".

Second, your characterization of the task forces as being somehow
"illegitimate" are pretty shallow. The contracts and bylaws are pretty clear
that a task-force, and similar constructs, are indeed legitimate mechanisms
that facilitate the policy development process. They could be deemed,
depending on the interpretation of the by-laws, a mandatory part of the
process.[2]

Anyways, you've made some pretty sweeping indictments of the structure,
processes, policy and people that make up ICANN - do us all a favor and
quantify some of these allegations. Continuing this discussion without
rooting it in fact doesn't seem, to me at least, to be a productive
exercise. Unless of course the real exercise is to create the foundation for
an argument that will later attempt to discredit the policy development
process to Verisign's advantage - if that's the case, then please carry on -
and don't stumble over those pesky facts that somebody so inconsiderately
left lying around.

- -rwr

[1] One of several the justifications given by Verisign for the fast track
process was to improve employee moral. None of these were "to support the
consensus conclusions of the ICANN process".
[2] ICANN Bylaws, VI-B.2a,b,c etc.

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

------------------------------

Date: Mon, 26 Nov 2001 03:12:47 +1100
From: "Patrick Corliss" <[email-masked]>
Subject: [ga] Revised BC Charter In Breach of ICANN's Bylaws ??

To:    GA Mailing List Members

Article 4 of the revised BC Charter says, in part:

"This [i.e. membership] excludes for-profit entities whose business means they
are likely to formulate views from the perspective of Internet or Domain Name
service providers, as well as from other groups whose interests may not be
aligned with business users.  Such entities may find other constituencies
offer more appropriate means of representing their members' interests."

Section 3 of ICANN's Bylaws states in part:

THE CONSTITUENCIES
(a)    "Each Constituency shall self-organize, and shall determine its own
criteria for participation, except that no individual or entity shall be
excluded from participation in a Constituency merely because of participation
in another Constituency, and constituencies shall operate to the maximum
extent feasible in an open and transparent manner and consistent with
procedures designed to ensure fairness."

If you look at the language used in the BC revised Charter, it specifically
EXCLUDES businesses which are ISPs etc. "who may find other constituencies
offer more appropriate means of representing their members' interests".

That looks like a clear breach of ICANN's bylaws to me.  However, the revised
Article has been very carefully worded to suggest that ISPs etc. have not
been excluded merely because of PARTICIPATION in another constituency.

No, sirree, they have been excluded because they are ELIGIBLE to participate
in another constituency !!

Does this "get them off on a technicality"  (as the criminal lawyers say) ?
I don't think so as that is not fairness to the "maximum extent possible".

Best regards
Patrick Corliss

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

------------------------------

Date: Sun, 25 Nov 2001 11:12:59 -0600
From: "Jim Fleming" <[email-masked]>
Subject: [ga] The Consensus....is in the Code...

The Consensus....is in the Code...not the Contracts...

http://www.dot-biz.com/IPv4/Tutorial/

Jim Fleming
http://www.ddj.com/articles/search/search.cgi?q=fleming
Oct93: The C+@ Programming Language 

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

------------------------------

Date: Sun, 25 Nov 2001 10:09:56 -0800
From: Roeland Meyer <[email-masked]>
Subject: RE: [ga] Revised BC Charter In Breach of ICANN's Bylaws ??

Actually, that's not any better or worse than what they had before. It also,
doesn't solve the problem. NewNet isn't eligible, for the BC, because they
might be better served by a registry constitituency, which won't have them
because they are regligiously incompatible, thus leaving them out even
though they are a legal organization, in the US, practicing a legal
activity. 

This is basically, practicing illegal discrimination under US charter. Can
we say "Jim Crow"? Catholics, Blacks, and Jews need not apply because we are
a WASP church.

ICANN cannot claim to be all-inclusive and they are in violation of the DOC
MoU.

|> -----Original Message-----
|> From: Patrick Corliss [mailto:[email-masked]]
|> Sent: Sunday, November 25, 2001 8:13 AM
|> To: Philip Sheppard
|> Cc: [ga]
|> Subject: [ga] Revised BC Charter In Breach of ICANN's Bylaws ??
|> 
|> 
|> To:    GA Mailing List Members
|> 
|> Article 4 of the revised BC Charter says, in part:
|> 
|> "This [i.e. membership] excludes for-profit entities whose 
|> business means they
|> are likely to formulate views from the perspective of 
|> Internet or Domain Name
|> service providers, as well as from other groups whose 
|> interests may not be
|> aligned with business users.  Such entities may find other 
|> constituencies
|> offer more appropriate means of representing their members' 
|> interests."
|> 
|> Section 3 of ICANN's Bylaws states in part:
|> 
|> THE CONSTITUENCIES
|> (a)    "Each Constituency shall self-organize, and shall 
|> determine its own
|> criteria for participation, except that no individual or 
|> entity shall be
|> excluded from participation in a Constituency merely because 
|> of participation
|> in another Constituency, and constituencies shall operate to 
|> the maximum
|> extent feasible in an open and transparent manner and consistent with
|> procedures designed to ensure fairness."
|> 
|> If you look at the language used in the BC revised Charter, 
|> it specifically
|> EXCLUDES businesses which are ISPs etc. "who may find other 
|> constituencies
|> offer more appropriate means of representing their members' 
|> interests".
|> 
|> That looks like a clear breach of ICANN's bylaws to me.  
|> However, the revised
|> Article has been very carefully worded to suggest that ISPs 
|> etc. have not
|> been excluded merely because of PARTICIPATION in another 
|> constituency.
|> 
|> No, sirree, they have been excluded because they are 
|> ELIGIBLE to participate
|> in another constituency !!
|> 
|> Does this "get them off on a technicality"  (as the criminal 
|> lawyers say) ?
|> I don't think so as that is not fairness to the "maximum 
|> extent possible".
|> 
|> Best regards
|> Patrick Corliss
|> 
|> 
|> 
|> 
|> 
|> 
|> 
|> 
|> 
|> 
|> 
|> 
|> --
|> This message was passed to you via the [email-masked] list.
|> Send mail to [email-masked] to unsubscribe
|> ("unsubscribe ga" in the body of the message).
|> Archives at http://www.dnso.org/archives.html
|> 
- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Sun, 25 Nov 2001 11:35:38 -0800 (PST)
From: Patrick Greenwell <[email-masked]>
Subject: Re: [ga] RE: DNSO Constituency Structure

On Sun, 25 Nov 2001, Ross Wm. Rader wrote:

> Anyways, you've made some pretty sweeping indictments of the structure,
> processes, policy and people that make up ICANN - do us all a favor and
> quantify some of these allegations. Continuing this discussion without
> rooting it in fact doesn't seem, to me at least, to be a productive
> exercise. Unless of course the real exercise is to create the foundation for
> an argument that will later attempt to discredit the policy development
> process to Verisign's advantage - if that's the case, then please carry on -
> and don't stumble over those pesky facts that somebody so inconsiderately
> left lying around.

Ross,

Might it be more productive to listen to what is said rather than who
is saying it?

I can offer countless examples of how the consensus process within ICANN is
largely a sham and I could hardly be considered a fan of Verisign. For
starters: the founding documents of ICANN, the sweeping bylaw changes that
have been made, the "clean sheet study" to decide whether or not
individuals should be represented within ICANN, the UDRP, the board
squatters, the TLD selection process, ICP3, the list goes on and on and
on.

Quite honestly I can't even remember half the examples because there are
so many.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                               Patrick Greenwell
       Asking the wrong questions is the leading cause of wrong answers.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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

------------------------------

Date: Sun, 25 Nov 2001 14:43:40 -0500
From: "Ross Wm. Rader" <[email-masked]>
Subject: Re: [ga] RE: DNSO Constituency Structure

> > Anyways, you've made some pretty sweeping indictments of the structure,
> > processes, policy and people that make up ICANN - do us all a favor and
> > quantify some of these allegations. Continuing this discussion without
> > rooting it in fact doesn't seem, to me at least, to be a productive
> > exercise. Unless of course the real exercise is to create the foundation
for
> > an argument that will later attempt to discredit the policy development
> > process to Verisign's advantage - if that's the case, then please carry
on -
> > and don't stumble over those pesky facts that somebody so
inconsiderately
> > left lying around.
>
>
> Might it be more productive to listen to what is said rather than who
> is saying it?

My point was that what was being said was inaccurate and self-serving. Sort
of speaks to both conditions actually.

>
> I can offer countless examples of how the consensus process within ICANN
is
> largely a sham and I could hardly be considered a fan of Verisign. For
> starters: the founding documents of ICANN, the sweeping bylaw changes that
> have been made, the "clean sheet study" to decide whether or not
> individuals should be represented within ICANN, the UDRP, the board
> squatters, the TLD selection process, ICP3, the list goes on and on and
> on.

Don't confuse the development of consensus policy with "truth" or
"unanimity". What I find intriguing is that what you hold up as failures of
the process, I look to as successes of the process. Context, condition and
perspective all lend to that difference, but regardless, ICANN is hardly the
drastic failure that some might have one believe.

- -rwr

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

------------------------------

Date: Sun, 25 Nov 2001 14:55:44 EST
From: [email-masked]
Subject: [ga] Consensus & Names Council Task Forces

Patrick Corliss wrote:  "Could you confirm, for example, that there are seven 
task forces and that you are the GA representative on three of them?"  This I 
can confirm. 

It was my expectation that GA members that purportedly represented the 
interest of domain name holders would have clamored to join these particular 
task forces, but it appears that these petty parliamentarians instead 
preferred to devote their time playing king of the hill and engaging in 
relentless sniping and back-stabbing rather than getting any meaningful work 
done on behalf of the registrant community... that left it up to me to 
represent the GA and registrants on these task forces in the absence of any 
articulated interest on the part of these so-called champions of domain name 
owners.

These task forces are invariably long term projects that require 
participation at several plenary sessions, participation in 
regularly-scheduled teleconferences, and hundreds of hours of work.  They 
require a commitment of time, travel and money.  Yet every time that I 
presided over a GA session and looked out into audience, I  noted that the 
"active" GA membership was never there.  Yes, they are perfectly willing to 
bitch and complain, but they are rarely prepared to participate to the same 
degree as every other constituency that has chosen to work within the ICANN 
process.   

Why is it that even the NCDNHC (that successfully operates even without an 
acknowledged Charter) always manages to get its members to ICANN sessions 
even though many are at a severe financial disadvantage, while GA members 
from wealthier nations that ostensibly represent the registrant community 
can't even bother to show up?  In my view, this is because those NCDNHC 
members are dedicated individuals and have made a commitment to the process 
even while knowing that their positions will routinely be voted down in the 
Council.  Because they have demonstrated their resolve through physical 
attendance, their minority views are, at the very least, respected.  When 
they comment on the At-Large Study report, the Board listens... 

By contrast, when the GA speaks, decision-makers pay scant attention because 
the GA has earned absolutely no respect.  It's active membership is almost 
never there to either engage or lobby the members of the Board, nor is it 
there to interact with other constituencies -- it has demonstrated no 
commitment, and it is viewed by many as nothing more than a haven for 
crackpots and malcontents.  The GA as a collectivity of individuals is not an 
organization, it is nothing more than a discussion list for DNS afficionados 
and future tyrants.  It will never become more than it currently is because 
individually its members are not prepared to make a commitment to necessary 
involvement -- even those GA members that ran for ICANN Board seats would not 
commit to actually showing up at an ICANN meeting.  

If someone in this group wants to step up to the plate and become a Task 
Force member, I will willingly give my seat to that individual.  Perhaps in 
such fashion there might actually be more than one or two people from the GA 
at the next Ghana session... but I doubt it.   It's easy to give lip-service 
to development and discussion of work items, draft document preparation, and 
participation in committees and task forces... it's entirely another matter 
to actually do the work.   

In the three years that an individuals constituency has been discussed, has 
anyone even bothered to raise the necessary funds required for participation? 
  Of course not, that would imply responsibility and a true commitment to a 
cause.    Perhaps we should just pretend that the $14,000 annual dues will 
magically appear or be graciously waived by the other constituencies that 
have conscienciously put their money up.  You can talk about restructuring as 
much as you like but there will never be a self-funded individuals 
constituency in the DNSO because there is no motivated membership, there are 
only those that use the cause of registrants to promote their own 
self-interest.

I see no hope for the GA as currently constituted and have to ask, why should 
our Board members even want to have a GA in the restuctured ICANN?  There 
will be an elected At-Large to represent the user interest.  The GA will be 
nothing more than a useless appendage in the DNSO, a structural redundancy 
that will not be needed or desired when the At-Large is established.  If the 
Board Restructuring Task Force recommends the abolition of the GA, this will 
come as no great shock to me.  

I will also not be surprised to see all of you attempt to bolt to the 
At-Large the moment that the SO is created.  Not that any of you will 
actually involve yourselves in building the At-Large, organizing its 
structure and raising the necessary revenues, that would be too much too 
ask... instead you will wait until it is handed to you as a finished product 
by the ICANN staff and the ALSC, and then proceed to gripe about it's Charter 
and everything else because bitching is all that most of you are prepared to 
contribute to the process.

It's easy to be a critic of ICANN.  It's harder to support its mission and to 
work to get things done.  Soon you will have a new Chair and Alt. Chair for 
the General Assembly... I offer them my sympathies.
- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

End of GA-DIGEST V1 #874
************************