[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [wg-c] Important -- voting on WG report



I support the report.

Josh

> -----Original Message-----
> From: owner-wg-c@dnso.org [mailto:owner-wg-c@dnso.org]On Behalf Of
> Jonathan Weinberg
> Sent: Saturday, March 18, 2000 9:20 PM
> To: wg-c@dnso.org
> Subject: [wg-c] Important -- voting on WG report
>
>
> 	 A list member has asked me to post instructions for voting
> on our report
> to the Names Council.  In order to vote, simply post a message to the list
> stating that you are voting, either "yes" or "no."  (If you just send your
> vote to me personally, I'll count it.  But my preference is that votes be
> sent to the list, so that any list member can tally up the votes should he
> or she choose to.)  The voting deadline, as modified yesterday, is 3 a.m.
> UTC (10  p.m. US Eastern, 7 pm US Pacific) on Monday night /Tuesday
> morning.   With apologies for the bandwidth, I'm attaching a copy of the
> report below.
>
> 	I want to urge everyone in the strongest of terms to cast
> votes on this
> report.  My original view was that we didn't need to vote on the report at
> all -- that it was sufficient that discussion on the list, in the week
> after it was first posted, turned up nobody who considered the report
> anything other than an accurate summary of our progress and conclusions.
> But the Names Council gave us an extra ten days to submit the report,
> largely so that we could schedule a vote and have that extra assurance of
> procedural regularity.  (The extra time for discussion has also given two
> people -- Petter and Anthony Lupo -- the opportunity to post messages
> indicating that they do *not*  support the report.)  Given that we've
> scheduled a vote, I think it's really important that people take advantage
> of it, to cast votes in support of the report or against it.
> Remember, the
> voting period *closes* at 3 a.m. UTC (10  p.m. US Eastern, 7 pm
> US Pacific)
> on Monday night /Tuesday morning, so there's less than 48 hours (and only
> one business day) left.  It would be really silly, and I think
> unfortunate,
> now that we've got a formal vote scheduled, if almost nobody bothered
> actually to submit a ballot.
>
> Jon
>
>
> Jonathan Weinberg
> co-chair, WG-C
> weinberg@msen.com
>
> ---------------------------
>
> Report (Part One) of
> Working Group C of the Domain Name Supporting Organization
> Internet Corporation for Assigned Names and Numbers
>
>
> 	This document is Part One of the Report of Working Group C.
>  It sets out
> the rough consensus of  the group regarding whether there should be new
> generic top-level domains (gTLDs), and if so, how quickly they should be
> added to the root as an initial matter.
>
> Introduction and summary
>
> 	Working Group C has reached rough consensus on two issues.
> The first is
> that ICANN should add new gTLDs to the root.  The second is that ICANN
> should begin the deployment of new gTLDs with an initial rollout of six to
> ten new gTLDs, followed by an evaluation period.  This report will address
> each of these issues separately.  For each of the issues, it will
> summarize
> the discussions within the working group, arguments pro and con, and
> comments received from the public.  It will then briefly summarize the
> ongoing work of the group.
>
> Procedural and outreach history
>
> 	The Names Council approved the charter of Working Group C
> on June 25,
> 1999, and named Javier Sola (Business constituency) as its chair.  On July
> 29, the working group members elected Jonathan Weinberg co-chair.  The
> working group includes extensive representation from each of the
> constituencies.  It is open to anyone who wishes to join, and
> currently has
> about 140 members, many of whom are inactive. (For most of the life of the
> working group, no NSI representative participated.  When WG-C's co-chair
> solicited greater participation from the Registry constituency, Don Telage
> explained that NSI had chosen not to involve itself in the WG-C process.
> That representational gap has been filled now that Roger Cochetti and Tony
> Rutkowski, WG-C members from the start, have joined NSI in senior
> policymaking capacities.)
>
> 	On October 23, 1999, the Working Group released its Interim
> Report.  That
> report described the issues on which the Working Group had reached rough
> consensus to date.  It also included seven "position papers," setting out
> alternative scenarios for the introduction of new gTLDs.  Those position
> papers usefully illustrate alternate approaches to expanding the name
> space, and address a broader range of issues than does this Report; they
> are available at
> <http://www.dnso.org/dnso/notes/19991023.NCwgc-report.html>.
>
> 	On November 23, 1999, the Names Council formally requested
> public comment
> on the Interim Report.  This call for comments was publicized on a variety
> of mailing lists maintained by the DNSO, including ga-announce, ga, and
> liaison7c (which includes the constituency secretariats).  In addition,
> WG-C's co-chair spoke at the meetings of most of the constituencies at the
> Los Angeles ICANN meeting, and urged constituency members to file
> comments.
> Nearly 300 comments were filed in response to the interim report.  They
> included responses from leading members of all of the constituencies but
> two - the record does not include comments from the ccTLD or Registry
> constituencies (although ccTLD members participated in the
> discussions that
> led to the Interim Report, and WG-C's co-chair expressly solicited the
> comments of both of those groups).
>
> 	The initial draft of this report was circulated to the
> working group on
> March 2, 2000, and the report was presented to the Names Council on March
> 8.  The working group approved this revised version of the report
> in a vote
> that closed on March 20.
>
>
> Issue One - Should There Be New gTLDs?
>
> Discussions within the working group
>
> 	The working group quickly -- by mid-July, 1999 -- reached
> consensus that
> there should be new global top-level domains.  There was very little
> dissent from this position.
>
> Arguments supporting the consensus position
>
> 	Expanding the number of TLDs will increase consumer choice,
> and create
> opportunities for entities that have been shut out under the current name
> structure.  Today, .com stands astride the name space: it has more
> registrations than all other top-level domain names combined, and is ten
> times the size of the largest ccTLD.  Yet it has become nearly impossible
> to register a new simple domain name there: Almost a year ago, in April
> 1999, a survey found that of 25,500 standard English-language dictionary
> words, only 1,760 were free in the .com domain.
>
> 	This situation is undesirable.  It requires companies to register
> increasingly unwieldy domain names for themselves, and is inflating the
> value of the secondary (speculators') market in .com domain
> names. Existing
> second-level domain names under the .com TLD routinely change hands for
> enormously inflated prices. These are legitimate trades of ordinary,
> untrademarked words; their high prices reflect the artificial scarcity of
> common names in existing gTLDs, and the premium on .com names in
> particular. The inflated value of the speculators' market imposes
> additional costs on businesses making defensive registrations of
> domain names.
>
> 	Companies that currently have a domain name in the form of
> <www.companyname.com> have an extremely important marketing and
> name-recognition tool.  They have an advantage over all other companies
> that do not have addresses in that form, because the companyname.com firms
> are the ones that consumers, surfing the Net, will be able to find most
> easily.  If the name space is expanded, companies will be able to get
> easy-to-remember domain names more easily, and the entry barriers to
> successful participation in electronic commerce will be lowered.  Addition
> of new gTLDs will allow different companies to have the same second-level
> domain name in different TLDs.  Those businesses will have to
> compete based
> on price, quality and service, rather than on the happenstance of which
> company locked up the most desirable domain name first.
>
> 	Similarly, addition of new gTLDs could enlarge
> noncommercial name space,
> and allow the creation of top-level domains designed to serve
> noncommercial
> goals.  One proposal made in WG-C, widely applauded in the public
> comments,
> advocated the creation of a new top-level domain to be operated by North
> American indigenous peoples.  Other examples are easy to imagine.
>
> 	Creation of new generic top-level domains can be beneficial in other
> respects.
>  One proposal before WG-C, with significant support, urges the creation of
> multiple registries, each capable of managing registrations for multiple
> TLDs, so as to eliminate the single point of failure for the registration
> process.  Under this view, multiple new gTLDs are necessary to support the
> multiple registries needed for stability.
>
> 	Adding new gTLDs to the root, finally, is an important part
> of ICANN's
> mandate.  ICANN was created because the institutions that preceded it were
> unable to resolve the intense political and economic conflicts created by
> demand for new top-level domain names. The U.S. Department of Commerce's
> White Paper saw the establishment of policy "for determining the
> circumstances under which new TLDs are added to the root system" as one of
> ICANN's fundamental goals.
>
> Arguments opposing the consensus position
>
> 	Three arguments were made in WG-C that cut against the
> addition of new
> gTLDs.  First, some working group members suggested that the
> perceived need
> for new gTLDs was illusory.  Public commenters raising this issue included
> Bell Atlantic and Marilyn Cade.
>
> 	Second, some working group members suggested that an increase in the
> number of top-level domains could confuse consumers, because it would be
> harder for consumers to keep in mind and remember a larger set of
> top-level
> domains.  Accordingly, any increase in the number of new gTLDs should be
> cautious.  Notwithstanding requests, though, no working group member
> offered studies or other evidence backing up this view.
>
> 	Finally, some working group members raised trademark
> policing concerns:
> Expansion of the domain space will create additional opportunities for the
> registration of domain names that are confusingly similar to existing
> trademarks.  It will present a risk that bad actors will seek to confuse
> consumers by registering SLD strings identical to those registered by
> others in other TLDs.  It will likely increase trademark owners' policing
> costs and the costs of defensive registrations.
>
> 	The relationship between domain names and trademark rights
> presents an
> important and difficult issue, and is appropriately addressed by registry
> data maintenance requirements, dispute resolution mechanisms such as the
> UDRP, and any other device that ICANN may choose to adopt, as well as by
> national legislation. Trademark owners' concerns in this regard are
> important ones, and not to be overlooked.  In public comments on the
> Interim Report, a substantial number of commenters urged that deployment
> should be delayed until after implementation of the uniform dispute
> resolution procedure, improved domain name registration procedures, and
> adoption of a system for protecting famous marks.  They included, among
> others, Jonathan Cohen (then an NC member, IPC), Dr. Victoria Carrington,
> AOL, British Telecom, Disney, INTA, Nintendo of America and Time Warner.
> Steven Metalitz expressed a similar view: "New gTLD's should be
> inaugurated
> only when, and to the extent that, established and proven
> procedures are in
> place in the existing gTLD's to improve the quality and accessibility  of
> registrant contact data, as well as satisfactory dispute resolution
> procedures."  The comments of the WG-C Rapporteur of the Business &
> Commercial constituency urged, on behalf of the constituency, that
> "business requirements such as the effective implementation of
> the UDRP and
> international business practices such as jurisdictional domains"should be
> addressed satisfactorily before new gTLDs are deployed.  The Software and
> Information Industry Association noted its support for adding new gTLDs,
> but only after the creation of a robust, responsive whois system.
>
> 	Other commenters, by contrast, do not believe that trademark-related
> concerns justify delay in the introduction of new gTLDs.  These included
> Hirofumi Hotta (NC member, ISPCPC) (emphasizing that discussion of
> famous-mark protection should not delay the gTLD rollout), Kathryn Kleiman
> (NC member, NCDNHC), Michael Schneider (NC member, ISPCPC), Computer
> Professionals for Social Responsibility, Melbourne IT, AXISNET (Peruvian
> Association of Users and ISPs), the United States Small Business
> Administration's Office of Advocacy, Register.com, InterWorking Labs,
> Tucows.com, InterAccess Company and PSI-Japan.    Raul Echeberria (then an
> NC member, NCDNHC) filed comments urging that the establishment of new
> gTLDs was important and positive, but that rules should be
> devised to avoid
> massive speculative purchases of domains in the new TLDs, or trademark
> holders simply duplicating their existing domains.
>
> 	Within the working group, the argument that ICANN should impose
> substantial delays on the initial deployment of new gTLDs in the interest
> of adopting or perfecting trademark- protective mechanisms won little
> support except from Intellectual Property constituency members.
>
> Public comments
>
> 	The discussion above canvasses many of the public comments
> received.  By
> far the largest set of comments, however, addressed a specific
> implementation of the principles discussed above.  Nearly 180
> commenters (a
> majority of the comments filed) supported the creation of a particular
> proposed new domain: .NAA, proposed as a new gTLD to be run by North
> American indigenous peoples.
>
>
> Issue Two - What Should be the Nature of the Initial Rollout?
>
> Discussions within the working group
>
> 	In working group discussions, members of the working group initially
> expressed sharply varying positions on the nature of the initial rollout.
> Some working group members urged that ICANN should immediately
> announce its
> intention to authorize hundreds of new gTLDs over the course of the next
> few years.  While ICANN might interrupt that process if it
> observed serious
> problems with the rollout, the presumption would be in favor of deployment
> to the limits of the technically feasible and operationally stable.  If
> ICANN simply deployed a small number of new gTLDs with no
> commitment to add
> more, they argued, the public would have to make registration decisions
> based on the possibility that the small number of new gTLDs would be the
> only options.  This would give the new registries oligopoly power and the
> ability to earn greater-than-competitive profits; it would encourage
> pre-emptive and speculative registrations based on the possibility of
> continued artificial scarcity.  By contrast, they urged, an ICANN decision
> to deploy a large number of gTLDs would enable competition and a level
> playing field: If ICANN announced an intention to add hundreds of
> new gTLDs
> over a three-year period, no new registry could exercise market
> power based
> on the prospect of a continued artificial scarcity of names.
>
> 	Other working group members took the opposite approach.
> New gTLDs, they
> urged, could seriously aggravate the problems facing trademark
> rightsholders in the existing domain name space.  Accordingly, they urged,
> new gTLDs should be introduced only slowly and in a controlled manner, and
> only after effective trademark protection mechanisms had been implemented
> and shown to be effective.
>
> 	A third set of working group members took still another
> approach.  In the
> long term, they stated, it would be desirable for ICANN to allow the
> deployment of new gTLDs to the limits of the technically feasible and
> operationally stable.  As a short-term matter, however, the immediate
> deployment of hundreds of new TLDs would not be prudent.  The
> operationally
> safer course, rather, should be to deploy a smaller number, and to follow
> that deployment with an evaluation period during which the Internet
> community could assess the initial deployment.  ICANN would go on
> to deploy
> additional TLDs if no serious problems arose in the initial rollout.
>
> 	The proposal that ICANN start by deploying six to ten new
> TLDs, followed
> by an evaluation period, was crafted as a compromise position to
> bridge the
> gap separating the three groups, and to enable a rough consensus
> to form in
> the middle ground.
>
> 	In September 1999, the WG-C co-chairs made the
> determination that the
> working group had reached rough consensus supporting the compromise
> position.  Because there had been no formal consensus call, though, the
> working group held a vote in December 1999 to reaffirm that consensus.
> Following the lead of Working Group B, the working group determined in
> advance that a two-thirds margin would constitute adequate evidence of
> rough consensus.  The vote reaffirmed the "six to ten, followed by an
> evaluation period" compromise position as the rough consensus of the
> working group, by a margin of 44 to 20.  (A substantial number of working
> group members did not cast votes.  In addition, some working
> group members,
> having been solicited to vote, sent messages to the list explaining that
> they were declining to take a position at that time, and listed themselves
> as consequently abstaining.  Neither the non-voters nor the
> abstainers were
> counted in figuring the two-thirds majority.)
>
> Arguments supporting the consensus position
>
> 	The "six to ten, followed by an evaluation period"
> consensus position has
> the advantage of being a compromise proposal supported by a wide range of
> working group members.  In a bottom-up, consensus-driven organization,
> broad agreement on a policy path is valuable for its own sake.  The sense
> of the bulk of the working group is that this proposal strikes an
> appropriate balance between slower, contingent deployment of new gTLDs and
> faster, more nearly certain, deployment.
>
> Arguments opposing the consensus position
>
> 	Three arguments were made in the working group against the
> proposal.  The
> first was that the contemplated initial deployment was too large; rather,
> some WG members urged, it would be appropriate, following the
> implementation of effective intellectual property protections,
> for ICANN to
> roll out no more than two or three new gTLDs.  The second
> argument was that
> the contemplated initial deployment was too *small*: that, as detailed
> above, a deployment of only six to ten, without an upfront commitment to
> roll out many more, will be a half-measure that would grant
> oligopoly power
> to the lucky registries selected for the initial rollout.
>
> 	Commenters expressed agreement with each of these positions:  Bell
> Atlantic and Marilyn Cade supported the introduction of just a single new
> gTLD at the outset; British Telecom and Time Warner urged the initial
> rollout of only a few.  The submission of the WG-C Rapporteur of the
> Business & Commercial constituency, on behalf of that constituency, urged
> that ICANN should start with a "very small number" of new gTLDs.  Other
> commenters, including Jonathan Cohen (then an NC member, IPC),
> Dr. Victoria
> Carrington, AOL, Disney and Nintendo of America, generally endorsed the
> statement that the introduction of new gTLDs should be slow and
> controlled,
> and should incorporate an evaluation period.
>
> 	By contrast, Hirofumi Hotta (NC member, ISPCPC), Kathryn Kleiman (NC
> member, NCDNHC), Michael Schneider (NC member, ISPCPC), Computer
> Professionals for Social Responsibility, AXISNET, InterWorking Labs,
> Tucows.com and InterAccess Company supported the  position that ICANN
> should, at the outset, announce a schedule for introducing hundreds of new
> TLDs.  The Office of Advocacy, U.S. Small Business Administration
> concluded
> that ICANN should start with a limited introduction of new TLDs
> followed by
> an evaluation period, but that ICANN should announce in advance that it
> would continue with a steady introduction of additional TLDs so long as
> pre-announced technical criteria were met.    Raul Echeberria (then an NC
> member, NCDNHC) stated that ICANN should evaluate the operation and market
> acceptance of the TLDs added in the initial rollout before creating or
> announcing more.  Melbourne IT, PSI-Japan and Register.com all supported
> the compromise position of an initial rollout of six to ten new gTLDs
> followed by an evaluation period.
>
> 	Most WG members concluded that a deployment of fewer than
> 6-10 would not
> give ICANN the information that it would need to make sensible later
> decisions, and was smaller than caution dictated.  At the same time, most
> WG-C members felt that an initial commitment to many more than 6-10 would
> not be operationally sound.  Until we see the consequences for the domain
> name space of adding new gTLDs, there are advantages to a more circumspect
> path.
>
> 	The final objection raised was that the consensus agreement
> answered the
> wrong question: The working group, said some, should not be addressing the
> number of new gTLDs at all before resolving such issues as whether the new
> top-level domains should be general-purpose (like .com), special-purpose,
> or some combination of the two.  These issues are discussed in this report
> under the heading of "ongoing work," and certainly it would not have been
> inappropriate for the WG to have sought to reach conclusions on those
> matters before discussing Issue Two.  But most members of the
> working group
> concluded that the size of the initial rollout could and should be
> addressed first, before resolving less tractable issues.
>
> Ongoing work
>
>         Remaining questions before the working group include how the new
> gTLDs deployed in the initial rollout, and their associated registries,
> should be selected.  In initial discussion and straw polls on this issue,
> working group members fell into several camps.  One group urged that ICANN
> should first select new gTLD strings, and only then call for applications
> from registries wishing to operate those TLDs.  A second group urged that
> ICANN should select new gTLD registries on the basis of objective
> criteria,
> and allow the registries to choose their own gTLDs in response to market
> considerations.  A third group suggested that registries should apply
> describing their proposed gTLDs, and that an ICANN body or process would
> then make selections taking into account the characteristics of both the
> registry and its proposed gTLD. The working group considered the third
> option, viewed as a possible middle ground, as a consensus call, relating
> only to the initial rollout of six to ten new gTLDs.
>
> 	Thirteen "yes" votes were cast in that consensus call, and five "no"
> votes.  While the votes cast were markedly in favor, it's the view of the
> co-chair that a finding of rough consensus, at this date, would be
> premature.  Only a small number of people voted:  In contrast to the 64
> votes cast on the consensus call relating to the size of the initial
> deployment (well over half of the membership of the WG at the time), only
> eighteen people chose to cast a vote on this matter.  Even some active
> participants in the discussion of the consensus call did not cast votes.
> This makes the vote less reliable as a gauge of the views of the working
> group as a whole.  Other factors making it difficult to draw an
> unambiguous
> consensus from the vote include the facts that some of those who voted
> "yes" added additional caveats conditioning their support, and that voters
> may have had varying understandings as to how the term "registry" in the
> consensus call should be understood, and what an application would entail.
> ("No" voters urged both that the consensus proposal would give too much
> discretionary authority to ICANN, and that it would preclude ICANN from
> considering gTLD proposals that came from entities other than would-be
> registries.)
>
> 	It appears to be the sense of the working group, among both
> supporters and
> opponents of the consensus call, that ICANN's selection process should be
> procedurally regular and guided by pre-announced selection criteria.
> Further, it appears to be the sense of the working group that the
> namespace
> should have room for both limited-purpose gTLDs (which have a charter that
> substantially limits who can register there) and open, general-purpose
> gTLDs.  The working group extensively discussed a set of eight principles,
> drafted by Philip Sheppard (NC member, Business) and Kathryn Kleiman (NC
> member, NCDNHC), against which applications for new TLDs might be judged.
> The proposed principles, in their current iteration, incorporate the
> keywords Certainty, Honesty, Differentiation, Competition, Diversity,
> Semantics, Multiplicity and Simplicity.  However, the working
> group has not
> so far achieved a consensus on the content or usefulness of the
> principles.
>
> Conclusion
>
> 	In summary, Working Group C has reached rough consensus on
> two issues. The
> first is that ICANN should add new gTLDs to the root.  The second is that
> ICANN should begin the deployment of new gTLDs with an initial rollout of
> six to ten new gTLDs, followed by an evaluation period.  The working group
> is continuing to address other issues, including the mechanism through
> which new gTLDs and registries should be selected.  While there is
> sentiment within the working group for the compromise position that
> registries should apply describing their proposed gTLDs, and that an ICANN
> body or process should make selections taking into account the
> characteristics of both the registries and their proposed gTLDs, a finding
> of rough consensus on this point would be premature.
>
> --------------
>
> A detailed summary of the public comments on the working group's Oct. 23,
> 1999 interim report is available at
> <http://www.dnso.org/wgroups/wg-c/Arc01/msg00490.html>.