...
Unfortunately, SiteFinder did not have such a destructive effect as we
had all wanted it to have.
...
that apparently depends on what you wanted and what you consider destructive.
to me, as a domain holder under .COM, the damage was latent, coming in the
form of "unacceptable business risk". as long as i know that my competitors
would have to actually register "nearby" names in order to steal business
from me, then i know (a) their costs are linear with my risk, and (b) i can
find out what they're doing and perhaps even who they're paying to do it.
in the presence of a wildcard and paid advertising, (a) no longer holds and
there is no way to do (b). if sitefinder returns, i'd expect to have to find
a new parent domain, who has no wildcard-like keyword system, just for risk
management reasons. some domain holders might prefer to manage this risk by
paying verisign extra money to get all the nearby keywords, but i'd consider
this blackmail and i'd rebrand my offerings out of .COM and .NET, and i expect
that many other domain holders would feel (and do) the same. ultimately i'd
expect domain registration fees in wildcard-free TLDs to cost more than domain
registration fees in wildcard-containing TLDs.
also, to me, as a domain holder under .com who uses my domain for more than
just a web site, i can't tolerate the lack of RCODE=3 when a "nearby" name
is used by mistake. verisign promised not to use the connections for anything
nefarious, but they are not a public-benefit corporation and if they thought
that the best way to return value to their shareholders was to keyword-search
e-mail that was sent to them by mistake, then they would be stupid NOT to do
so. (this has been called a strong argument for all TLD registries to be
required to be public-benefit corporations... foxes guarding chicken houses,
and so on.)
So while SideFinder was not as destructive as we might have thought
or hoped, ...
i wasn't hoping for anything in particular. but sitefinder was incredibly
damaging, and its return would mark a sharp uptick in my risk management costs,
and there's no way you could say it wasn't "destructive" based simply on
your local network traffic analysis. simply put, i would have chosen a
different TLD if i'd known that wildcard processing was going to occur, and
i do not recognize verisign's right to unilaterally change the terms under
which my domain's delegation data is served.
also, to me, as a domain holder under .com who uses my domain for more than
just a web site, i can't tolerate the lack of RCODE=3 when a "nearby" name
is used by mistake. verisign promised not to use the connections for anything
nefarious, but they are not a public-benefit corporation and if they thought
that the best way to return value to their shareholders was to keyword-search
e-mail that was sent to them by mistake, then they would be stupid NOT to do
so. (this has been called a strong argument for all TLD registries to be
required to be public-benefit corporations... foxes guarding chicken houses,
and so on.)
Just image if Versign one day would find out that they can implement some sort
of "ad-word" or "adsense" program where it will redirect you directly, or with
a ten second delay, to the site of the highest bidder for the closest matching
keyword.
Type "example.com" which does not exist and get redirected to "evilempire.com"
who bought the keyword "example". Great, isn't it?
PS: I will patent it myself to prevent Versign from doing this.
Wouldnt it be beautiful if a bunch of people patented the hell out of
various ways to exploit dns wildcarding, thus preventing verisign from
doing anything useful with it at all...
> PS: I will patent it myself to prevent Versign from doing this.
And if they do, what's to stop the root operators from doing this.
the root server operators don't act collectively.
Remember, there are 13 IPs no one can get around - no other "TLD" to
register your domain name.
according to the whackos, we are the "legacy root" operators, and folks
ought to feel free to point their resolvers at any of the "alternative
root" operators instead. YMMV.
Flipped on its head, what's to stop the root operators from
circumventing anything Verisign or any other TLD operator does?
root server operators don't control the root zone, they only publish it.
some combination of itu (via the iso3166 process), icann/iana, ietf/iab,
and us-DoC are the folks you'd go to if you wanted a toplevel wildcard.
PS: I will patent it myself to prevent Versign from doing this.
And if they do, what's to stop the root operators from doing this.
the root server operators don't act collectively.
While correct, your statement does not answer the original question.
Remember, there are 13 IPs no one can get around - no other "TLD" to
register your domain name.
according to the whackos, we are the "legacy root" operators, and folks
ought to feel free to point their resolvers at any of the "alternative
root" operators instead. YMMV.
Let's confine the discussion to the 99.99% of us who use the Internet .. uh .. "normally". (Best description I could think up.)
I mean, they are called "whackos" for a reason.
Flipped on its head, what's to stop the root operators from
circumventing anything Verisign or any other TLD operator does?
root server operators don't control the root zone, they only publish it.
some combination of itu (via the iso3166 process), icann/iana, ietf/iab,
and us-DoC are the folks you'd go to if you wanted a toplevel wildcard.
Actually, the root server operators absolutely do _control_ the root zone in very obvious operationally relevant ways.
Whether that control could be used - improperly or not - to, say, insert a wildcard record strikes me as much the same question as the Verisign action which started this thread....
>PS: I will patent it myself to prevent Versign from doing this.
And if they do, what's to stop the root operators from doing this.
Remember, there are 13 IPs no one can get around - no other "TLD" to
register your domain name.
Flipped on its head, what's to stop the root operators from
circumventing anything Verisign or any other TLD operator does?
we'd have to agree on what to do...
and thats been problematic for years.
or one could view it as the core strength
of the root server system (theres a misnomer:)
of course, if a majority of the root server instances
decided to make the change, then we have inconsistancy
in the authoritatve data - which is -REALLY- bad.
>> And if they do, what's to stop the root operators from doing this.
>
> the root server operators don't act collectively.
While correct, your statement does not answer the original question.
i consider it directly responsive. one of the ways to keep a root server
operator from doing something, statistically speaking at least, is to tell
them that some other root server operator is doing it.
>> Flipped on its head, what's to stop the root operators from
>> circumventing anything Verisign or any other TLD operator does?
>
> root server operators don't control the root zone, they only publish
> it. some combination of itu (via the iso3166 process), icann/iana,
> ietf/iab, and us-DoC are the folks you'd go to if you wanted a toplevel
> wildcard.
Actually, the root server operators absolutely do _control_ the root
zone in very obvious operationally relevant ways.
Whether that control could be used - improperly or not - to, say,
insert a wildcard record strikes me as much the same question as the
Verisign action which started this thread....
you will never find a more tightly woven hive of independence and diversity.
the only things all 12 operators have ever been able to agree on are that
(1) the root zone should be published with maximum reachability and uptime,
(2) the root zone should not be edited by the root server operators, and
that, finally, (3) there should never be a (3).
Patent violation can be easily gathered, but the penalty is always based on
the lost revenue, which must be documented and validated.
In short, if you want to make money selling your patent to someone then you
must have a valid business that loses money so that your lawsuit against
them will have teeth.
So the attorney creates an IP holding company to which the patent is
assigned, and the company offers to license the patent to Verisign.
When Verisign refuses, they get sued for lost revenue.
There are companies whos entire revenue stream revolves around licensing
patents / litigating. This is quite normal.
> In short, if you want to make money selling your patent to someone then you
> must have a valid business that loses money so that your lawsuit against
> them will have teeth.
So the attorney creates an IP holding company to which the patent is
assigned, and the company offers to license the patent to Verisign.
When Verisign refuses, they get sued for lost revenue.
The holding company must be making money from the patent to demonstrate the
value of the loss. It can't be a silent owner -- these have been fairly
routinely tossed out of court as meritless.
There are companies whos entire revenue stream revolves around licensing
patents / litigating. This is quite normal.
Yes, but they use complicated techniques of licensing and subcompanies with
demonstratable revenue to achieve those goals. It's not as simple as was
suggested here.
