On Sun, Feb 14, 1999 at 07:14:52PM -0500, Antony Van Couvering wrote:
> We have heard some proponents of the BMW application say and repeat that
> their application automatically protects minority interests, and that the
> Names Council as conceived by that document is not a powerful body at all
> but instead one whose powers are greatly limited by the requirement to
> consult with constituencies when it comes to making policy recommendations
> to the ICANN Board.
Thanks for your detailed input. You seem to have missed a very
important point, however, which I thought I mentioned in my
commentary and explanation for the WMP draft:
The WMB application is an APPLICATION. It is NOT a set of
bylaws.
As an application it expresses the collective understanding of the
signatories about how things should and will be done. It does not
spell out in detail how to do them.
So, for example, when the application says that "The Names Council is
intended to act primarily as an administrative and management body",
it means exactly that. It does not, however, spell out the exact
mechanisms that will guarantee this -- the application maintains a
fairly high-level view.
The choice of going to a simplified, high-level view was deliberate.
The prior versions I worked on were getting quite detailed, and no
one would read them. The application form, on the other hand, is
short enough to actually read and understand -- well, we hoped it
was, anyway -- as we shall see, you give clear proof that
people don't read this document either).
Note that it is premature to draft bylaws per se, because there are
large undetermined questions -- the issue of separate incorporation,
for example -- that will have a *big* effect on the shape of the
bylaws document, but should have little effect on the workings of
the DNSO.
> Leaving aside the enormous power (and potential for abuse) vested in the
> Names Council by virtue of its ability to appoint members to the ICANN
> board,
Sigh. The NC does not "appoint" members of the ICANN Board. The
actual process is that a nominating committee is formed, one member
from each constituency, to find potential candidates for the ICANN
board. The constituencies appoint their respective members of the
nominating committee.
There are other ways you could select a nominating committee, of
course. The experience from the IETF and ISOC, however, is that it
is damn hard to get people who want the job...
You need something like a nominating committee, because being an
unpaid board member for ICANN is a non-trivial, important, largely
thankless task that intelligent people will probably shun (no slight
intended to the present directors :-). Note also that half the ICANN
board members will be elected by a membership already -- in the WMB
document the role of the selection process is to provide expert,
professional board members. (I explained this difference in
philosophy in the commentary I sent out. It seems abundantly clear
you didn't read that...)
Once the nominating committee has selected a raft of candidates the
NC votes on them, it is true. But most of the work has already been
done by the nominating committee. Note that this process is
considered more like an executive search than it is a popular
election.
Incidentally, the point about the difficulty of finding people to
serve on the Nominating Committee is something I hadn't considered
as a factor until recently. This is also the reason for shortening
the term of office for the members of the NC -- these are all
non-paid, time-consuming jobs, and practical experience among people
who have served in such roles is that people simply burn out. Two
years is a shorter prison term than three years.
> I have examined the BMW draft closely
That is, kindly, utter nonsense. You have not examined it very well
at all, as I will show below.
> and have found that these
> contentions of limited powers and minority protections are not to be found
> in the language of the draft -- whether by inadvertancy or design, I can't
> say.
It was by design that the application was simplified, but not, as you
imply, for nefarious motives. Nor are the protections removed.
Instead, the goal is to present a high level understanding of the
agreement between all the signatories, and, where the ICANN bylaws
specify protections, simply adopt those.
> Following is a line-by-line analysis of the procedure for developing
> policies within the DNSO as defined by the BMW application, which I believe
> shows that (a) given the very little attention given to the details of the
> drafting/research committee procuedures, and (b) given the powerful
> potential for abuse of the constituency system, the BMW application has the
> following effects:
Unfortunately, the bottom line is that your line by line analysise is
off the mark, for the reasons I cite above. However, even with those
caveats you analysis is so faulty that I feel it necessary to
respond, line by line...
> 1. Vests tremendous power in the Names Council wrt developing policy (forget
> the fact that they select DNSO members to the ICANN Board), because the
> Names Council and the "constituencies" as defined in the application may be
> in practice one and the same.
The internal logic of this point is non-existent. Even if the
constituencies and the NC were the same, that doesn't mean the NC
has "enormous power". In fact, it has nothing to do with it --
similarity between the NC and the Constituencies is almost (not
quite, I grant) totally orthogonal to the amount of power the NC
has.
> 2. Does not provide for consultation with the DNSO membership, because the
> constituencies are under no obligation (depending on their rules) to consult
> their members, or even under any obligation to be fair
As components of the DNSO they are required to meet the same
standards of fairness and openness as the ICANN Board:
"The processes of the Names Council (and the processes of each
constituency) shall be governed by the same provisions for open
and transparent non-discriminatory processes as those of the
Board of the Corporation."
> 3. Effectively provides veto power for many interest groups, because of the
> difficulty of pre-defining constituencies and because of the ability of any
> member to join more than one constituency. As defined now, both
> business/trademark interests and registrars/ISPs will have a veto.
Correction: allows for the submission of minority opinions by these
groups.
> 4. Allows the consideration of any topic to be blocked by a majority of the
> Names Council, giving the Names Council far more power to delay or prevent
> the forwarding of a recommendation to ICANN than anything contained in the
> Paris Draft.
This is simply false. The NC is required to consider anything any
single constituency bring for consideration:
"Constituencies may provide initial input to the Names Council on
a given topic. If the Names Council undertakes consideration of
a topic, OR IF A CONSTITUENCY REQUESTS CONSIDERATION OF A TOPIC,
THE NAMES COUNCIL *SHALL* DESIGNATE one or more research or
drafting committees, as appropriate..."
> 5. Allows the drafting/research committees to proceed wholly in secret, with
> no record-keeping, no minutes, and no requirement for broad-based
> participation or indeed participation of any interested parties at all.
As mentioned above, all proceedings of the DNSO are required to
follow the guidelines for open fair etc that the ICANN board are
required to follow.
It's true that the exact mechanisms of committee operation were
left unspecified, for the reasons I mentioned above. Also, it is
worth noting that there are many unknowns about how the DNSO and
ICANN will interact in terms of their membership -- committees
might draw on the ICANN membership for user input. Given the
number of unknowns, it seemed wise to leave things less specified.
> Let's examine what practical meanings and applications the BMW consultations
> *could* have. I'll push the interpretations here a bit, because I want to
> expose the ambiguities and weaknesses. Here's how the normal process would
> work. (Note: the following paragraphs below come consecutively, in their
> entirety, from Section II.A of the BMW draft.)
>
> "Constituencies may provide initial input to the Names Council on a given
> topic. If the Names Council undertakes consideration of a topic, or if a
> constituency requests consideration of a topic, the Names Council shall
> designate one or more research or drafting committees, as appropriate, and
> shall set a time frame for the draft."
>
> Problems:
> 1. No specification of who will be on the research/drafting committee.
Pity you won't read: "The Names Council may from time to time appoint
research or drafting committees to review matters, draft proposals
and provide expert recommendations to the Names Council. SUCH
COMMITTEES SHALL BE COMPOSED OF AT LEAST ONE REPRESENTATIVE FROM EACH
CONSTITUENCY."
> 2. No requirement that there will be any research at all. Under this
> language, it is possible that the Names Council will round up some people
> and say, "OK, we have this idea, put it in writing."
1) How do you "require" that research actually be done? These are all unpaid
volunteers. You can put all kinds of formalisms around it, but the
bottom line is that what work gets done will depend on the
individuals involved.
2) It may in fact be appropriate, under some circumstances, to round
up some people to just draft some language.
> 3. A more likely and dangerous possibility is that the members of these
> committees could be drawn excusively from the ranks of the Names Council,
> and no-one else will even know about the topic until is presented to them in
> finished form -- in other words, there will be no input from anyone outside
> the Names Council until the proposed recommendation is in a "first draft"
> stage.
The application says:
"The Names Council SHALL seek input and review..."
It's not an option to not seek input and review.
> 4. No parameters for time frames -- what is expected to be normal? A day, a
> week, a month?
It is impossible to know at this point what might be "normal" and
what might not.
> 5. No requirements for record-keeping and public notification of the
> Research/Drafting committees, so we'll never know *how* they reached their
> decisions. Is this the International Olympic Committee or an organization
> with "fair, open, and transparent" processes?
It says the requirements are the same as for the Board of ICANN.
> Continuing:
>
> "The draft shall then be returned from the committee for review by Names
> Council. The Names Council may either accept the draft for submission back
> to constituencies for comment and consultation or return the draft to the
> committee for further work. After the draft is submitted to the
> constituencies and the comment period for the constituencies is over, the
> Names Council shall evaluate the comments to determine whether there is the
> basis for a consensus recommendation."
>
> Problems:
> 1. If the Names Council doesn't like what it sees, it can send it back to
> the committee. It can do this for ever and ever. There is no requirement
> that the constituencies ever see any draft. There is no requirement that
> they even know about the existence of a draft.
This is plain silly. In your scenario some constituency brought up
the matter to begin with. The NC is required to keep public
minutes, etc etc.
> 2. A very very large problem now crests, a ripple effect (tsunami effect?)
> from the extreme vagueness of how constituencies are supposed to operate
> internally. The only specification of this comes from Section I.A: "The
> DNSO membership shall consist of constituencies, as described below. Each
> constituency shall self-organize and determine its own criteria for
> membership. Such criteria shall be publicly available." There is not even
> a requirement that the constituencies follow the apple-pie ICANN mantra of
> being "fair, open, and transparent."
Yes. There is. Please read.
> For the purposes of this discussion on
> how policies are developed, the immediate objection is that it is possible
> for the "constituency" to be "consulted" merely by running the draft past
> the Names Council members from that constituency - depending on how the
> constituency organized itself. As constituencies are to be organized
> according to rules developed only by the initial members, it may well have
> top-heavy seniority rules that prevent meaningful participation by later
> entrants, or even weaker initial entrants. Thus there is no guarantee or
> even expectation that minority or dissident members of a constituency will
> have any voice at all. So the idea that the Names Council is necessarily
> going to get any sense of what a constituency thinks (as opposed to what its
> leaders think) is a chimera.
The *above* is a chimera. You pile one unlikihood on top of another
and in the end get a Dr Strangelove result -- surprise, surprise. In
*any* organizational structure, if all the parties involved are evil
you could well get an evil result. It's true for the Paris Draft, as
well.
Aside: The DNSO will be required to come up with a method for
changing the constituencies. This is a significant problem; it's a
problem for the Paris draft, as well. (The Paris draft makes it easy
to create new constituencies -- it doesn't deal with the *very
difficult* problem of getting rid of constituencies.) Constituencies
will tend to entrench, and resist change to their place in the
structure. We discussed this at some length on one telecon -- the
conclusion was that it is indeed a big problem, but it is not an
immediate problem -- we don't have to solve the entrenchment problem
right now because entrenchment is by definition something that
happens over time. Note that this is explicitly spelled out as a
task for the DNSO and the NC: "The DNSO and the Names Council will
develop fair and open procedures for the creation, deletion, and
merger of constituencies; and adjustment of the representation of
constituencies on the Names Council."
> 3. The comment period, and comments. How long is it? Is it long enough to
> generate a meaningful discussion? How are comments to be forwarded? Does
> anyone get to comment, or is it just "official" constituency comments that
> are to be heard. What happens to the comments? Are they filed with any
> eventual recommendation sent to ICANN, are they made part of the record? Is
> the Names Council and/or the Drafting/Research Committee obliged to respond
> to comments, or can they just put them in the circular file? This comment
> process *ought* to be the meat and potatoes of the deliberative effort of
> the DNSO, yet it is given one short sentence in the BMW draft.
The comment period is as long as necessary -- that will vary a great
deal, and the exact specification is not only unnecessary, but
probably unwise at this stage. Once again, all the proceedings of
the DNSO are required to be open....
> 4. Names Council evaluation of comments. How are they evaluated?
The general process for evaluation is to think about things.
> Is there
> any process to be followed?
None specified.
> Do Names Council members have any obligation to
> provide reasons for their votes?
How could you possibly enforce any such obligation: "I thought it was
a good/bad idea".
> Is the evaluation the same as a meeting,
> will there be publicly available minutes of the evaluation?
The evaluation will be a vote, in a meeting, with publically
available minutes of the meeting.
> Moving on:
>
> "A consensus recommendation is one that is supported by the affirmative vote
> of two thirds of the members of the Names Council and is not opposed by the
> votes of all of the representatives of any two constituencies. If a
> consensus recommendation is developed, any constituency may file a
> statement of its dissenting view to accompany the recommendation to the
> Board of the Corporation. If a recommendation is supported by an
> affirmative vote of more than one half but less than two-thirds of the
> members of the Names Council, the Council shall submit the recommendation to
> the Board of the Corporation with statements of majority and minority views.
> If a recommendation is not supported by affirmative vote of at least one
> half of the members of the Names Council, the Names Council will submit the
> proposed recommendation back to the drafting committee for re-drafting
> consistent with constituency comments.
>
> Problems:
> 1. The first sentence means that the definition of the constituencies is
> absolutely vital and critical for the DNSO, as described here in the BMW
> draft, to have any chance of working fairly and effectively. If, as critics
> of trademark interests have pointed out so often on these lists, the
> "business" and "trademark" constituencies are essentially similar, and if
> one is allowed to join one than more constituency (as indeed is allowed by
> the BMW draft) then this is a business/trademark veto.
No. It's not. At most it means that the recommendation is passed
on a majority vote, and the Business/TM group gets to write one or
more dissenting opinions...
> 2. The "dissenting view" accompaniment brings up again the question of how
> minorities in constituencies are handled. It is possible that even though
> 49% of a constituency dissents, their dissent won't be recognized because
> they don't have a majority within the constituency.
That's possible. In the Paris model they wouldn't be heard, either
-- in fact they would have a lot less of a voice, because 49% of a
constituency could be 2.5% of the membership -- and in the case of
the registries, they could be a much lower percentage of the total
membership.
Now, there is the possibility that 49% of *every* constituency is
against something, AND that all the constituencies decide things by a
simple majority vote, AND probably some other conditions. In this
case it might seem that the dissent could be stifled. BUT, a
grievance could be called, a Fair Hearing Panel could be empowered,
this large group of people (many of whom will be members of ICANN)
could complain directly to ICANN, and finally, all these proceedings
are open.
There are *many*, *many* avenues for dissent to be heard.
> 3. Statements of majority and minority views - one view per side, or more
> than one? Surely the idea should be to send to ICANN the full sense of the
> DNSO, not just a one side, or two sides.
In a complicated case that might indeed happen. However, the whole
point of this exercise is that there be some distillation of opinion
for ICANN. To the extent possible, when there is dissent, the goal
should (IMO) be to capture the disagreement as succinctly as possible.
> Hopefully this analysis will aid us in developing real procedures and
> methods for assuring that all stakeholders have a voice, that openness and
> accountability are central to the operation of the DNSO, and that capture
> and blockage are not possible.
We might also hope for a little more accuracy and integrity in
scholarship. Your "spluttering vituperations" remark gave little
hope for objectivity; your "analysis" confirms those fears.
Obviously you cherry-picked the document for phrases that fit your
preconceptions, and ignored phrases that didn't; you ignore the fact
that the document is explicitly high level; you pile hypothetical on
top of hypothetical, and then say: "Looky here: If these n admittedly
unlikely conditions occur, we could have a problem", all the while
ignoring the layer upon layer of safeguards that are built into the
whole structure.
--
Kent Crispin, PAB Chair "Do good, and you'll be
[EMAIL PROTECTED] lonesome." -- Mark Twain
