Re: [wg-c] Choosing the intial testbed

[Kent Crispin <kent@songbird.com>]

On Wed, Mar 22, 2000 at 07:45:03AM -0800, Dave Crocker wrote:
[...]
> 
> I agree, hence my statement of support for the basic idea, though the 
> concerns that Brunner state are non-trivial and entirely valid.
> 
> 
> >    If the non-commerical domain holders could choose 3, they would
> 
> The essential non-existence of that group as a functioning group is not a 
> minor or subjective point.

I suspect you may have read "individual domain name holders" for 
"non-commercial domain name holders".  The former, as you state, not in 
existence as a meaningful group.  The latter, however, is a functioning 
constituency. 

> >    For the voting proposal. ICANN does have a membership system. It is
> 
> It has the framework for one.  It does not have one that is 
> functioning.  Hence your proposal pretty much assures that it will be 
> nearly a year to get a set of names from the at large group.

Yes.  There are other problems with tying name proposals to votes of a
large body, as well.  But, like you, I think that Jamie's basic approach
is well worth working on.

Here are some hopefully constructive observations:

I think everybody agrees that there should be a defined process for
addition of TLD names to the root zone.  If we just use ad hoc votes to 
select names for the initial rollout, we will not have done anything to 
define a process.  It would be nice to minimize adhoc-ness as much as 
possible, because if we don't deal with the procedural issues now we 
will be stuck with them later...there is of course some unavoidable 
uniqueness to the initial rollout.

TLD name selection really should *not* be a popularity contest. 
Whatever procedure there is in place really must allow for the creation 
of small, special-purpose TLDs.  Moreover, there should be at least 
some development of *reasons* for a particular TLD name.

An underlying motif in Jamie's suggestion is that the process would be
subdivided by interest groups, who would propose their own TLD
suggestions, presumably after some internal deliberation.  His proposal
"blesses" a subset of the constituencies, and, while there is some
superficial appeal to that approach, I see lots of problems with that
particular approach -- I'm not sure (for example) why some
constituencies were selected and others were left out.

In general, we would like TLD proposals to come from groups that are
cohesive enough to come to agreement on reasonable proposals for names,
but large enough and open enough so that the issues get a good airing.  
Large, diverse groups will have difficulty coming to decisions.

I would, therefore, propose that the long term mechanism by which TLD
names are proposed is that TLD Working Groups of the DNSO would be
formed.  The purpose of an individual TWG would be to produce a formal
proposal for a TLD name (or possibly a set of names).  The proposal
would include a justification, description of the group to be served and
how the TLD would serve them, perhaps a charter, perhaps a proposed
registry or sponsoring organization.  Anyone could form such a WG -- an
organization like Jamie's, CORE could form one to propose one or more of
their TLDs, etc etc.  The idea is that *someone* has to produce a
written proposal that will go, eventually, to the ICANN board for final
approval -- we don't want "back-door" processes.  Those proposals should
be prepared through some kind of defined ICANN process, with opportunity
for public input and comment on the way.  The DNSO WG is the cannonical
vehicle for such things.

It might be claimed that WG-C is the obvious vehicle for such things. 
It is not.  The WGs I have in mind are real WGs, where group document
preparation is the modus operandi.  They have to be small enough and 
specialized enough so that they can actually get some work done.

Note that production of a proposal would not mean that it was accepted. 

-- 
Kent Crispin                               "Do good, and you'll be
kent@songbird.com                           lonesome." -- Mark Twain