nanog mailing list archives
Re: Verisign vs. ICANN
From: "Alexei Roudnev" <alex () relcom net>
Date: Sun, 20 Jun 2004 19:35:18 -0700
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 RoudnevPV> Date: 18 Jun 2004 05:58:00 +0000 PV> From: Paul Vixie PV> Paul Vixie is an existing provider of competitive services
for
PV> registry operations, including providing TLD domain namehostingPV> services for ccTLDs and gTLDs, and a competitor of
VeriSign
forPV> 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: davidc () brics com -*- jfconmaapaq () intc net -*- sam () everquick net Sending mail to spambait addresses is a great way to get blocked.
Current thread:
- Re: Verisign vs. ICANN, (continued)
- Re: Verisign vs. ICANN Paul Vixie (Jun 17)
- Re: Verisign vs. ICANN Edward B. Dreger (Jun 18)
- Re: Verisign vs. ICANN Edward B. Dreger (Jun 18)
- Re: Verisign vs. ICANN Paul Vixie (Jun 18)
- Re: Verisign vs. ICANN Edward B. Dreger (Jun 18)
- Re: Verisign vs. ICANN Paul Vixie (Jun 18)
- Re: Verisign vs. ICANN Edward B. Dreger (Jun 18)
- Re: Verisign vs. ICANN Owen DeLong (Jun 18)
- Re: Verisign vs. ICANN Alexei Roudnev (Jun 19)
- Re: Verisign vs. ICANN Stephen J. Wilcox (Jun 19)
- Re: Verisign vs. ICANN Alexei Roudnev (Jun 20)
- Re: Verisign vs. ICANN Wayne E. Bouchard (Jun 18)
- Re: Verisign vs. ICANN Patrick W Gilmore (Jun 18)
- Re: Verisign vs. ICANN Jon R. Kibler (Jun 18)
- Re: Verisign vs. ICANN Henry Linneweh (Jun 18)
- Re: Verisign vs. ICANN Paul Vixie (Jun 18)
- Re: Verisign vs. ICANN Steven M. Bellovin (Jun 18)
- Re: Verisign vs. ICANN Michael Froomkin - U.Miami School of Law (Jun 18)
- Re: Verisign vs. ICANN David Lesher (Jun 18)