subject:"Re\: Verisign vs. ICANN"


> >> 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).
-- 
Paul Vixie

Re: Verisign vs. ICANN

2004-08-16 Thread bmanning

On Mon, Aug 16, 2004 at 03:17:48PM -0400, Patrick W Gilmore wrote:
> 
> On Aug 16, 2004, at 3:08 PM, Andre Oppermann wrote:
> 
> >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.

> -- 
> TTFN,
> patrick

Re: Verisign vs. ICANN

2004-08-16 Thread Patrick W Gilmore

On Aug 16, 2004, at 4:13 PM, Paul Vixie wrote:
[EMAIL PROTECTED] (Patrick W Gilmore) writes:
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

--
TTFN,
patrick

Re: Verisign vs. ICANN


[EMAIL PROTECTED] (Patrick W Gilmore) writes:

> > 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.
-- 
Paul Vixie

Re: Verisign vs. ICANN

2004-08-16 Thread Dan Hollis


On Mon, 16 Aug 2004, Andre Oppermann wrote:
> 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...

-Dan

Re: Verisign vs. ICANN

2004-08-16 Thread Patrick W Gilmore

On Aug 16, 2004, at 3:08 PM, Andre Oppermann wrote:
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?

--
TTFN,
patrick

Re: Verisign vs. ICANN


[EMAIL PROTECTED] (Michael Loftis) writes:

> ...
> The BIND source was modified in response to CUSTOMERS REQUESTS.  ...

actually, it was multiple credible threats of codeforking that got this done.
(as i explained in the press at that time, "isc cherishes our relevance.")
-- 
Paul Vixie

Re: Verisign vs. ICANN

2004-08-16 Thread Andre Oppermann

Paul Vixie wrote:
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.
--
Andre

Re: Verisign vs. ICANN

2004-06-19 Thread Michael Froomkin - U.Miami School of Law


> ...
> 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.

Re: Verisign vs. ICANN

2004-08-16 Thread Michael Loftis

I'm not a lawyer but I still think businesses have a valid lawsuit against 
Verisign for whatever the legal term is for using their copyrighted names 
and likenesses.  With SiteFinder it guarantees Verisign 'owns' any domain a 
particular company may no have yet purchased until such time that they do. 
And until they do their property gets branded as if it were Verisign's. 
That's my chief complaint against Verisign.

There is also the problem that no one can easily verify non-existence of 
ANY domain when the SiteFinder is deployed with the Wildcard A record, this 
is almost certainly detrimental.

The BIND source was modified in response to CUSTOMERS REQUESTS.  It seems 
as though Verisign intends to implement it's will by legal maneuvering. 
It's akin to Microsoft being told by say RedHat that they can't have 
multiple user logins because Linux does that.  Or that Windows can't have a 
good, useful CLI subsystem even though customers are clamoring for it.

I'm not certain what other legal beef Verisign may have with ICANN (and any 
of the others mentioned in their legal proceedings) but it's certainly not 
any conspiracy, an option was simply provided at the outcry by a large, 
well respected, technical community to a change in infrastructure we all 
rely on that caused problematic effects.

It's very regrettable that Verisign's lawyers decided it was necessary to 
go about this.

As part of a a disclaimer:  Any various mentioned parties were used above 
in a purely hypothetical manner and do not represent any companies actual 
intentions.  Any mentioned copyrighted names are the property of their 
respective copyright or other property holders.

Re: Verisign vs. ICANN

2004-08-16 Thread Paul Wouters

On Tue, 10 Aug 2004, Paul Vixie wrote:

> (and if the idea that kc or woolf could be depended upon to parrot
> somebody else's point of view caused you to laugh so hard you spewed
> coffee all over your keyboard while reading the above tidbits, then
> send the repair bill to verisign, not me.  i'm just the messenger.)

Unfortunately, SiteFinder did not have such a destructive effect as we
had all wanted it to have. Statistics in our network showed no 
significant increase in dns traffic. Especially if you compare it
against things like SoBig:

http://www.xtdnet.nl/paul/spam/graphs/versign.png

So even though my own hunch was wrong, I feel I should still publish
the data. If you only publish data when it serves your goal, you lose
your objectivity and your opinions become worthless as well. So I
won't be blaming kc of woolf for not confirming what isn't there but
what we really wanted to see.

So while SideFinder was not as destructive as we might have thought
or hoped, obviously it is still one of the most stupid ideas that
the NetSol/Verisign monstrosity came up with. If they cannot seperate
their Registrar from their Registry business, then ICANN should 
break their contract and find a proper party to host the Registry.

Ofcourse, in my dreams I have the money and all the girls too...

Paul

Re: Verisign vs. ICANN

2004-08-09 Thread Paul Vixie


> PS. I am excited - Vixie as a co-conspirator... Vixie, you can be proud -:).

i'm not, though.  not proud, and not a co-conspirator.  this whole thing
makes me want to puke.  the worst thing is, the people i know inside
verisign seem to wish i wouldn't take it so personally.  but if their
stock options go up in value as a result of this lawsuit, then it's
blood money, and it's on their hands.

anyway, today i was given a courtesy copy of verisign's "final ssac
response", which i've converted from pdf to a number of other
more-greppable formats, and put online.  url's are as follows:

http://sa.vix.com/~vixie/sitefinder/Final SSAC Response.doc
http://sa.vix.com/~vixie/sitefinder/Final SSAC Response.html
http://sa.vix.com/~vixie/sitefinder/Final SSAC Response.pdf
http://sa.vix.com/~vixie/sitefinder/Final SSAC Response.rtf
http://sa.vix.com/~vixie/sitefinder/Final SSAC Response.sxw
http://sa.vix.com/~vixie/sitefinder/Final SSAC Response.txt

here are some tidbits:

Moreover, the Report appears primarily to have been composed and/or
contributed to by persons who are opponents of Site Finder and/or
competitors of VeriSign, a fact the Report fails to acknowledge. For
example, Paul Vixie, a member of the committee who is cited three
times as evidentiary support for the Committee¡Çs conclusions, fails
to disclose that he is the president of Internet Systems Corporation
("IS C"), which released the BIND software patch discussed in the
Report as one of the technical responses to VeriSign¡Çs wildcard
implementation, and competes with VeriSign in other relevant
respects, including the provision of DNS services and as a potential
TLD registry operator. The Report also fails to identify that
Suzanne Woolf, an employee of ISC, K.C. Claffy, an associate of Paul
Vixie, and Mike StJohns as members of the committee who were added
to the committee by SSAC¡Çs committee chair, specifically for the
purpose of rendering conclusions about Site Finder. Ms. Woolf an
employee of ISC, K.C. Claffy, an associate of Paul Vixie, and Mike
StJohns as members of the committee who were added to the committee
by SSAC's committee chair, specifically for the purpose of rendering
conclusions about Site Finder. Ms. Woolf and Ms. Claffy's
association with Mr. Vixie suggests they were added for the purpose
of packing the committee with Site Finder opponents. [...]

