From: owner-wg-c-digest@dnso.org (WG-C-DIGEST) To: wg-c-digest@dnso.org Subject: WG-C-DIGEST V1 #54 Reply-To: Sender: owner-wg-c-digest@dnso.org Errors-To: owner-wg-c-digest@dnso.org Precedence: bulk WG-C-DIGEST Monday, March 20 2000 Volume 01 : Number 054 ---------------------------------------------------------------------- Date: Mon, 20 Mar 2000 07:44:54 -0800 From: "Roeland M. J. Meyer" Subject: RE: [wg-c] WG-C report -- final version Perhaps, you missed the debate when it became obvious that the IP folks were gonna deadlock us unless we agreed to a more moderate stance. I agree with you, but am willing to make the expedient compromise. > -----Original Message----- > From: owner-wg-c@dnso.org [mailto:owner-wg-c@dnso.org]On Behalf Of > Philip Sheppard > Sent: Monday, March 20, 2000 1:16 AM > To: wg-c@dnso.org; Jonathan Weinberg > Subject: Re: [wg-c] WG-C report -- final version > > > Jonathan, > You have done a great job managing this process but I am > forced to vote no > to the WG C report. How many is the wrong question. Recommending an > oligopoly of 6-10 will do nothing for consumer confidence as it will > encourage warehousing and cyber squatting without the > differentiation that > is so desperately required. > Philip > > Philip Sheppard > AIM - European Brands Association > 9 av. des Gaulois B-1040 Brussels > Tel +322 736 0305 Fax +322 734 6702 > ------------------------------ Date: Mon, 20 Mar 2000 08:06:32 -0800 From: "Roeland M. J. Meyer" Subject: [wg-c] Shared TLD and shared roots? WRT IAB: The hallmark of technical absurdity is making statements which run counter to existance proofs. > There are two possible interpretations there (which is why > Dave asked for > clarification): > a) Competition can be achieved by having multiple entities > manage the same TLD (something which the IAB has stated as technically unfeasible). In spite of the problems with SRS, it can work, if run properly. It can also be scaleable, if run properly. For the most part, the SRS seems to be working, for various definitions of "working". It appears that SRS will improve. Thus, lending the lie to the infeasibility argument, of the IAB. Note that, if the IAB were to acknowlege this fact, it would also have to retract the arguments against the feasibility of multi-part root systems. For all intents and purposes, they are the same argument set. For this reason, IAB will continue its technical argument against what has already bee proven to work, and continue down the road to irrelevance. Part of what makes such a system work is adequate business process, not technical finess. Myself and others have already pointed to various proofs of shared root-zones. > b) Competition can be achieved by having multiple TLDs (each > managed as a single unit). There are no technical restrictions here either. ------------------------------ Date: Mon, 20 Mar 2000 08:11:54 -0800 From: "Mark C. Langston" Subject: Re: [wg-c] Administrivia (revision 1) For whatever reason, Eric's not including my vote on this list. I voted "yes". On Mon, Mar 20, 2000 at 08:46:39AM -0500, Eric Brunner wrote: > > 139 subscribers of list 'wg-c' (revised as of 19 Mar 2000): > 8 subscribers of list 'wg-c-digest' (revised as of 19 Mar 2000): > > The far votes Jon and I have noticed are: > Pro text: > ------------------------------------------------------------------------------ > name | paper | 8 Dec | CAIRO | March | | > ------------------------------------------------------------------------------ > Christopher Ambler | B | yes | | YES | | > Dave Crocker | A,D | yes | | YES | | > Eric Brunner | A,D,E | yes | | YES | | > Ian Penman | | yes | | YES | | > J. William Semich | | no | | YES | | > James Love | | | NEW | YES | | > John Charles Broomfield | | yes | | YES | | > Justine McCarthy | | | NEW | YES | | > Karl Auerbach | | yes | | YES | | > Mark Measday | A | yes | | YES | | > Mikki Barry | B | yes | | YES | | > Paul Garrin | B | yes | | YES | | > Rick H. Wesson | | yes | | YES | | > Roeland Meyer | G | yes | | YES | | > Ross Wm. Rader | | yes | | YES | | > Scott Pollard | | no | | YES | | > Siegfried Langenbach | A | yes | | YES | | > Tony Linares | | | NEW | YES | | > William X. Walsh | B | yes | | YES | | > kendall@paradigm.nu | | | NEW | YES | | > > Con text: > ------------------------------------------------------------------------------ > name | paper | 8 Dec | CAIRO | March | | > ------------------------------------------------------------------------------ > Christopher Ambler | B | yes | | YES | | > Anthony Lupo | C | no | | NO | | > Petter Rindforth | C | no | | NO | | > Philip Sheppard | | no | | NO | | > Warwick Rothnie | | | NEW | NO | | > > A Kendall Dawson also subscribed to WG-C on Feb 23rd, under a different > "nom de net", the Kendall Dawsons are allowed one vote and to send me > one item email each as cheery as ... what was that guy's name anyway? > > Cheers, > Eric > - -- Mark C. Langston mark@bitshift.org Systems & Network Admin San Jose, CA ------------------------------ Date: Mon, 20 Mar 2000 10:14:06 -0600 From: dwmaher@ibm.net Subject: [wg-c] wg-c vote I vote yes David Maher ------------------------------ Date: Mon, 20 Mar 2000 11:21:43 -0500 From: "Newell, Tom" Subject: RE: [wg-c] distributing gTLD whois Why not use DNS? Specify the location of a whois service for a zone using SRV? Rework whois clients to make them SRV-aware. Client would: 1. SRV query to parent-dom for zone to locate whois service location 2. Whois query to location returned, client queries location identified. No need for centralized tables; zone administrators manage service location directly; seems to scale... This has actually been an approach under discussion at recent CENTR meetings. - --Tom - -----Original Message----- From: Roeland M. J. Meyer [mailto:rmeyer@mhsc.com] Sent: Sunday, March 19, 2000 2:17 PM To: 'Dave Crocker'; 'Rick H Wesson' Cc: wg-c@dnso.org Subject: RE: [wg-c] distributing gTLD whois Dave, I agree, but this still leaves unreolved, the issue of where to find the whois servers. as the phrase "whois.. is not at all consistent across whois service implementors. The central mapping server whould be a good addition. > -----Original Message----- > From: owner-wg-c@dnso.org [mailto:owner-wg-c@dnso.org]On > Behalf Of Dave > Crocker > Sent: Sunday, March 19, 2000 9:45 AM > To: Rick H Wesson > Cc: wg-c@dnso.org > Subject: Re: [wg-c] distributing gTLD whois > > > At 08:41 AM 3/19/00 -0800, Rick H Wesson wrote: > >when new registries come on line it will be difficult to traverse the > >whois tree with current whois clients. there are several > ways to solve > >the problem I would like to hear which proposal might work best. > > > > a) allocate the TLD in TLD.whois.int maping to the registry's > > whois service. > > This is really the same approach as is taken for in-addr.int, namely > creating a 'centralized' mapping table. It is a > well-understood approach, > though it is separated from the main set of data that the > registry-related > people work with. > > > > b) require the current manager of rs.internic.net to merge all > > whois queries into the current whois service providing referals > > to the actual authorative service. > > The extreme version of 'centralized'. > > And... > > I believe there is an alternate approach that is simpler, > scales well, and > is more natural for the registry folk to deal with: > > Require whois support for .. So to find out about the > registration of brandenburg.com, you ave whois query .com. > To find out the > registration of icann.org, you have whois query .org. > > This is thoroughly predictable and involves maintenance by > the organization > already responsible for the relevant TLD. > > d/ > > =-=-=-=-= > Dave Crocker > Brandenburg Consulting > Tel: +1.408.246.8253, Fax: +1.408.273.6464 > 675 Spruce Drive, Sunnyvale, CA 94086 USA > ------------------------------ Date: Mon, 20 Mar 2000 08:20:10 -0800 From: Dave Crocker Subject: [wg-c] Re: Shared TLD and shared roots? At 08:06 AM 3/20/00 -0800, Roeland M. J. Meyer wrote: >... It appears that SRS will >improve. Thus, lending the lie to the infeasibility argument, of the IAB. The SRS pertains to multiple registrars for a registry, not multiple managers for a registry. The SRS is not relevant to the question of multiple points of control for a registry. >Myself and others have already pointed to various proofs of shared >root-zones. and they nicely demonstrate either the problems cited in the IAB document or that the alternative efforts are, in fact, another example of central control. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA ------------------------------ Date: Mon, 20 Mar 2000 17:35:24 +0100 From: "Petter Rindforth" Subject: SV: [wg-c] OK, *really* final version I vote "no". Petter Rindforth - -----Ursprungligt meddelande----- Från: Jonathan Weinberg Till: wg-c@dnso.org Datum: den 18 mars 2000 08:31 Ämne: [wg-c] OK, *really* final version > Immediately after sending out the "frozen" version of the report, I got a >message from Bob Broxton with additional suggestions. I've added in a few >of his changes, but this is it -- this is the really and truly final version. > > Again, votes are due by 3 a.m. UTC (10 p.m. US EST) on Monday night / >Tuesday morning. > > Thanks. > >Jon ------------------------------ Date: Mon, 20 Mar 2000 11:47:22 -0500 From: "Winer, Jonathan" Subject: RE: [wg-c] WG-C report -- final version "No," although the report is by and large very helpful. There seemed to be a majority on the Sheppard/Kleiman principles, and if there wasn't, the issues raised should be considered important enough to resolve first rather than to proceed piece-meal. I vote yes On Fri, 17 Mar 2000, Jonathan Weinberg wrote: > Here is the "frozen" version of the WG-C report, taking into account > additional comments received. Because this comes a few hours later than > promised, I propose that we extend the voting period to 3 a.m. UTC (10 > p.m. US EST) on Monday night / Tuesday morning. All votes *must* be in > before then, so that I can pass the report onto the Names Council. So far, > I count Petter Rindforth and Anthony Lupo as voting no on the report, and > Justin McCarthy as voting yes. Please let me know if you have atttempted > to vote on the report but aren't on that list (or if you are on that list > but don't consider yourself to have voted). Majority vote prevails, as set > out in . > > Thanks to all. > > ------------------------ > > 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 currently has about 140 members, not all of whom are active. > It includes extensive representation from each of the constituencies. > (There is one partial exception: 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 . > > 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 > 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 > substantial sentiment within the working group for the proposition 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 > . > - -- Alex Kamantauskas alexk@tugger.net NOTICE: This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by telephone (404-881-7000) or by electronic mail (postmaster@alston.com), and delete this message and all copies and backups thereof. Thank you. ======================================================= ------------------------------ Date: Mon, 20 Mar 2000 08:47:49 -0800 From: "Roeland M. J. Meyer" Subject: RE: [wg-c] distributing gTLD whois This seems like a good idea and one that should be implemented in code. Can you send references to appropriate links and documents? Ones suitible for codifying? However, there remains the deployment issue. How many DNS servers implement BIND8? Bear in mind that, MANY commercial Unices are significantly down-rev and are still running BIND4 or older, not to mention the flock of crufty old BSD and SCO systems out there (I personally know of one old VAX 11/780 still in operation, with Unix 4.2bsd). Until the SRV feature is more widely deployed, it cannot be used as the sole mechanism. (Don't forget that even when the software is installed, it must still be configured properly) > -----Original Message----- > From: Newell, Tom [mailto:tomn@netsol.com] > Sent: Monday, March 20, 2000 8:22 AM > To: 'rmeyer@mhsc.com'; 'Dave Crocker'; 'Rick H Wesson' > Cc: wg-c@dnso.org > Subject: RE: [wg-c] distributing gTLD whois > > > Why not use DNS? Specify the location of a whois > service for a zone using SRV? Rework whois clients > to make them SRV-aware. Client would: > > 1. SRV query to parent-dom for zone to > locate whois service location > 2. Whois query to location returned, client > queries location identified. > > No need for centralized tables; zone administrators > manage service location directly; seems to scale... > > This has actually been an approach under discussion > at recent CENTR meetings. > > --Tom > > -----Original Message----- > From: Roeland M. J. Meyer [mailto:rmeyer@mhsc.com] > Sent: Sunday, March 19, 2000 2:17 PM > To: 'Dave Crocker'; 'Rick H Wesson' > Cc: wg-c@dnso.org > Subject: RE: [wg-c] distributing gTLD whois > > > Dave, > > I agree, but this still leaves unreolved, the issue of where > to find the > whois servers. as the phrase "whois.. is not at all > consistent > across whois service implementors. The central mapping server > whould be a > good addition. > > > -----Original Message----- > > From: owner-wg-c@dnso.org [mailto:owner-wg-c@dnso.org]On > > Behalf Of Dave > > Crocker > > Sent: Sunday, March 19, 2000 9:45 AM > > To: Rick H Wesson > > Cc: wg-c@dnso.org > > Subject: Re: [wg-c] distributing gTLD whois > > > > > > At 08:41 AM 3/19/00 -0800, Rick H Wesson wrote: > > >when new registries come on line it will be difficult to > traverse the > > >whois tree with current whois clients. there are several > > ways to solve > > >the problem I would like to hear which proposal might work best. > > > > > > a) allocate the TLD in TLD.whois.int maping to the registry's > > > whois service. > > > > This is really the same approach as is taken for in-addr.int, namely > > creating a 'centralized' mapping table. It is a > > well-understood approach, > > though it is separated from the main set of data that the > > registry-related > > people work with. > > > > > > > b) require the current manager of rs.internic.net to merge all > > > whois queries into the current whois service > providing referals > > > to the actual authorative service. > > > > The extreme version of 'centralized'. > > > > And... > > > > I believe there is an alternate approach that is simpler, > > scales well, and > > is more natural for the registry folk to deal with: > > > > Require whois support for .. So to find out about the > > registration of brandenburg.com, you ave whois query .com. > > To find out the > > registration of icann.org, you have whois query .org. > > > > This is thoroughly predictable and involves maintenance by > > the organization > > already responsible for the relevant TLD. > > > > d/ > > > > =-=-=-=-= > > Dave Crocker > > Brandenburg Consulting > > Tel: +1.408.246.8253, Fax: +1.408.273.6464 > > 675 Spruce Drive, Sunnyvale, CA 94086 USA > > > ------------------------------ End of WG-C-DIGEST V1 #54 *************************