Re: [dnso.discuss] drj response to Kent -- long

[jeff Williams <jwkckid1@ix.netcom.com>]

David and all,

  Pretty good detailed breakdown of two of the current DNSO drafts being
considered.  There is however one area the we (INEGroup) do disagree
with
in the extreme. Consider the following:

 David you state, "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." 
Although
this has some TRUTH in it it is far form the breadth of LACK of support
that the
"Paris Draft" in it's current form given that our (INEGroup) membership
is
NOT in support of either the "Paris Draft" or the BMW/WMB Draft.  It is
also
yet to be known, or at least published, what the total number of
supporters the
AIP or the the AIP and the ORSC combined enjoy's presently.  This is not
so with the INEGroup.  Hence we challenge this contention on that basis.

David R. Johnson wrote:

> 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.
>
> - snip WBM draft comparison fo brevity -
>
> David Johnson
>
> ---
> You are subscribed to dnso.discuss as: [jwkckid1@ix.netcom.com]
> To unsubscribe, change your list options, or view archives go to:
> http://lists.association.org/cgi-bin/lyris.pl?enter=dnso.discuss
> This list system donated by Lyris Technologies (http://www.lyris.com/).

Regards,
--
Jeffrey A. Williams
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208