...

For example, the Report relies heavily on the opinion of Paul Vixie,
an outspoken critic and competitor of VeriSign, on the issue of
Internet stability following the implementation of VeriSign's
wildcard.  Yet the Report fails to include a conflict of interest
statement for Mr. Vixie, even though he is the president of ISC,
which released the BIND software patch discussed in the Report as
one of the technical responses to VeriSign's wildcard
implementation.  Ironically, Mr. Vixie's BIND patch was a primary
source of the "incoherence" described in the Report.

...

On May 19, 2003, Paul Vixie wrote: "speaking for dnssac, [I] don't
think we have standing. [D]ns is a distributed, reliable,
autonomous, hierarchical database system. The key word for this
purpose is `autonomous'. Delegating something to somebody and then
telling them what they can and cannot put into it is false (and I
might add, offensively so.)"

...

As stated above, SSAC was unable to fault Site Finder on security or
stability grounds. Indeed, SSAC member Paul Vixie has expressly
admitted as much. In response to an email stating that "I think
recent events prove pretty well that VeriSign GRS no longer gives a
crap about stability. Have we forgotten *.COM so quickly?,"
Mr. Vixie conceded:

[I] was ... publicly critical of *.COM and *.NET, butthat¡Çs a
policy problem, not an operational problem. [V]eriSign has a
very good record for name server uptime both at the TLD and root
level.

[Email message posted by Paul Vixie to [EMAIL PROTECTED] dated June
17, 2004 (emphasis added). A copy of this email is attached as
Exhibit H.]

anyway, the whole thing is worth reading, and not just for history buffs.

(and if the idea that kc or woolf could be depended upon to parrot
somebody else's point of view caused you to laugh so hard you spewed
coffee all over your keyboard while reading the above tidbits, then
send the repair bill to verisign, not me.  i'm just the messenger.)

Re: Verisign vs. ICANN

2004-06-21 Thread Alexei Roudnev

Title: Re: Verisign vs. ICANN

Thanks, Dickson - next time I'll try to write exact text
from the very beginniong -:). This is _exactly_ what I want to say, with
examples I was too lazy to write myself.

To make Alexei's argument's syntax agree with the intended
semantics:
He means to say, "Technically, there is no grounds for
implementing SiteFinder by means of inserting
wildcards to the .com and .net zones. Rather, there are specific grounds for *not* inserting wildcards, regardless of the
purpose of those wildcards, in .net and .com
zones.
(E.g.: in contrast with .museum zone, which is generally
special-purpose, and for which assumptions about which
services are expected (www only) are reasonable and
valid, the .com and .net zone are general-purpose, and
pretty much any service, including all assigned values for TCP and UDP
ports from the IANA, should and must be presumed to be used
across the collection of IPv4 space.)
The crux of the problem appears in a particular case, for
which *no* workaround exists, and for which no workaround *can* exist, from a
straight derivational logic of state-machine origins.
The DNS *resolver* system, is only one of the places where the
global namespaces is *implemented*.
Any assigned DNS name *may* be placed into the
DNS. And *only* the owner of that name has authority to register that name, or
cause its value to return from any query.
An assigned name, however, can *also*, or even *instead* of
being placed into the DNS *resolver* system, be put
into other systems for resolving and returning name->address mappings.
These include: the predecessor to BIND, which is the archaic "/etc/hosts"
file(s) on systems; Sun's NIS or NIS+ systems (local to any NIS/NIS+ domain
space); LDAP and similar systems; X.500 (if this is by any chance distinct
from LDAP - I'm no expert on either); and any other arbitrary system for
implementing name->address lookups.
And the primary reason for *REQUIRING* NXDOMAIN
results in DNS, is that in any host system which queries multiple sources,
only a negative response on a lookup will allow the search to continue to the
next system in the search order.
Implementing root-zone wildcards, places restrictions on both
search-order, and content population, of respective name-resolution systems,
which violates any combination of RFCs and best-common practices.
And, most importantly, *cannot* be worked around,
*period*.
Until the RFCs are extended to permit population of zones with
authoritative *negative* information, and all the servers and resolvers
implement support for such, *and* operators of root zone databases
automatically populate assigned zones with such negative values, wildcards
*will* break, in unreconcileable fashion, existing, deployed systems which
refer to multiple implementations of zone information services, and for which
*no* workaround is possible.
Apologies for a long, semi-on-topic post. Hopefully this will
end this thread, and maybe even put a stake through the heart of the VeriSign
filing (at least this version of it). While the law generally doesn't
recognize mathematically excluded things as a matter of law, when it comes to
affirmative testimony, counter-arguments can demonstrably be shown as de-facto
purgury (sp?).
Brian Dickson (who has had to deploy
systems in heterogeneous environments, and is aware of
deployed systems that broke because of *.com)

Re: Verisign vs. ICANN

2004-06-21 Thread Dickson, Brian

Title: Re: Verisign vs. ICANN

Stephen J. Wilcox (SJW) wrote:
SJW> I do not believe there is any technical spec prohibiting this,
SJW> in fact that DNS can use a wildcard at any level is what enables
SJW> the facility.

It is not always the case that everything a spec defines, is included
or enumerated in the spec, particularly when specs refer to other specs
and it is the combination(s) of specs which define proper behaviour.

(If every protocol which was built on TCP, had to also include the contents
of the TCP spec, the whole RFC system would quicly collapse under its own
weight.)

SJW> I think this is a non-technical argument..
SJW> altho it was demonstrated that owing to the age and status of the com/net
SJW> zones a number of systems are now in operation which make
SJW> assumptions about the response in the event of the domain not existing...

If it were merely an *internal* issue *within* the DNS system, perhaps there
would be areas of disagreement which could be settled via either extending,
or clarifying, the relevant RFCs. However, the issue is, to some degree,
actually outside of the proper scope of the DNS lookup/resolver system.
(see below...)

On Sat, 19 Jun 2004, Alexei Roudnev (AR) wrote:
AR> The technical roots of the problem are: proposed services VIOLATES
AR> internet specification (which is 100% clean - if name do not exist,
AR> resolver must receive negative response).
AR> So, technically, there is not any ground for SiteFinder - vice versa

To make Alexei's argument's syntax agree with the intended semantics:

He means to say, "Technically, there is no grounds for implementing SiteFinder
by means of inserting wildcards to the .com and .net zones. Rather, there
are specific grounds for *not* inserting wildcards, regardless of the purpose
of those wildcards, in .net and .com zones.

(E.g.: in contrast with .museum zone, which is generally special-purpose,
and for which assumptions about which services are expected (www only)
are reasonable and valid, the .com and .net zone are general-purpose,
and pretty much any service, including all assigned values for TCP and UDP
ports from the IANA, should and must be presumed to be used across the
collection of IPv4 space.)

The crux of the problem appears in a particular case, for which *no* workaround exists, and for which no workaround *can* exist, from a straight derivational logic of state-machine origins.

The DNS *resolver* system, is only one of the places where the global namespaces is *implemented*.

Any assigned DNS name *may* be placed into the DNS. And *only* the owner of that name has authority to register that name, or cause its value to return from any query.

An assigned name, however, can *also*, or even *instead* of being placed into
the DNS *resolver* system, be put into other systems for resolving and returning name->address mappings. These include: the predecessor to BIND, which is the archaic "/etc/hosts" file(s) on systems; Sun's NIS or NIS+ systems (local to any NIS/NIS+ domain space); LDAP and similar systems; X.500 (if this is by any chance distinct from LDAP - I'm no expert on either); and any other arbitrary system for implementing name->address lookups.

And the primary reason for *REQUIRING* NXDOMAIN results in DNS, is that in any host system which queries multiple sources, only a negative response on a lookup will allow the search to continue to the next system in the search order.

Implementing root-zone wildcards, places restrictions on both search-order, and content population, of respective name-resolution systems, which violates any combination of RFCs and best-common practices.

And, most importantly, *cannot* be worked around, *period*.

Until the RFCs are extended to permit population of zones with authoritative *negative* information, and all the servers and resolvers implement support for such, *and* operators of root zone databases automatically populate assigned zones with such negative values, wildcards *will* break, in unreconcileable fashion, existing, deployed systems which refer to multiple implementations of zone information services, and for which *no* workaround is possible.

Apologies for a long, semi-on-topic post. Hopefully this will end this thread, and maybe even put a stake through the heart of the VeriSign filing (at least this version of it). While the law generally doesn't recognize mathematically excluded things as a matter of law, when it comes to affirmative testimony, counter-arguments can demonstrably be shown as de-facto purgury (sp?).

Brian Dickson
(who has had to deploy systems in heterogeneous environments, and is aware
of deployed systems that broke because of *.com)

Re: Verisign vs. ICANN

2004-06-20 Thread Alexei Roudnev


Hmm; this is technical argument. If you request bookk.com domain, and such
domain do not exists, you must know it.
if you wish to get 'best match', your can programm client to ask something
like

  bookk.com-search

or

  bookk.com-search.microsoft.com

or

  bookk.com-search-in-russian.relcom.net

(additional service).

Notice, that unwanted service (search in Verisign) violates ALL this cases,
making impossible flexible,
competitive processing of such requests,

Just again - DNS design, by RFC, do not include someone who thinks for you
and guess, whcih exactly name are you requesting. I request 'A for
bookk.com' , answer may be 'This is it' or 'NOT, DO NOT EXISTS' only.

 So, this is not political - this is technical ; Verisign wish to violate
Internet, ICANN refuse to allow it, Verisign get angry and pay for shameless
lawyers (no one lawyer can be shamefull).

Other items from this lawsuite may have another classification (I did not
investigate), but for 'name guess' service, it is 100% clean - this is
violation. Internet is based on numerous compromises (such as TCP slow tart)
and numerous rules (such as DNS resolver, MTU size, AS path propogation and
so on) and it is very unwise to allow commercial company violate any rule
without overall agreement.

The best solution, btw, could be to dismiss Verisign as a .COM registry -
they was granted a permission to register, violate rules, so what.. no
permission anymore. Unfortuinately, this is too unrealistic by political
reasons. ICANN is nort obligated to grant this permission to Verisign
specifically.

> Hi Alexei,
>  I do not believe there is any technical spec prohibiting this, in fact
that DNS
> can use a wildcard at any level is what enables the facility. I think this
is a
> non-technical argument.. altho it was demonstrated that owing to the age
and
> status of the com/net zones a number of systems are now in operation which
make
> assumptions about the response in the event of the domain not existing...
>
> Steve
>
> On Sat, 19 Jun 2004, Alexei Roudnev wrote:
>
> >
> > (read it only today, so sorry if I repeat something).
> >
> > The technical roots of the problem are: proposed services VIOLATES
internet
> > specification (which is 100% clean - if name do not exist, resolver must
> > receive negative response). So, technically, there is not any ground for
> > SiteFinder - vice versa,
> > now you can add client-level search SiteFinder (MS did it, and it took
LOONG
> > to turn off their dumb 'search' redirect) so allowing
> > competition between ISP, browsers and so on.
> >
> > Anyway, please - those who knows history and can read this 'official'
> > English (little bored) - I am sure, that we can find many
inconsistencies in
> > the filing; it may be reasonable to provide a set of independent
_technical_
> > reviews, showing that ICANN plays a role of technical authority, just do
not
> > allowing to violate a protocols. For the second case (waiting lists), it
is
> > not technical issue, but it is anti-competitional attempt from Verisign
as
> > well. I can ask my Russian folks to review it as well (dr. Platonov,
Dimitry
> > Burkov) but I am not sure, if it is of any use... Anyway, good review,
> > explaining history and revealing real ICANN role, should be done.
> >
> > If VeriSign wish to deploy services - they must put thru new RFC first.
> >
> > PS. I am excited - Vixie as a co-conspirator... Vixie, you can be
proud -:).
> >
> > Alexei Roudnev
> >
> >
> >
> >
> > >
> > > PV> Date: 18 Jun 2004 05:58:00 +
> > > PV> From: Paul Vixie
> > >
> > > PV> Paul Vixie is an existing provider of competitive services
for
> > > PV> registry operations, including providing TLD domain name
> > hosting
> > > PV> services for ccTLDs and gTLDs, and a competitor of
VeriSign
> > for
> > > PV> new registry operations.  [...]
> > >
> > > I'm missing something.  By what stretch of whose imagination does
> > > root nameserver operations compete with a registrar?
> > >
> > >
> > > Eddy
> > > --
> > > EverQuick Internet - http://www.everquick.net/
> > > A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
> > > Bandwidth, consulting, e-commerce, hosting, and network building
> > > Phone: +1 785 865 5885 Lawrence and [inter]national
> > > Phone: +1 316 794 8922 Wichita
> > > _
> > > DO NOT send mail to the following addresses:
> > > [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
> > > Sending mail to spambait addresses is a great way to get blocked.
> > >
> > >
> >
> >
>

Re: Verisign vs. ICANN

2004-06-19 Thread Stephen J. Wilcox


Hi Alexei,
 I do not believe there is any technical spec prohibiting this, in fact that DNS 
can use a wildcard at any level is what enables the facility. I think this is a 
non-technical argument.. altho it was demonstrated that owing to the age and 
status of the com/net zones a number of systems are now in operation which make 
assumptions about the response in the event of the domain not existing...

Steve

On Sat, 19 Jun 2004, Alexei Roudnev wrote:

> 
> (read it only today, so sorry if I repeat something).
> 
> The technical roots of the problem are: proposed services VIOLATES internet
> specification (which is 100% clean - if name do not exist, resolver must
> receive negative response). So, technically, there is not any ground for
> SiteFinder - vice versa,
> now you can add client-level search SiteFinder (MS did it, and it took LOONG
> to turn off their dumb 'search' redirect) so allowing
> competition between ISP, browsers and so on.
> 
> Anyway, please - those who knows history and can read this 'official'
> English (little bored) - I am sure, that we can find many inconsistencies in
> the filing; it may be reasonable to provide a set of independent _technical_
> reviews, showing that ICANN plays a role of technical authority, just do not
> allowing to violate a protocols. For the second case (waiting lists), it is
> not technical issue, but it is anti-competitional attempt from Verisign as
> well. I can ask my Russian folks to review it as well (dr. Platonov, Dimitry
> Burkov) but I am not sure, if it is of any use... Anyway, good review,
> explaining history and revealing real ICANN role, should be done.
> 
> If VeriSign wish to deploy services - they must put thru new RFC first.
> 
> PS. I am excited - Vixie as a co-conspirator... Vixie, you can be proud -:).
> 
> Alexei Roudnev
> 
> 
> 
> 
> >
> > PV> Date: 18 Jun 2004 05:58:00 +
> > PV> From: Paul Vixie
> >
> > PV> Paul Vixie is an existing provider of competitive services for
> > PV> registry operations, including providing TLD domain name
> hosting
> > PV> services for ccTLDs and gTLDs, and a competitor of VeriSign
> for
> > PV> new registry operations.  [...]
> >
> > I'm missing something.  By what stretch of whose imagination does
> > root nameserver operations compete with a registrar?
> >
> >
> > Eddy
> > --
> > EverQuick Internet - http://www.everquick.net/
> > A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
> > Bandwidth, consulting, e-commerce, hosting, and network building
> > Phone: +1 785 865 5885 Lawrence and [inter]national
> > Phone: +1 316 794 8922 Wichita
> > _
> > DO NOT send mail to the following addresses:
> > [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
> > Sending mail to spambait addresses is a great way to get blocked.
> >
> >
> 
>

Re: Verisign vs. ICANN

2004-06-19 Thread Alexei Roudnev


(read it only today, so sorry if I repeat something).

The technical roots of the problem are: proposed services VIOLATES internet
specification (which is 100% clean - if name do not exist, resolver must
receive negative response). So, technically, there is not any ground for
SiteFinder - vice versa,
now you can add client-level search SiteFinder (MS did it, and it took LOONG
to turn off their dumb 'search' redirect) so allowing
competition between ISP, browsers and so on.

Anyway, please - those who knows history and can read this 'official'
English (little bored) - I am sure, that we can find many inconsistencies in
the filing; it may be reasonable to provide a set of independent _technical_
reviews, showing that ICANN plays a role of technical authority, just do not
allowing to violate a protocols. For the second case (waiting lists), it is
not technical issue, but it is anti-competitional attempt from Verisign as
well. I can ask my Russian folks to review it as well (dr. Platonov, Dimitry
Burkov) but I am not sure, if it is of any use... Anyway, good review,
explaining history and revealing real ICANN role, should be done.

If VeriSign wish to deploy services - they must put thru new RFC first.

PS. I am excited - Vixie as a co-conspirator... Vixie, you can be proud -:).

Alexei Roudnev




>
> PV> Date: 18 Jun 2004 05:58:00 +
> PV> From: Paul Vixie
>
> PV> Paul Vixie is an existing provider of competitive services for
> PV> registry operations, including providing TLD domain name
hosting
> PV> services for ccTLDs and gTLDs, and a competitor of VeriSign
for
> PV> new registry operations.  [...]
>
> I'm missing something.  By what stretch of whose imagination does
> root nameserver operations compete with a registrar?
>
>
> Eddy
> --
> EverQuick Internet - http://www.everquick.net/
> A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
> Bandwidth, consulting, e-commerce, hosting, and network building
> Phone: +1 785 865 5885 Lawrence and [inter]national
> Phone: +1 316 794 8922 Wichita
> _
> DO NOT send mail to the following addresses:
> [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
> Sending mail to spambait addresses is a great way to get blocked.
>
>

Re: Verisign vs. ICANN

2004-06-19 Thread Paul Vixie


> Just curious.  How much would it differ from 
> 
> http://www.amazon.com/exec/obidos/redirect?tag=icannwatch-20&path=tg/detail/-/0262134128/qid%3D1041619276/sr%3D1-1
> 
> and
> 
> http://www.law.miami.edu/~froomkin/articles/icann.pdf

as i said, it can't be written by an ambulance-chaser or nobody will pay
attention.

Re: Verisign vs. ICANN

2004-06-19 Thread Peter H Salus



I will admit to only thinking about this for a few days.

However, it seems to me that the Harvard material is rather
narrowly focussed both on a temporal and on a topical level.
I am an admirer of Froomkin's essays, and have published 
at least one of them (in the distant past when Matrix News
was published).  I haven't really looked at Ruling the Root,
because I was turned off by Dave Crocker's review in IPJ.
But, anyway, as it appeared in 2002, I imagine it contains
little of the recent Verisign/Netsol "business."  However,
I should most likely give Mueller more leeway, as I really
liked his telephony book.

Peter

Re: Verisign vs. ICANN



Just curious.  How much would it differ from 

http://www.amazon.com/exec/obidos/redirect?tag=icannwatch-20&path=tg/detail/-/0262134128/qid%3D1041619276/sr%3D1-1

and

http://www.law.miami.edu/~froomkin/articles/icann.pdf

?

On Fri, 18 Jun 2004, Jonathan Slivko wrote:

> 
> Maybe try these guys?
> http://cyber.law.harvard.edu/is99/governance/love.html
> -- Jonathan
> 
> On Fri, 18 Jun 2004 15:38:50 -0700, Peter H Salus <[EMAIL PROTECTED]> wrote:
> > 
> > 
> > Paul (et al.),
> > 
> > If you can find a willing publisher and an organization
> > able to supply some funds, I would be delighted to
> > work on a "real" history of Internet "governance" since
> > RFCs 881-883.
> > 
> > (Most of the funds would be for travel, Xeroxing, etc.)
> > 
> > Peter
> > -
> > 
> > Peter H. Salus, Ph.D.   40 IH 35 N  #4A3Austin, TX 78701
> >consultant & author
> >[EMAIL PROTECTED] +1 512 478-7562
> > 
> 
> 
> 

-- 
http://www.icannwatch.org   Personal Blog: http://www.discourse.net
A. Michael Froomkin   |Professor of Law|   [EMAIL PROTECTED]
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
 -->It's warm here.<--

Re: Verisign vs. ICANN

2004-06-18 Thread Michael Froomkin - U.Miami School of Law


see http://www.icannwatch.org/article.pl?sid=04/06/18/0334236&mode=nested

On Fri, 18 Jun 2004, Jon R. Kibler wrote:

> 
> OK, I have obviously missed something here... I know that the courts
> dismissed the original complaint against ICANN, but what has happened
> since, and what is this about some conspiracy? Are they trying to say
> that users of the anti-SiteFinder BIND patch are conspirators?
> 

-- 
http://www.icannwatch.org   Personal Blog: http://www.discourse.net
A. Michael Froomkin   |Professor of Law|   [EMAIL PROTECTED]
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
 -->It's warm here.<--

Re: Verisign vs. ICANN

i've watched (or maybe helped) a thread susan didn't like morph into a
different thread that susan's probably not liking much either.  hit D now.

oh well, i warned you.

[EMAIL PROTECTED] (Ariel Biener) writes:
> ...
> This, in my own humble opinion, climbs slowly but surely to the levels of
> being ridiculous. Paul did exactly what any good vendor would do. If many
> customers or users asked for a feature, the vendor would issue the
> feature. It is the administrators choice to use the feature. As such, it
> is not the vendors fault in any way.

verisign's first amended complaint (now reachable at www.icann.org, i'm told)
does not mention BIND or patches to BIND at all.  but For The Record, it was
not simply end-user demand that drove "the wildcard patch".  end-users have
often asked for things that were protocol violations and been told "no" --
for example, the alternate root whackos with their "multiple root patches".
of course BIND is very free as software goes -- it's not GPL'd or anything --
so it's perfectly forkable as codebases go.  ISC cherishes its relevance,
and the thing that caused "the wildcard patch" to be published was the very
real threat by several very credible people to fork BIND unless there was
an official patch "Real Soon Now".  THAT is why there was a "wildcard patch."

[EMAIL PROTECTED] (Patrick W Gilmore) writes:
> ...
> Have the roots recurse and put a wildcard in for anything that does not
> resolve. > Makes Paul a ... well, not a competitor, 'cause that would
> imply they were in competition.  If the roots put in the wild card, the
> GTLDs cannot compete.

i have absolutely no influence over the content of the root zone.  i can't
even get an  RR added for the glue NS used by 50 or 60 TLD's.  but if i
had any influence over the root zone, i would use it to prevent a wildcard
from ever being added.  (i like my nxdomains straight up, no ice, no soda.)

[EMAIL PROTECTED] (Henry Linneweh) writes:
> ...
> It is amazing that one psrson Paul Vixie could be so intimidating that he
> must be intimidated and maligned as a conspirator in order to eliminate
> him as a potential threat because of his knowledge.

i'm not sure verisign cares whether they intimidate me or not.  they just
need to prove that a conspiracy is restraining competition, in order to
prevent their complaint against icann from being dismissed.  which means
they had to declare that somebody was a co-conspirator, and i was available.
this is not about me at all, other than by proximity -- it's about icann.
-- 
Paul Vixie

Re: Verisign vs. ICANN

2004-06-18 Thread Jonathan Slivko


Maybe try these guys?
http://cyber.law.harvard.edu/is99/governance/love.html
-- Jonathan

On Fri, 18 Jun 2004 15:38:50 -0700, Peter H Salus <[EMAIL PROTECTED]> wrote:
> 
> 
> Paul (et al.),
> 
> If you can find a willing publisher and an organization
> able to supply some funds, I would be delighted to
> work on a "real" history of Internet "governance" since
> RFCs 881-883.
> 
> (Most of the funds would be for travel, Xeroxing, etc.)
> 
> Peter
> -
> 
> Peter H. Salus, Ph.D.   40 IH 35 N  #4A3Austin, TX 78701
>consultant & author
>[EMAIL PROTECTED] +1 512 478-7562
> 


-- 
  Jonathan M. Slivko - [EMAIL PROTECTED]
"Linux: The Choice for the GNU Generation"
 - http://www.linux.org/ -

Don't fear the penguin.
 .^.
 /V\
   /(   )\
^^-^^
  He's here to help.

Re: Verisign vs. ICANN

2004-06-18 Thread Peter H Salus



Paul (et al.),

If you can find a willing publisher and an organization
able to supply some funds, I would be delighted to 
work on a "real" history of Internet "governance" since
RFCs 881-883.

(Most of the funds would be for travel, Xeroxing, etc.)

Peter
-

Peter H. Salus, Ph.D.   40 IH 35 N  #4A3Austin, TX 78701
consultant & author
[EMAIL PROTECTED] +1 512 478-7562

Re: Verisign vs. ICANN

[EMAIL PROTECTED] (Gordon Cook) writes:

> in my estimation [verisign] would like to control telecom by control of
> the numbers associated therewith.
> 
> ...
> 
> ... I am tying to stay away from this cesspool.  It brings no income -
> only grief.  But, knowing what i know, i am remiss if i don't stick my
> head up here.
> 
> I go waaa back with network solutions to 1994 actually and i keep
> damned good archives.  If I can assist Paul or the anti-verisign part of
> this case in building the details of the history of who did what to whom,
> I gladly will do so

that's an interesting offer for several reasons.  i meet many people in my
travels who weren't domainholders when the system was first commercialized
and so they do not remember any of the times network solutions overstepped
internic's charter in order to, for example, unilaterally impose new terms
in the domain change templates.  in fact most people don't know what a
domain change template was, or what internic was, or who GSI was or who SRI
was.  and without that knowledge, it's easy to mistake the icann/verisign
legal battle as "turf related".

i know of any number of nose-holding fence-sitters who only tolerate icann
(or consider icann relevant) because icann is somehow keeping verisign from
abusing their monopoly -- and who feel betrayed every time icann fails.  i
know folks who are still angry with icann and with us-DoC for ever signing
the current .COM registry agreement -- the one verisign says is too
restrictive and claims icann is violating.

there's a huge amount of history that's required before anybody should draw
conclusions or form opinions about icann or verisign.

however, it would have to be written up by someone who is not an ambulance
chaser before it could have any effect on unbiased objective observers.
-- 
Paul Vixie

Re: Verisign vs. ICANN

[EMAIL PROTECTED] (Gordon Cook) writes:

> in my estimation [verisign] would like to control telecom by control of
> the numbers associated therewith.
> 
> ...
> 
> ... I am tying to stay away from this cesspool.  It brings no income -
> only grief.  But, knowing what i know, i am remiss if i don't stick my
> head up here.
> 
> I go waaa back with network solutions to 1994 actually and i keep
> damned good archives.  If I can assist Paul or the anti-verisign part of
> this case in building the details of the history of who did what to whom,
> I gladly will do so

that's an interesting offer for several reasons.  i meet many people in my
travels who weren't domainholders when the system was first commercialized
and so they do not remember any of the times network solutions overstepped
internic's charter in order to, for example, unilaterally impose new terms
in the domain change templates.  in fact most people don't know what a
domain change template was, or what internic was, or who GSI was or who SRI
was.  and without that knowledge, it's easy to mistake the icann/verisign
legal battle as "turf related".

i know of any number of nose-holding fence-sitters who only tolerate icann
(or consider icann relevant) because icann is somehow keeping verisign from
abusing their monopoly -- and who feel betrayed every time icann fails.  i
know folks who are still angry with icann and with us-DoC for ever signing
the current .COM registry agreement -- the one verisign says is too
restrictive and claims icann is violating.

there's a huge amount of history that's required before anybody should draw
conclusions or form opinions about icann or verisign.

however, it would have to be written up by someone who is not an ambulance
chaser before it could have any effect on unbiased objective observers.
-- 
Paul Vixie

Re: Verisign vs. ICANN

2004-06-18 Thread Stephen J. Wilcox

On Fri, 18 Jun 2004, John Neiberger wrote:

> It never ceases to amaze me that some companies will move forward with actions
> that they know will give them a horrible reputation. Does the potential for
> short-term financial gain outweigh the benefits of a good long-term
> reputation? Verisign, SCO, and Postini come to mind as examples.

Hmm the volumes and costs involved are more than a short term financial gain 
imho, I'd say this represented long term large income and pretty easy money too.

(imho) I'd also say that you overestimate the bad reputation.. the nanog
community isnt that large when you consider the global market using verisign for
various services, and often commercial decisions to use verisign are made by
non-technical folks not on nanog

if i was a commercial vp at verisign, i'd probably be thinking in a similar 
manner, they are in a unique position and unique sales points means big money in 
this marketplace

Steve

(anti-flame disclaimer - i'm not a commerical person, and my logic only outlines 
the reasoning behind having as neutral a body as possible operating these kind 
of services)

Re: Postini, Re: Verisign vs. ICANN

2004-06-18 Thread Ray Wong

On Fri, Jun 18, 2004 at 08:02:34PM +, Edward B. Dreger wrote:
> 
> JN> Date: Fri, 18 Jun 2004 12:56:11 -0600
> JN> From: John Neiberger
> 
> JN> Postini's patent issue (do a Google search to get more info)
> JN> is suspicious, and _possibly_ indicative of a slimy tactic.
> 
> It does look pretty ridiculous.  ETRN, formail, procmail, Web-
> based UIs, etc. have been around far longer than Postini.

Yep, and NAT, PAT and stateful inspection exist outside of Cisco.

This "need" by already dominant players to patent everything related
to their business is unpleasant enough, but it's also common enough
to make singling anyone out as slimy to be a bit disingenuous.

I'd hazard to guess that a large number of folks on this list work
for employers with similarly "ridiculous" patents.

-- 

Ray Wong
[EMAIL PROTECTED]

Re: Verisign vs. ICANN

2004-06-18 Thread Owen DeLong


--On Friday, June 18, 2004 17:25 + Paul Vixie <[EMAIL PROTECTED]> wrote:

PV> if it's not that, then perhaps they're just smoking crack.
Still a bit of a stretch.  They receive money for registered domains (and
attempted to for unregistered domains) in the .COM and .NET namespaces.
my employer was a bidder for .ORG, and gives away EPP software ("ISC
OpenReg"), so there's some overlap with the registry/registrar community
that verisign might be thinking of.
Didn't Verisign sell off the Registrar stuff, thus making OpenReg not
a competitor?
Owen
--
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.


pgp4iitsTNykZ.pgp
Description: PGP signature

Re: Verisign vs. ICANN

2004-06-18 Thread Henry Linneweh


It is amazing that one psrson Paul Vixie could be so
intimidating that he must be intimidated and maligned
as a conspirator in order to eliminate him as a
potential threat because of his knowledge.

I find that pretty ironic that a billion dollar
corporation is that weak.

-Henry

--- Patrick W Gilmore <[EMAIL PROTECTED]> wrote:
> 
> On Jun 18, 2004, at 2:25 PM, Wayne E. Bouchard
> wrote:
> 
> >> verisign's official position throughout the
> sitefinder launch was 
> >> that "users
> >> are free to disable it if they want to."  they
> did NOT want this 
> >> characterized
> >> as them shoving their sitefinder service down
> anybody's unwilling 
> >> throat.  so
> >> i don't expect any action to occur against folks
> who installed a BIND 
> >> patch.
> >
> > Um, unless I really missed something during this
> whole episode, that
> > was the only way TO disable it.
> 
> Have the roots recurse and put a wildcard in for
> anything that does not 
> resolve.
> 
> Makes Paul a ... well, not a competitor, 'cause that
> would imply they 
> were in competition.  If the roots put in the wild
> card, the GTLDs 
> cannot compete.
> 
> -- 
> TTFN,
> patrick
> 
>

Re: Verisign vs. ICANN

2004-06-18 Thread Jon R. Kibler

Patrick W Gilmore wrote:
> 
> On Jun 18, 2004, at 2:25 PM, Wayne E. Bouchard wrote:
> 
> > Um, unless I really missed something during this whole episode, that
> > was the only way TO disable it.
> 
> Have the roots recurse and put a wildcard in for anything that does not
> resolve.
> 
> Makes Paul a ... well, not a competitor, 'cause that would imply they
> were in competition.  If the roots put in the wild card, the GTLDs
> cannot compete.
> 

Geee, we block sitefinder's ip both inbound and outbound at our border router...

I wonder what that makes us? A competitor? A conspirator? A saboteur? ???

Jon Kibler
-- 
Jon R. Kibler
Chief Technical Officer
A.S.E.T., Inc.
Charleston, SC  USA
(843) 849-8214

==
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.

Re: Postini, Re: Verisign vs. ICANN


JN> Date: Fri, 18 Jun 2004 12:56:11 -0600
JN> From: John Neiberger

JN> Postini's patent issue (do a Google search to get more info)
JN> is suspicious, and _possibly_ indicative of a slimy tactic.

It does look pretty ridiculous.  ETRN, formail, procmail, Web-
based UIs, etc. have been around far longer than Postini.

Heck, I was doing selective partial delivery in 1997 -- if a
message was addressed to an important email address, "head -n"
and pipe the output to a printer for paper-using staff to have.


Eddy
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.

Postini, Re: Verisign vs. ICANN

2004-06-18 Thread John Neiberger


>It never ceases to amaze me that some companies will move forward with
>actions that they know will give them a horrible reputation. Does the
>potential for short-term financial gain outweigh the benefits of a
good
>long-term reputation? Verisign, SCO, and Postini come to mind as
>examples. 
>
>I can't stand the current spam filtering/AV email service that we use
>right now (Mailwatch...ugh.), but should we change to Postini--a
>supposedly superior service--knowing how slimy some of their actions
>have been? That's a rhetorical question, of course, but I think it
makes
>the point. I prefer to do business with good companies with good
>products, not bad companies with good products.

Based on some offline comments I've decided to clarify my remarks. I
don't think Postini is necessarily slimy and I shouldn't have mentioned
them in the same sentence as Verisign and SCO, who are verifiably slimy.
I should have phrased my remarks differently because I don't _know_ that
Postini is slimy yet.

Postini's patent issue (do a Google search to get more info) is
suspicious, and _possibly_ indicative of a slimy tactic. However, there
may be some completely valid reasons for their actions and I suppose we
shouldn't judge them too harshly yet. Regardless of their reasons, it
gives the appearance that they're not satisfied with simple competition
and may try to negatively affect the competition through legal means. If
they do that, then they're slimy. Until then, I suppose we (I) shouldn't
make hasty judgments.

John
--

Re: Verisign vs. ICANN

2004-06-18 Thread Patrick W Gilmore

On Jun 18, 2004, at 2:25 PM, Wayne E. Bouchard wrote:
verisign's official position throughout the sitefinder launch was 
that "users
are free to disable it if they want to."  they did NOT want this 
characterized
as them shoving their sitefinder service down anybody's unwilling 
throat.  so
i don't expect any action to occur against folks who installed a BIND 
patch.
Um, unless I really missed something during this whole episode, that
was the only way TO disable it.
Have the roots recurse and put a wildcard in for anything that does not 
resolve.

Makes Paul a ... well, not a competitor, 'cause that would imply they 
were in competition.  If the roots put in the wild card, the GTLDs 
cannot compete.

--
TTFN,
patrick

Re: Verisign vs. ICANN

2004-06-18 Thread Wayne E. Bouchard


On Fri, Jun 18, 2004 at 05:58:00AM +, Paul Vixie wrote:
> 
> > > ...  i'm not a defendant, just a named co-conspirator.
> > 
> > Hah? Are they also naming individually all the dns operators that installed 
> > bind patch and specifically enabled it so that wildcards would not work?
> 
> the lawsuit doesn't mention the bind patch.  they seem to be upset about my
> work on the ICANN Security and Stability Advisory Committee.  what their
> "First Amended Complaint" says about me is that:
> 
> Paul Vixie is a Site Finder co-conspirator [...].  
> 
> Paul Vixie is an existing provider of competitive services for
> registry operations, including providing TLD domain name hosting
> services for ccTLDs and gTLDs, and a competitor of VeriSign for
> new registry operations.  [...]
> 
> (y'know, i'd pay Real Money for Adobe Acrobat Professional for SuSE 9.1/amd64,
> by which i could scan-convert PDF files instead of typing in stuff by hand --
> my win32 laptop has more than 70 days of downtime and i'm going for 3 digits.)
> 
> verisign's official position throughout the sitefinder launch was that "users
> are free to disable it if they want to."  they did NOT want this characterized
> as them shoving their sitefinder service down anybody's unwilling throat.  so
> i don't expect any action to occur against folks who installed a BIND patch.

Um, unless I really missed something during this whole episode, that
was the only way TO disable it.

---
Wayne Bouchard
[EMAIL PROTECTED]
Network Dude
http://www.typo.org/~web/

Re: Verisign vs. ICANN

2004-06-18 Thread Ariel Biener

On Thu, 17 Jun 2004, Jeff Shultz wrote:

>
> I'm having fun figuring out how altering BIND (since I assume that is
> the basis of their arguements) rises to the level of conspiracy...
> IANAL, obviously.

I read you loud and clear. I believe most rational people among us do, see
below.

Oh my, a vendor that actually listens to the cryout of its customers. That
cannot be tolerated.

This, in my own humble opinion, climbs slowly but surely to the levels of
being ridiculous. Paul did exactly what any good vendor would do. If many
customers or users asked for a feature, the vendor would issue the
feature. It is the administrators choice to use the feature. As such, it
is not the vendors fault in any way.

After the courts drop this one as well, I am curious what will be the next
Verisign idea. They (read: their lawyers) have proved themselves to be
full of bright ideas (that lead to a dead end due to irrationality), and I
am curious to see what's next.

happy sailing,

--Ariel

>
> ** Reply to message from Bob Martin <[EMAIL PROTECTED]> on Thu, 17 Jun
> 2004 16:54:20 -0500
>
> > Anything I/we can do to help the cause?
> >
> > Bob Martin
> >
> > Quoted from different thread:
> >
> >
> > >(note that verisign has amended their complaint against icann (since the
> > >court dismissed the first one) and i'm now named as a co-conspirator.if
> > >you reply to this message, there's a good chance of your e-mail appearing
> > >in court filings at some point.)
> > > -- Paul Vixie
>
> --
> Jeff Shultz
> A railfan pulls up to a RR crossing hoping that
> there will be a train.
>
>
>  +++
>  This Mail Was Scanned By Mail-seCure System
>  at the Tel-Aviv University CC.
>

--
Ariel Biener
e-mail: [EMAIL PROTECTED]
PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html

 +++
 This Mail Was Scanned By Mail-seCure System
 at the Tel-Aviv University CC.

Re: Verisign vs. ICANN

2004-06-18 Thread Vincent J. Bono


>   Also, while drastic, filing suit
> doesn't preclude adults getting together and working out the the matter
> before  anything makes it to court.

Having been a part of a few large lawsuits here, I can say that many judges
will force at least a conversation between signatories of both parties (not
just attorney's) before getting to trial.  It even helps sometimes.

-v

Re: Verisign vs. ICANN


PV> Date: 18 Jun 2004 17:25:08 +
PV> From: Paul Vixie

PV> my employer was a bidder for .ORG, and gives away EPP
PV> software ("ISC OpenReg"), so there's some overlap with the
PV> registry/registrar community that verisign might be thinking
PV> of.

I don't know about OpenReg, and can't comment on it.  Bidding for
.ORG still doesn't make sense -- if my employer makes a bid for
Ford, which doesn't go through, are we suddenly competing with
GM?  (No, we don't make cars.)


Eddy
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.

Re: Verisign vs. ICANN

2004-06-18 Thread John Curran

At 10:34 AM -0600 6/18/04, John Neiberger wrote:
>
>It never ceases to amaze me that some companies will move forward with
>actions that they know will give them a horrible reputation.

Hmm...  I'm not going to try to defend Verisign (or ICANN for that matter),
but will note that the decision to engage in litigation is often not optional... 

In many areas of law, failure to act to diligently against infringement can
effectively preclude you from pursuing legal recourse in the future.  So,
companies can find easily find themselves having to file legal actions
simply to maintain their right to do so.  Also, while drastic, filing suit
doesn't preclude adults getting together and working out the the matter
before  anything makes it to court.   It's legal action without any real
meaningful attempt to meet and settle in advance which deserves a
bad reputation.

/John

Re: Verisign vs. ICANN


> PV> if it's not that, then perhaps they're just smoking crack.
> 
> Still a bit of a stretch.  They receive money for registered domains (and
> attempted to for unregistered domains) in the .COM and .NET namespaces.

my employer was a bidder for .ORG, and gives away EPP software ("ISC
OpenReg"), so there's some overlap with the registry/registrar community
that verisign might be thinking of.
-- 
Paul Vixie

Re: Verisign vs. ICANN


PV> Date: 18 Jun 2004 16:44:41 +
PV> From: Paul Vixie

PV> i think they mean ns-ext.isc.org (or its old name, ns-ext.vix.com),
PV> which offers "TLD hosting" without fee to about 60 domains:

[ snip ]

PV> if it's not that, then perhaps they're just smoking crack.

Still a bit of a stretch.  They receive money for registered
domains (and attempted to for unregistered domains) in the .COM
and .NET namespaces.  If you're offering the same, you've done a
very poor job capturing market share. ;)

Although IMHO not related due to differences in service
offerings, this reminds me of Microsoft's argument that, although
Sun and Corel had hardly any market share, they were competitors.
Has there ever been any official ruling on size requirements for
one to be considered competition?


Eddy
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.

Re: Verisign vs. ICANN


> PV> Paul Vixie is an existing provider of competitive services for
> PV> registry operations, including providing TLD domain name hosting
> PV> services for ccTLDs and gTLDs, and a competitor of VeriSign for
> PV> new registry operations.  [...]
> 
> I'm missing something.  By what stretch of whose imagination does
> root nameserver operations compete with a registrar?

i think they mean ns-ext.isc.org (or its old name, ns-ext.vix.com), which
offers "TLD hosting" without fee to about 60 domains:

   % awk '/^zone/ { print $2 }' slave_tld.zones | sed 's/"//g' | fmt
   ac ae ao bg br com.br ca cd cl cz cv gov.fj fr hn hr io il ac.il co.il
   gov.il k12.il muni.il net.il org.il in co.in ernet.in org.in ac.in
   res.in gov.in mil.in net.in firm.in gen.in ind.in is museum md na com.na
   nl np com.np edu.np org.np mil.np net.np gov.np nr biz.nr com.nr edu.nr
   gov.nr info.nr net.nr org.nr pt ro sh tm za si sk co.zw aq pn ug

if it's not that, then perhaps they're just smoking crack.

(note for TLD folks... we're trying to collect the whole set, we're missing
the last 200 or so, give us a call, tsig preferred.)
-- 
Paul Vixie

Re: Verisign vs. ICANN


EBD> Date: Fri, 18 Jun 2004 16:16:07 + (GMT)
EBD> From: Edward B. Dreger

EBD> I'm missing something.  By what stretch of whose imagination
EBD> does root nameserver operations compete with a registrar?

Apologies for replying to my own post.  I just had a [sinister]
thought:  I've typed ".cmo" a few times when using a qwerty
keyboard.  Does NetSol think it has some strange exclusive right
to hijack TLDs, too?


Eddy, who wonders if NetSol will "do the SCOX thing" shortly
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.

Re: Verisign vs. ICANN

2004-06-18 Thread John Neiberger


>>OK, I have obviously missed something here... I know that the courts
dismissed
>> the original complaint against ICANN, but what has happened since,
and what i
>>s this about some conspiracy? Are they trying to say that users of
the anti-Si
>>teFinder BIND patch are conspirators?
>
>No -- but the easiest thing to do is to read the amended complaint, 
>which is linked-to from ICANN's home page.

It never ceases to amaze me that some companies will move forward with
actions that they know will give them a horrible reputation. Does the
potential for short-term financial gain outweigh the benefits of a good
long-term reputation? Verisign, SCO, and Postini come to mind as
examples. 

I can't stand the current spam filtering/AV email service that we use
right now (Mailwatch...ugh.), but should we change to Postini--a
supposedly superior service--knowing how slimy some of their actions
have been? That's a rhetorical question, of course, but I think it makes
the point. I prefer to do business with good companies with good
products, not bad companies with good products.

John
--

Re: Verisign vs. ICANN

2004-06-18 Thread Steven M. Bellovin


In message <[EMAIL PROTECTED]>, "Jon R. Kibler" writes:
>

>
>OK, I have obviously missed something here... I know that the courts dismissed
> the original complaint against ICANN, but what has happened since, and what i
>s this about some conspiracy? Are they trying to say that users of the anti-Si
>teFinder BIND patch are conspirators?

No -- but the easiest thing to do is to read the amended complaint, 
which is linked-to from ICANN's home page.


--Steve Bellovin, http://www.research.att.com/~smb

Re: Verisign vs. ICANN