Chicoine and all, I vote for option 4 with the following suggested amendment: Resolved, that ICANN should allow the membership and/or the DNSO GA make this determination by majority vote post haste. That all alternative existing gTLD's be added that are not currently in conflict or a clear determination of that conflict is already known, and further that these sited gTLD's must be chartered gTLD's... Chicoine, Caroline wrote: > Would like your input before midnight EDT next wednesday. > > Thanks, Caroline. > > > -----Original Message----- > > From: Jonathan Weinberg [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, August 12, 1999 22:53 > > To: [EMAIL PROTECTED] > > Subject: [wg-c] Straw Vote > > > > > > WG-C began its work more than a month ago now (some WG > > members joined more > > recently), and I think we've gotten a lot done. To try to > > get us forward > > to the next stage, I've been working with Javier on an options memo > > summarizing the viewpoints that people have expressed on the > > list so far. > > (Specifically, I put together an initial draft, Javier > > commented on the > > draft, and I revised it in accordance with his comments. > > Javier hasn't > > seen this final version, though, and if you don't like it, you should > > complain to me, not him.) > > > > I'd like us to start taking straw votes on these > > questions. I don't mean > > these votes to be formal or conclusive. Rather, they're a tool for > > revealing whether we may in fact have rough consensus on any > > of the issues > > I've listed - something that's hard to tell in the course of everyday > > discussion, given the strength and eloquence of individual > > voices on each > > side. I think it makes sense to take the votes successively, > > rather than > > all at once. That way, folks will have the opportunity, if > > they want, to > > argue each question as it arises. > > > > So as a beginning, list members should cast votes on > > Question One. You > > should cast votes under the subject line "Straw Vote," and the sender > > should indicate whether he or she is voting for "Option One," > > "Option Two," > > or "Neither." Voters are free to include explanations of > > their votes and > > arguments for their positions - or they can just cast votes. > > It's up to > > you. The only requirement is that anybody voting for "Neither" *must* > > explain what his or her preferred policy choice is. Voting > > should close at > > midnight EDT on August 18. (I don't think we really need > > that long, and I > > expect it'll make sense to take less time for the remaining > > questions, but > > I figure it's better to err on the side of inclusiveness the > > first time out.) > > > > A note on nomenclature: I use "gTLD" below to include > > any top-level > > domain other than a ccTLD. That is, I'm including both TLDs > > that have a > > charter limiting registrations and those that do not. > > > > Thanks. > > > > Jon > > > > > > Jon Weinberg > > co-chair, WG-C > > [EMAIL PROTECTED] > > > > > > > > QUESTION ONE: HOW MANY NEW gTLDS, AND HOW FAST? > > > > Option 1: Without regard to whether it would be desirable > > to have many > > gTLDs in the long term, ICANN should proceed now by adding > > only a few, and > > then pausing for evaluation. Only after assessing the > > results should it > > initiate any action to add more. > > > > Option 2: ICANN should implement a plan contemplating the > > authorization of > > many new gTLDs over the next few years. (Example: ICANN might plan to > > authorize up to 10-12 new registries, each operating 1-3 new > > gTLDs, each > > year, for a period of five years; each year's authorizations would be > > staggered over the course of the year.) This option would > > place the burden > > on opponents, if evidence comes in demonstrating that > > additional new gTLDs > > are a bad idea or that the rollout is too fast, to bring that > > evidence to > > ICANN's attention and call for a halt or a slowdown. > > > > > > QUESTION TWO: HOW TO SELECT TLD STRINGS AND REGISTRIES? > > > > Option 1: ICANN should decide on a set of new gTLD > > strings, and then > > solicit applications from would-be registries (or existing > > registries) to > > run those TLDs. In picking the new gTLD strings, it should > > use an ad hoc > > approach to choose the new gTLDs that it thinks will best serve the > > Internet community. Each proponent of a new gTLD would apply > > to the NC for > > formation of a WG devoted to that gTLD string (or to several > > strings). The > > WG would then generate a charter for each proposed new TLD, > > and it would be > > up to the NC and ICANN to approve the WG's product. This > > process would > > likely generate some broad-based TLDs along with some more > > narrowly focused > > ones (which might have restrictive registration policies). > > > > Option 2: Same as Option One, except that a standing WG > > would make > > periodic proposals for new gTLDs. > > > > Option 3: ICANN should decide on a set of new gTLD > > strings, and then > > solicit applications from would-be registries (or existing > > registries) to > > run those TLDs. Before picking the new gTLD strings, it > > should agree on a > > predetermined structure for the namespace (such as a Yellow Pages-type > > taxonomy). All new gTLDs, under this approach, would be > > limited-purpose. > > This approach would be responsive to Dennis Jennings' concern > > that "the set > > of gTLDs that are active must, to be successful, be clearly > > understood by > > the vast majority of Internet users (in English) to point to clearly > > defined and (ideally) non-overlapping sub-sets of the > > possible Internet > > hosts." > > > > Option 4: ICANN should start by adding the existing > > "alternate" gTLDs, > > and then find a neutral method to continue adding new TLD > > strings, focusing > > on names that have already been proposed. > > > > Option 5: ICANN should pick a set of registries, according to > > predetermined, objective criteria. The registries would then > > choose their > > own gTLD strings, subject to some process or rules under > > which ICANN could > > resolve conflicts, and could deem certain gTLD strings out of > > bounds. This > > approach would incorporate a mechanism under which existing registries > > could apply for authorization to add additional gTLD strings. The > > registry-selection criteria might reserve a certain number of > > slots for > > registries based in each region of the world. > > > > > > QUESTION THREE: SHOULD REGISTRIES BE FOR-PROFIT OR > > NON-PROFIT? HOW MANY > > gTLDS SHOULD THEY RUN? > > > > Option 1: All registries would be run on a > > not-for-profit, cost-recovery > > basis. (The "registry operator," in the sense that Emergent was the > > operator of the planned CORE registry, could be a for-profit company.) > > Registries could operate any number of gTLDs. > > > > Option 2: Some registries would be run on a > > not-for-profit, cost-recovery > > basis, and could operate any number of gTLDs. Other > > registries, however, > > could be run on a for-profit basis, and would be limited to > > one gTLD each. > > > > Option 3: Some registries would be run on a > > not-for-profit, cost-recovery > > basis, and could operate any number of gTLDs.. Other > > registries, however, > > could be run on a for-profit basis, and would be limited to a > > small number > > of gTLDs (say, three). > > > > Option 4: Some registries would be run on a > > not-for-profit, cost-recovery > > basis. Other registries, however, could be run on a > > for-profit basis. Any > > registry could operate any number of gTLDs. > > > > > > QUESTION FOUR: SHOULD ICANN REQUIRE SHARING? > > > > Option 1: All gTLDs would be shared (that is, open to > > competitive > > registrars). > > > > Option 2: An ICANN rule would presumptively require > > that gTLDs be shared, > > but ICANN would allow exceptions in particular cases. (A > > single registry > > might run both shared and non-shared gTLDs.) > > > > Option 3: ICANN would not require registries to > > support competitive > > registrars in any of their gTLDs, although registries might > > independently > > choose to do so. > > Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail [EMAIL PROTECTED] Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
