[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [wg-c] WG-C Report
"Mark C. Langston" <skritch@home.com> wrote (03/17/00 01:36PM)
>On Fri, Mar 17, 2000 at 06:12:57PM +0100, Petter Rindforth wrote:
>>
>
> > * The report mainly ignores the difficulties that trademark owners
> will face in attempting to protect their names, {snip now that context is clear}
>
>Doesn't the law require the TM owner to police their own marks, rather
>than shift the burden of this to an entity like a registrar? I believe
>this discussion has gone round several times in WG-B, where it belongs.
>
While Mr. Langston's statement is literally correct, we are not now facing a
legal issue. We are facing a political issue, in which the trademark interests
are ill-served by allowing the expense of policing their marks to be greatly
increased.
>If there is a need for quick, efficient searching of multiple TLDs for
>possible infringement as the number of TLDs grow, I'm sure businesses
>will spring up to fill that need.
>
>In fact, they already exist.
The recent fracturing of the whois database into separate databases for each
registrar has well and truly <loved> the ability of trademark searchers to do
exactly this.
So this is not a complaint about the
>difficulty of policing marks, it's a complaint about the cost of doing
>so.
The comment is so startling, I would use it on fellow zazen sitters if any of them
were involved in the domain name wars. Given an economic incentive to
perform an act, there is always a price at which it will be performed. If it
becomes more difficult, the price will go up. Given the (usual) price-elasticity
of demand, higher prices eat into corporate profits. Therefore, existing interests
will calculate a set point at which they will spend money to stop the enlargement
of the TLD namespace rather than spend money to find a way to police their
marks in that enlarged namespace. In other words,
cost = k*difficulty
profits = k*difficulty**(-1) <Goodness, did I just date myself as a Fortran geek?>
> A cost that the TM owners want to shift to the registrars and/or
>registries rather than continue to bear themselves, as they ought.
Nope. A cost that the TM owners want to make go away like morning mists in the sunlight.
>
>
>
>
> > * Under "Discussions within the working group" it is mentioned that
> "a substantial number of working group members did not cast votes",
> but nothing is said about the reason for this silence. As you will
> recall, the Names Council recommended the WG C to be reconstructed in
> September 1999, as the NC had noticed the WGs "high traffic and
> limited progress" and concluded that the working group's structure was
> "not adequate to carry out the substantive work of the DNSO". Thus, it
> seemed pointless to participate in a vote during the reconstruction
> period. Also, a significant numbers of WG C members, not only the ones
> representing IP-interests have argued that the question of "how many"
> should not be raised until we have answers on "how". I am well aware
> of the fact that the initial rollout of 6-10 new gTLDs are supported
> by 44 members of the WG C - on the other hand, the working group has
> currently "more than 140 members"...
>
>
>Silence is properly counted as abstention, and as such is not
>attributable to either position.
Europeans (at least used to) think otherwise. There is a long standing
tradition of staying away from the polls to express distaste with the
process. This is why (for example) in the days of the USSR being
ruled under a one-party system by the CPSU(b), much was made of
the fact that over 96% of the electorate went to the polls.
>Therefore, those unheard voices are
>effectively and correctly ignored. If you did not vote, and the result
>is not to your liking, you have nobody to blame but yourself.
>
> > * As to "ongoing work" - the question of "how": It is my opinion
> that it should be the task of ICANN to decide on the set of new gTLD
> strings (and, if we have to stick to the "6-10", rather 6 than 10) and
> then solicit applications from would-be registries, or existing
> registries, to run those TLDs. Having ICANN retain control of the
> adoption of any new gTLDs would not only further the specific purposes
> for which it was formed, but would also enable ICANN to formulate gTLD
> strings that will help domain name owners and users, trademark owners
> and different members of the public to distinguish among identical
> domain name registered in different TLDs.
>
>
>We've already had this discussion, and this vote.
>
>And the method used to " [...] distinguish among identical domain name
>registered in different TLDs" is the TLD itself. it's a unique string,
>plainly visible for all to see.
>
>Or are we now going to suggest that foo.cx is confusingly similar to
>foo.baz? If so, perhaps it's truly time to scrap the domain name system
>as it currently exists and put the BIND code to a different, less
>confusing use, because as time goes by, the namespace _WILL_ become
>larger. It's inevitable.
>
If wishing makes it so. I happen to share this wish. I wish to see 1000
domains bloom. It's because I hold this wish that I continue to point out
the political reality with which the process must deal. Our
political success will not be fostered by saying that *we* control the
namespace and *we* are going to make it grow, and trademarks be damned,
for there open the gates of hell. Yea, though I am
the voice of one crying out in the wilderness, yet still I try to get DN
warriors to see that the road to victory will come only when the TM
interests join us in supporting the growth of the namespace. Here open the
gates of heaven.
KJC.2
**********************************************************************
The information contained in this electronic message is confidential
and is or may be protected by the attorney-client privilege, the work
product doctrine, joint defense privileges, trade secret protections,
and/or other applicable protections from disclosure. If the reader of
this message is not the intended recipient, you are hereby notified
that any use, dissemination, distribution or reproduction of this com-
munication is strictly prohibited. If you have received this communi-
cation in error, please immediately notify us by calling our Help Desk
at 212-541-2000 ext.3314, or by e-mail to helpdesk@rspab.com
**********************************************************************