ICANN ICANN Email List Archives

[new-gtlds-pdp-comments]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] Top Level Domain or Second Level Domain?

  • To: Danny Younger <dannyyounger@xxxxxxxxx>, ICANN new-gtlds <new-gtlds-pdp-comments@xxxxxxxxx>
  • Subject: Re: [ga] Top Level Domain or Second Level Domain?
  • From: Jeff Williams <jwkckid1@xxxxxxxxxxxxx>
  • Date: Wed, 28 Dec 2005 01:46:56 -0800

Danny and all former DNSO GA members or other interested
stakeholders/users,

It would seem anti free market to suggest that what is "Sensable" to
one person or group is "Sensible" to another person or group.  The
Free market system doesn't work that way, and can't function as
a free market with such ephemeral criterion.  Many things are sold
that I believe are not "Sensible" or add value to the free market
system.  However that  is "Only" my opinion, and therefore
has only the support of those that agree with me to that extent.

Therefore if restraint of trade in a free market system is to be so
definably structured by a logically indefinable term as "Sensible"
is to be "Non-sensable" to whatever degree is acceptable to
a broad free market.  Hence to use such as criterion for determining
what TLD's "should" be added is not good criterion.

Danny Younger wrote:

> Sotiris writes:  "I would say a more prudent and
> logical approach would be to use the existing ccTLD
> and to partition it further based on states/provinces
> and perhaps regions or even cities"
>
> This above comment puts a finger on the problem that
> we all are facing -- earlier I had written about
> .berlin and had argued that some would say that it
> rightly belongs as a subdomain of .de or .eu
>
> Let's face it, some applicant will tender a hefty
> application fee (after having committed a significant
> amount of time and resources developing support for a
> proposal) only to be told by some member of the Board
> that "in my view, it would be more logical for [name
> of string] to be at the second-level rather than at
> the top-level".
>
> We can't let such subjectivity enter into the process.
>
> What we need to develop is an understanding of what
> belongs or doesn't belong at the top level, and to
> clearly spell that out by way of the selection
> criteria.
>
> Please note that the year 2000 criteria stated:
>
> "The enhancement of the utility of the DNS.
>      One motivation often cited for introducing new
> TLDs is that doing so might increase the utility of
> the DNS. Under this view, the appropriateness of
> adding new TLDs should be evaluated based on whether
> addition of the new TLDs:  would sensibly add to the
> existing DNS hierarchy"
> ?Criteria for Assessing TLD Proposals?
> http://www.icann.org/tlds/tld-criteria-15aug00.htm
>
> Is this criterion as stated still acceptable?  Do all
> new TLDs have to be "sensible" additions to the
> hierarchy?  Do they all need to display a quality of
> "appropriateness"?
>
> Can't we find better language to make it clear as to
> what we believe belongs at the top level and at other
> levels?
>
> --- sotiris@xxxxxxxxxxxxxxxxx wrote:
>
> > Danny Younger wrote:
> >
> > > I started wondering what the internet might be
> > like
> > > if, for example, a New York City resident could
> > access
> > > local content by recourse to a .212 TLD that
> > limited
> > > registrations to those that had a phone number in
> > the
> > > 212 area code.
> >
> > In my post
> >
> http://gnso.icann.org/mailing-lists/archives/ga/msg03436.html
> > on Decemeber 16, I likened the gTLD namespace to the
> > area code system, but
> > I do not support the idea of localized area code
> > TLDs per se.  I think a
> > far more prudent approach would be to use the
> > existing ccTLD hierarchy for
> > any such localized breakdown.
> >
> > >My assumption is that such New Yorkers
> > > would have no problem becoming accustomed to a
> > > numerical TLD that corresponded with their own
> > area
> > > code and would probably discover a great amount of
> > > utility in such a namespace.
> > >
> > > John Klensin has been fond of pointing out that
> > the
> > > nature of the current naming system is such that
> > it
> > > cannot support both Joe's Pizza (of Boston) and
> > Joe's
> > > Pizza (of San Francisco) as only one joespizza may
> > be
> > > registered in a TLD.
> > >
> >
> http://ietfreport.isoc.org/idref/draft-klensin-dns-role/
> >
> > Well, joespizza.us is currently available so I'd say
> > that there's still at
> > least one opportunity for some lucky Joe... ;-)
> >
> > >
> > > If each area code had its own TLD, then the Joe's
> > of
> > > this world would have a greater opportunity to
> > > establish domains that corrsponded with their
> > > particular business identities.  Yes, it's a
> > taxonomic
> > > approach with nexus requirements, but it would
> > > probably serve local communities better than the
> > > current set of alternatives.
> >
> > Again, I would say a more prudent and logical
> > approach would be to use the
> > existing ccTLD and to partition it further based on
> > states/provinces and
> > perhaps regions or even cities; an approach will
> > already exists in fact.
> >
> > Amiably,
> >
> > Sotiris Sotiropoulos
> >
> >
>
>
>
> _

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402
E-Mail jwkckid1@xxxxxxxxxxxxx
 Registered Email addr with the USPS
Contact Number: 214-244-4827




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy