David,
Well done. I hope that you stick around to deal with the various
spluttering vituperations that are bound to emerge...
Antony
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David
> R. Johnson
> Sent: Saturday, February 13, 1999 5:27 PM
> To: [EMAIL PROTECTED]; DNSO list
> Subject: [IFWP] drj response to Kent -- long
>
>
> Since Kent invokes my comments during the conference call, I feel
> compelled to
> respond.
> The following are my own views only.
> They are premised on the assumption that we should be considering
> the merits of
> the drafts, not claiming levels of support from organizations
> that have various
> large numbers of members and customers who have never heard of
> these issues, much
> less debating the "lineage" of drafts that have all obviously
> evolved from years
> of collective thinking about the issues.
> The following "Paris FAQ" and "Critique of the BMW draft" are
> meant as a first
> cut at articulating key differences.
> drj
> --------
> An Analysis of the Paris Draft proposal for establishment of a Domain Name
> Supporting Organization within ICANN
>
> Why does the Paris Draft call for a DNSO to be an integral part of ICANN?
>
> The DNSO is an advisory body that will be the most significant source of
> proposed ICANN policies regarding the domain name system. It does
> not need and
> should not have a role in fund-raising or an elaborate staff. If it were a
> separate organization, it would require a separate board and
> elaborate fiscal
> controls, and would likely develop interests and goals
> conflicting with those of
> ICANN. No contractual mechanism could provide adequate assurances that its
> procedures would comply with the safeguards established in
> ICANN's Articles and
> ByLaws, because it is not realistic to expect that ICANN could threaten to
> terminate a contract with its primary advisory body. There is no
> assurance that
> the needed parties would join a separate DNSO or that a separate
> DNSO would fully
> and fairly represent all of those who demand and need to provide input.
> Deliberations within the DNSO will be less vulnerable to
> challenge if they take
> place under the umbrella of governmental endorsements of the
> ICANN structure. In
> short, establishment of the DNSO by means of an amendment to
> ICANN's ByLaws
> provides the simplest route to a structure that will serve the
> goals and abide by
> the principles long debated in the course of creation of the
> ICANN structure.
>
> Why does the Paris Draft provide for self-organizing non-overlapping
> constituencies to select an administrative/facilitative (not a
> policy-adopting)
> Names Council?
>
> The Paris Draft establishes a Names Council that administers and
> facilitates the
> development of broad-based consensus. If the Names Council were
> defined as the
> decision-making body, with a limited number of seats, then
> interested parties
> would seek disproportionate representation in selecting the
> occupants of those
> seats. No pre-defined list of constituencies can adjust,
> flexibly, over time to
> reflect this dynamic medium. In contrast, selection of a
> steering committee by
> constituencies representing a minimum percentage (5%) of an open
> membership will
> assure effective leadership over a long period of time. By providing for
> non-overlapping constituencies, and allocating membership to both
> individuals and
> organizations, the Paris Draft makes sure all voices will be
> heard and given
> equal weight in determining whether there is a real consensus in
> the General
> Assembly. Constituencies will behave more like political parties,
> and less like
> "elected representatives" making top down decisions. This will
> ensure that those
> "steering" the research and review processes reach out to include
> all interested
> parties and are not captured by those who can "qualify" as
> electors for the most
> seats. Registries (and, potentially, registrars) are assured a role as a
> constituency without regard to the five percent rule because they
> would not
> likely be able to meet that test as the membership grows in size
> and because
> their participation is vital to assure that proposed policies can
> be implemented
> by means of binding contracts between ICANN and the registries.
>
> Why does the Paris Draft provide for an implementation preview by
> registries?
>
> ICANN has no governmental power to impose policies on registries
> against their
> will. If it is to adopt effective, equitable policies, it must enter into
> contracts with the registries. The implementation preview is designed to
> establish a basis for contracts that bind the registries to
> implement policies
> with which they may individually disagree, provided that most
> other registries
> are prepared to support and implement those policies. This
> provision will make
> ICANN a standard setting body with some teeth, but also prevent
> the embarrassment
> and futility of policy "decrees" that cannot be broadly implemented. The
> implementation preview does not apply to policies, such as adding
> new TLDs to the
> ICANN root, that do not need to be implemented by the registries.
> It is not a
> "veto" power by a particular constituency -- it doesn't prevent
> communication to
> the ICANN Board of the fact (if such were the case) that there is
> support among
> other constituencies for a policy that the registries oppose. It simply
> recognizes the fact that ICANN is not a governmental body and must, to be
> effective, implement its proposed policies by contract. All open
> TLDs should be
> equally subject to consensus policies, if there really is
> consensus for policies
> that change the business practices of registries or contractual
> relationships of
> registries with third parties. Most registries will not agree to
> contracts that
> require compliance with any and all policies ICANN may decide to
> impose. Thus,
> the best mechanism for assuring enforceability of policies
> developed by the DNSO
> would be for ICANN promptly to seek to enter into contracts with
> registries that
> commit them to implement policies that both have the support of a
> broad consensus
> of DNSO members and that have passed the suggested implementation preview
> procedure.
>
> Will the proposed DNSO structure be able to take effective action?
>
> The major argument for a "strong" Names Council elected by specified
> "constituencies" is that this will create a small group of
> "representatives" who
> can take prompt action. In contrast, the research and
> ratification processes
> defined in the Paris Draft tends to assure that proposals will
> not be forwarded
> without strong and widespread support among a large group of
> interested DNSO
> members. Any evaluation of these competing models depends on
> one's view of the
> consequences of inaction and, alternatively, of precipitate
> action. If a broad
> consensus and registry agreement are not present, rapid action by
> a Name Council
> (or ICANN) could well be destabilizing. The default condition,
> now, for the net
> is that diverse local players with a substantial stake in growing their
> businesses will take actions that benefit their customers and
> users. With the
> possible exception of artificial barriers to the addition of new
> TLDs to the
> root, which are imposed by the US Government, not the registries,
> there is no
> barrier to effective decentralized action to establish good dns policy.
> Registries and registrars establish sound policies every day and
> compete with one
> another for customers. And, with the planned opening of the competitive
> registration system for .com, .net and .org, there is substantial
> reason to
> believe there will be even more effective competitive forces to
> constrain any
> suboptimal decisions by registries and registrars. In contrast, a
> small group of
> "representatives" that purported to speak for all stakeholders
> and decided to
> "adopt" policies applicable to all registries, registrars and registrants,
> without their expressed support, could produce substantial and effective
> opposition. In short, there is little need for rapid
> "regulatory" action by a
> small, closed group. And those decisions that are taken on the basis of
> widespread membership support (by means of the General Assembly
> ratification and
> the implementation preview established in the Paris Draft) will
> be more likely to
> be effective.
>
> How does the Paris Draft prevent capture or disruption by
> minority interests?
>
> An open membership of all those who choose to join ICANN cannot
> be captured
> (unless the ICANN were to establish barriers to entry in its own
> membership, a
> course of action contrary to the requirements of its Articles and
> ByLaws and to
> the White Paper). The Paris Draft deliberately ties the two
> memberships together,
> both to avoid complexity and to encourage ICANN to adopt an open
> membership
> model. The Name Council cannot be captured because self-defining
> constituencies,
> meeting objective criteria and obtaining support from a minimum
> percentage of the
> DNSO membership can elect their share of seats. Even if a Names
> Council were to
> show some bias, the Paris Draft structure also prevents capture
> by requiring
> ratification by two thirds of the open General Assembly before a
> proposed policy
> may be forwarded to ICANN -- and by requiring transmission of the
> full research
> record, including expressions of dissent, to the ICANN Board. The research
> process is required to be open for comments and participation by
> a wide range of
> interested parties. If the Names Council were to attempt to prevent the
> commencement of consideration of a particular issue, then the
> process may be
> started either by petition of 5% of the General Assembly members
> or by only three
> of the potential 21 Names Council members. Fair Hearing processes
> are designed to
> give every disaffected party a forum to present its case -- but
> procedures can be
> developed for summary disposition of frivolous cases. Under the
> Paris Draft, the
> role of the Names Council is to seek consensus among impacted
> parties -- and that
> inherently requires that they act to prevent capture and avoid
> disruption by
> minorities.
>
> Who supports the Paris Draft and where did it come from?
>
> The Paris Draft derives from multiple prior efforts of a very
> large number of
> parties involved in the discussion of possible DNSO structures.
> It was drafted by
> a group involving representatives of the ORSC, AIP and registries
> representing
> the vast majority of registrations from around the world. Its
> language includes
> suggestions that have come from business interests, trademark interests,
> registrars, end user groups, and scholars. Sponsoring
> organizations are now
> soliciting additional endorsements. Ultimately, this draft
> belongs to each and
> every participant in ICANN and the resulting DNSO. Everyone
> interested in domain
> name policy is, or ought to be, eligible to become a member of
> the DNSO. Since
> DNSO is an advisory body of ICANN, only the ICANN Board can take
> the final action
> (amendment of the ByLaws) to make it a reality. It is a misnomer
> to characterize
> this as a process involving "applications" to "become the DNSO"
> -- because no
> effective and safe DNSO could be established other than as a
> functioning subpart
> of the ICANN membership. It is clear that the structure of the DNSO raises
> uncomfortable questions concerning the membership of ICANN itself
> (will that be
> open or closed?, will it allow individual memberships?, will it
> be conditioned on
> payment of unreasonable and inequitable fees?), about the
> relationship of ICANN
> to registries and registrars (will ICANN policies apply to all
> open TLDs?, will
> all registries agree to implement the policies that evolve from the ICANN
> process?), about the relationship between ICANN and governments
> (will governments
> allow ccTLD registries to enter into a contract with ICANN?, will
> governments
> allow ccTLD registries to participate in the DNSO process?), and
> about the source
> and nature of ICANN's own prerogatives and legitimacy. If the
> DNSO is to succeed,
> those questions must be answered to the satisfaction of all who wish to
> participate in the evolution of -- and who must implement --
> domain name policy.
> The fact that substantial numbers of registries have supported
> the Paris Draft is
> a good sign that its structures can lead to policies that can be
> implemented. The
> fact that it has an open membership, not carved up into
> artificial or inflexible
> constituencies, deprives any holdout opponents of the argument
> that they are not
> "fairly" represented in its processes. The fact that it calls for
> a facilitative
> Names Council, and for ratification of consensus proposals by the General
> Assembly, deprives any opponents of an argument that the policies
> it forwards
> don't represent a true consensus of the interested community. The
> fact that it
> requires an implementation preview lays the groundwork for broad and fair
> application of the policies that are developed. In short, while
> the Paris Draft
> represents only a process for potential evolution of new dns
> policies, it holds
> out the hope that the end product of that process will be widely
> supported and
> implementable -- avoiding destabilizing "top down" pronouncements by
> self-appointed regulators and embodying the best aspects of the
> "rough consensus
> and running code" methodology that has made the internet so
> successful to date.
>
>
>
> ---------
> February 13, 1999
>
> A critique of the BMW draft
>
> By: David R. Johnson
>
> Overall, the BMW draft differs from the Paris draft by (1)
> rejecting an open
> membership for the DNSO, (2) rejecting the need to assure that
> proposed policies
> can be implemented and the opportunity to create the basis for
> contracts that
> require all registries, despite their individual opposition, to
> accept policies
> supported by 3/4ths of the registries under contract with ICANN,
> (by means of
> the implementation preview), (3) vesting decision-making power
> regarding proposed
> policies in the Names Council rather than a General Assembly of
> DNSO members, (4)
> selecting the Names Council and ICANN Board members representing
> the DNSO through
> pre-defined constituencies (rather than letting DNSO members decide which
> constituency best represents their interests, (5) allowing
> particular members to
> join multiple constituencies (thereby granting large companies
> with diverse
> interests disproportionate say in the nomination process).
>
> The most fundamental differences between the BMW draft and the Paris draft
> appears to stem from differing views regarding the role of the
> DNSO and the
> consequences of any lack of broad consensus on particular
> proposed policies.
> Under the BMW approach, the absence of consensus is viewed as a
> problem that
> should be overcome by executive action of constituency representatives. In
> contrast, the Paris draft seeks an accurate reading of the extent
> of consensus
> among a broad membership -- and it contemplates that, in the absence of
> consensus, policies and practices of the dns system should be
> made by diverse
> local actors, all of whom have a stake in adopting policies that
> best serve their
> members and customers. If the DNSO is viewed as an "expert" body,
> as the BMW
> draft appears to assume, then the lack of widespread involvement by those
> impacted by policies (such as domain name holders) is not seen as
> a problem. In
> contrast, if one basic role of the DNSO is to give ICANN an accurate
> understanding of whether those impacted by policies will view
> them as acceptable,
> either on the merits or because they have had an effective means
> of participating
> in the policy development, then open membership and General
> Assembly voting on
> key questions become much more important to the DNSO's success.
> Are we creating a
> top down "expert" regulatory body or a "bottom up" standard
> setting body for a
> diverse industry and community? That is the question posed by the
> differences in
> these drafts.
>
> The drafts differ in their approaches to achieving the
> flexibility necessary for
> this dynamic medium. The BMW proposal seeks flexibility by
> reciting general
> principles and leaving many details regarding process to be
> worked out later by
> "self-organizing" constituencies and the Names Council they
> select. In contrast,
> the Paris Draft spells out specific procedures for policy
> formulation and allows
> flexibility by means of encouraging members to form and join
> constituencies
> representing at least some minimum percentage of the membership.
> (In the Paris
> draft, each member may join only one constituency, so multiple
> inputs by large
> companies are avoided and there is reasonable assurance that most
> members will be
> able and will choose to play a role in selecting the Names
> Council.) By selecting
> a particular set of named constituencies, the BMW draft seeks to balance
> interests represented on an executive Names Council in a manner
> that, even with
> our current understanding of the array of impacted interests,
> leaves out or
> relegates to minority status many types of participants who have
> a stake in the
> policies ICANN will make. A flexible constituency model will,
> instead, both allow
> and require each impacted party to choose which group best represents its
> perspective.
>
> The following comments relate to particular provisions of the BMW draft:
>
>
> Introduction. "The undersigned hereby commit to fulfill the
> undertakings and
> policies set forth in this application"
>
> The mechanism for assuring that selected DNSO processes are
> implemented should
> be the adoption of provisions in ICANN's Bylaws. No set of
> private parties can
> bind the diverse constituencies whose voices need to be heard in
> determining
> whether there is broad consensus for proposed policies that will impact
> participants in the domain name system. The BMW draft is
> ambivalent regarding
> whether the DNSO should be a separate organization with members,
> funding and
> staff independent from those of ICANN itself. The ICANN board
> should resolve this
> ambiguity by forming the DNSO as an advisory body within ICANN,
> subject to the
> many protective provisions of the ICANN Articles and Bylaws. That
> will eliminate
> the need for a separate group, which may not speak for the enumerated
> constituencies, and which surely will not speak for all impacted
> constituencies,
> to purport to speak for an as yet unformed membership.
>
> I.A. "The DNSO membership shall consist of constituencies�"
>
> This provision prevents any impacted stakeholder from joining the
> DNSO other than
> through a constituency. It will prevent flexible adaptation of
> the Names Council
> and effectively eliminates the voice of minority interests within
> the named
> constituencies. What will be the remedy for a company or
> individual dissatisfied
> with "its" constituency? with the association or organization
> that purports to
> speak for that party? The Paris Draft provides a safety valve for
> those who don't
> agree with the actions of their "representatives" and care enough
> to represent
> themselves.
>
> I.A. "Each constituency shall self-organize and determine its own
> criteria for
> membership."
>
> There is no clear need for criteria for membership in a
> constituency other than
> membership in the DNSO (which should be a subset of membership in
> ICANN) and the
> willingness to exercise one's vote for a representative on the
> Names Council
> through that particular constituency. The BMW does not and cannot
> explain what
> would happen if the named constituencies do not "self-organize"
> or if they face
> substantial internal disagreements. The Paris draft automatically handles
> intra-constituency conflict by allowing groups of DNSO members to reallign
> themselves over time. The BMW proposal creates a risk that
> criteria developed for
> membership will be exclusionary or unreasonable -- whereas the Paris Draft
> eliminates such criteria and self-corrects if the "leadership" of
> a particular
> constituency fail to represent the views of substantial numbers
> of constituency
> members.
>
> I.B. Membership in the Constituencies. "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."
>
> The BMW draft does not provide concrete procedures for members of
> the DNSO to
> form new constituencies. It is unreasonable to expect the initial group to
> welcome the addition of new groups that will dilute their voting
> power in a Names
> Council that is itself the source of a declaration as to whether
> a particular
> proposal is supported by "consensus". Adding words that promise
> that future
> procedures will be "fair" and "open" does not build trust,
> because the details of
> constituency formation could instead be selected now and can be
> tied to the
> decisions of members regarding who should represent their
> interests and serve as
> their voice on a Names Council that merely facilitates
> presentation of proposals
> to the membership body. A later provision contemplates the
> payment of dues to
> join a constituency, which will create a further barrier to
> participation by
> small businesses and individuals.
>
> I.B. Membership. "The constituencies are�"
>
> The BMW list of constituencies has many flaws. Businesses are
> specially called
> out, even though this category overlaps with many of the other
> categories. No
> account is taken of potential conflicts between small and large
> businesses. Even
> the non-commercial group excludes individual registrants and, indeed,
> non-commercial interests that are not registrants. The registrar
> group includes
> both true registrars (those with a contractual right to write to
> the TLD zone
> files) and resellers, even though their perspectives and
> interests may differ.
> The trademark group excludes those who oppose treating domain
> names as identical
> with trademarks, but provides no other clear "place" for the latter in the
> organization. In contrast, the Paris draft leaves selection of
> constituencies up
> to the constituents.
>
> I.C. The Names Council. Initial Names Council provisions.
>
> The BMW draft calls for creation of the first Names Council by means of a
> meeting "of all entities that have subscribed to the application
> in the form
> accepted by the Corporation." This ties participation in the DNSO
> formed by ICANN
> to required agreement with a particular proposal. This provision also
> contemplates an "assessment of fees for the start-up process" --
> creating another
> barrier to participation. It is not made clear how the
> geographic diversity
> requirements will be met, either in the initial Names Council or
> thereafter.
>
> I.D. Applications for Membership in Constituencies.
>
> The BMW requires submission of applications to "the relevant
> constituency" but
> doesn't make clear who will be able to claim to represent such
> constituency for
> purposes of accepting such applications. To whom would a
> university submit its
> application to become a member of the "Non-commercial
> registrants" group? What if
> two groups form? The answer appears to be that those who signed
> the BMW proposal
> will set themselves up, somehow, as the initial constituencies.
> But the parties
> supposedly represented by the constituencies may not agree that
> the supporters of
> the BMW draft should play this role. In contrast, under the Paris
> draft, each
> party impacted by the domain name system merely has to decide
> (1) whether to
> join the DNSO, and (2) which unique group of fellow members, if
> any, to join with
> for purposes of selecting a Names Council representative. Under
> the Paris draft
> approach, those groups that attract support from an adequate
> number of fellow
> members (or who, like registries, play particular roles defined
> with reference to
> direct or indirect contractual relationships with ICANN) will
> naturally form and
> fit into the structure. Even some delay in the formation of some
> particular
> constituencies would not interfere with effective operations,
> under the Paris
> Draft, because the General Assembly of the members has the key
> decision-making
> powers and it is possible for members to participate without
> being a member of a
> constituency.
>
> II.A. Methods for Developing Substantive Internet Policies� "�the
> Names Council
> shall make recommendations�" "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."
>
> The BMW draft uses the word "consensus" to refer to the state of
> voting within
> an 18 member board that is deemed to represent the interests of
> members. But,
> aside from the likelihood that the defined constituencies do not
> fully cover or
> adequately balance the diverse interests of the broader
> membership of impacted
> parties, there is no assurance that the votes of these
> "representatives" will
> actually reflect the state of consensus among the members
> themselves. Various
> members will have different views, held with widely differing levels of
> intensity, on different questions. There is a simple means of
> determining the
> overall level of support for a proposed policy -- submission of
> the proposal to
> the membership for a vote, as contemplated by the Paris Draft.
> The Names Council
> can play a useful role in framing questions, encouraging research
> and compromise,
> and assessing the likely reactions of the members. It (and ICANN)
> can assess the
> relative weight and importance of any dissenting opinion. But it
> cannot arrogate
> to itself the ultimate decision-making power without running
> serious risks of
> inaccurately reporting the degree to which particular policies,
> if adopted by
> ICANN, would be viewed as wise or legitimate by the many diverse
> parties who
> would be impacted. Only an open membership and General Assembly voting can
> provide a process the availability of which will disarm attacks
> against ICANN
> that claim it is a "top down" regulatory body potentially
> captured by those with
> the resources and will to seek disproportionate influence.
>
> II.B. Selecting Nominees to the Board of the Corporation.
>
> By allocating selection of the DNSO representatives to the ICANN
> Board to the
> Names Council, the BMW draft effectively gives the selection
> power to the group
> of pre-selected constituencies that can obtain half of the votes
> on the Name
> Council. That selection may well not represent an outcome that
> best reflects the
> overall views of the DNSO membership, especially if that
> membership (if not
> limited by artificial constituency constraints) were considered
> to include all
> stakeholders in the domain name system.
>
> Miscellaneous.
>
> Various provisions of the BMW draft calling for audited
> financial statements and
> DNSO self-funding will lead to additional layers of expense and
> erect barriers to
> participation by small companies and individuals. The BMW draft ends with
> reference to a decision by the "general assembly of the
> constituencies" regarding
> a "fair means of allocating membership dues among its
> membership". This provision
> contemplates the existence of a DNSO membership, but provides no
> rationale for
> restriction to the stated constituencies. If the "general assembly" of all
> members can allocate dues, why cannot it determine the state of consensus
> regarding substantive policies? Why is it necessary to collect
> dues at all, when
> the role of the DNSO is simply that of an advisory body and the
> members will
> already be expending substantial time and funds in order to
> participate? Why
> should only certain constituencies have a right to assess all
> members for dues
> money that will apparently be spent to subsidize the expenses of
> Names Council
> members that may not support the positions of the members who
> must pay such dues
> assessments?
>
> A final word on the Risks of Inaction and Capture
>
> Proponents of the BMW draft have argued that its provisions are
> needed to assure
> that some small group can take rapid action -- and that the Paris Draft
> procedures may lead to inaction. First, it is important to
> question whether
> action should be taken -- and recommendations should be made in
> the name of the
> DNSO community -- in the absence of a broad consensus that would
> manifest itself
> in the vote of a DNSO membership. In the absence of consensus,
> the domain name
> system will continue to operate. And diverse participants will
> continue to make
> decisions that best serve the needs of their customers or
> constituents. ICANN
> will continue to have the ability to seek contractual commitments from
> registries. Governments around the world will still have the
> ability to regulate
> those within their jurisdiction. There has been no showing of any
> need for rapid
> action by the DNSO on particular issues. Second, even if there
> were some issues
> as to which some parties are impatient for action, their advocacy
> should be
> channeled into the useful task of convincing others, or formulating policy
> proposals that receive widespread support, rather than towards
> the divisive goal
> of seeking to influence a small and not necessarily
> representative Names Council.
> Third, ICANN will itself have power to obtain expert opinion quickly, from
> multiple sources, and to take unilateral action to set policies
> for the root
> server operations on matters, such as the addition of new TLDs,
> that do not
> require implementation via alteration of contracts with third
> parties, in the
> event that it considers such issues to present an emergency.
> Correspondingly,
> ICANN does not have and will not obtain the power unilaterally to
> impose on third
> parties with which it contracts (such as registries) policies
> that it considers
> needed on an emergency basis but which such third parties do not
> necessarily
> consider to be "emergency" matters. Finally, the Paris Draft
> procedures would
> allow for rapid submission of consensus provisions when there really is a
> widespread consensus among the membership, as there might well be
> in the case in
> which emergency measures were really required. If two-thirds of
> the members of
> the DNSO support a proposal, the Paris Draft would move it forward as a
> recommendation, despite the opposition of some hold-outs. In
> contrast, the BMW
> draft allows any small group of individuals constituting half of
> the membership
> of the Names Council to hold up a proposal.
>
> Everyone agrees that capture is to be avoided, but there is
> disagreement on what
> mechanisms best avoid this vice. The BMW proposal creates various
> clear risks of
> capture. Each constituency will, in effect, "capture" the
> minority voices within
> the constituency (preventing their effective influence on policy) and will
> capture the entire DNSO away from those who are not admitted to
> the specified
> constituencies. If a few powerful interests gain disproportionate
> influence on
> the nomination of a relatively few Names Council board members,
> they could defy
> the will of the majority of the DNSO members. Just a few Names
> Council members
> can block action. In contrast, the open membership and General Assembly
> decision-making contemplated by the Paris Draft would be much
> more difficult to
> capture. No small group could hope to generate the required
> ratification vote,
> because any actions to sign up large numbers of "sham" members would be
> transparent and could be just as easily countered by opponents.
> The main fear of
> capture regarding the Paris Draft proposal appears to be that a
> small group could
> artificially assemble the one third vote of the General Assembly
> necessary to
> prevent ratification. But, assuming relatively low barriers to
> entry as a member
> of the DNSO, any such move could be countered by others
> (representing a more
> mainstream view) by recruiting additional participation on their
> side of the
> issues. The research committees would be selected by a Names
> Council that itself
> includes the representatives that the members themselves have selected, an
> inherently diverse group. The Paris Draft prohibits formation of
> constituencies
> defined with reference to company membership. Any large group of
> "sponsored"
> members would have to disperse into the natural constituencies of
> interested/impacted parties, lowering their proportionate impact.
> In short, there
> is a much greater risk of capture if power is concentrated into
> an executive
> Names Council (which declares "consensus" rather than testing the
> actual views of
> the membership) selected by a finite number of specified
> constituencies (which
> set their own rules for admission and may not collectively be
> inclined to admit
> new members to the club). And there is much greater opportunity
> for perceived
> legitimacy if the DNSO is open to all who care to spend the time
> and resources to
> participate -- and whose participation is direct and consequential.
>
>
> David Johnson
>
>
>
>
>
