<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: Verisign vs. ICANN</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>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.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2></FONT> </DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P><FONT size=2>To make Alexei's argument's syntax agree with the intended 
  semantics:</FONT> </P>
  <P><FONT size=2>He means to say, "Technically, there is no grounds for 
  implementing SiteFinder</FONT> <BR><FONT size=2>by means of inserting 
  wildcards to the .com and .net zones. Rather, there</FONT> <BR><FONT 
  size=2>are specific grounds for *not* inserting wildcards, regardless of the 
  purpose</FONT> <BR><FONT size=2>of those wildcards, in .net and .com 
  zones.</FONT> </P>
  <P><FONT size=2>(E.g.: in contrast with .museum zone, which is generally 
  special-purpose,</FONT> <BR><FONT size=2>and for which assumptions about which 
  services are expected (www only)</FONT> <BR><FONT size=2>are reasonable and 
  valid, the .com and .net zone are general-purpose,</FONT> <BR><FONT size=2>and 
  pretty much any service, including all assigned values for TCP and UDP</FONT> 
  <BR><FONT size=2>ports from the IANA, should and must be presumed to be used 
  across the</FONT> <BR><FONT size=2>collection of IPv4 space.)</FONT> </P>
  <P><FONT size=2>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.</FONT></P>
  <P><FONT size=2>The DNS *resolver* system, is only one of the places where the 
  global namespaces is *implemented*.</FONT> </P>
  <P><FONT size=2><STRONG><EM>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.</EM></STRONG></FONT></P>
  <P><FONT size=2>An assigned name, however, can *also*, or even *instead* of 
  being placed into</FONT> <BR><FONT size=2>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.</FONT></P>
  <P><FONT size=2><STRONG><EM>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.</EM></STRONG></FONT></P>
  <P><FONT size=2>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.</FONT></P>
  <P><STRONG><EM><FONT size=2>And, most importantly, *cannot* be worked around, 
  *period*.</FONT> </EM></STRONG></P>
  <P><FONT size=2>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.</FONT></P>
  <P><FONT size=2>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?).</FONT></P>
  <P><FONT size=2>Brian Dickson</FONT> <BR><FONT size=2>(who has had to deploy 
  systems in heterogeneous environments, and is aware</FONT> <BR><FONT size=2>of 
  deployed systems that broke because of *.com)</FONT> 
</P></BLOCKQUOTE></BODY></HTML>