|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Architectural issues involving Sitefinder & related functions
(since I haven't gotten back my enrollment confirmation, it seemed appropriate to crosspost this to NANOG. While I will address Sitefinder, there are broader architectural and operational issues). Let me assume, for the sake of this discussion, that Sitefinder is an ideal tool for the Web user, helping with the problem of not-quite-correct URLs. Given that, I'll stipulate in this discussion that the implementation of Sitefinder, along with the .com and .net wildcards that lead to it for unresolved domains, is a true benefit for the Web user. The Internet, however, is more than the World-Wide Web. It seems only logical to be able to discuss Sitefinder in two contexts: 1. Where it becomes the default, as with the recent Verisign wildcards 2. Where it is reached in some other manner. My architectural concern is defining a way in which context #1 serves the _non-Web_ services of the Internet. If DNS were purely an information service for Web users, the architectural conflict would go away, and only commercial and policy issues remain. I would hope that within the scope of the Sitefinder discussion list, or alternatively in another forum, is an approach to reconciling the IP-level DNS such that it continues to serve non-Web applications. Is there disagreement that Sitefinder provides no functionality to SMTP trying to deliver to an unresolved domain? To a user who mistypes the name of an FTP site and does not intend to use a Web browser? What about failover schemes for non-HTTP cooperative research across the Internet, where the inability to resolve a host name (assume that cached records have a zero lifetime) triggers selection of an alternate server? Seriously, technical people at Verisign may have thought about this and actually have suggestions. They may be very good ones, but, judging on the reactions to the Sitefinder deployment, it might be well to discuss them in open technical forums before a change is made. I'm really not trying to make it a matter of personalities, but there have been public statements by Verisign executives that such a process inhibits innovation. If Verisign policy is that as operator of .com and .net, it has the right to make unilateral changes, I think that needs to be clear to all concerned. I recognize that a number of independent parties suggest that the ICANN contract does not explicitly prohibit such unilateral action. Ironically, I worked with the original founders of Network Solutions, and almost was a principal back when it was a couple of rooms in McLean. Gary Desler, the founder and a fine engineer, always used to say "there is no technical solution to a management problem". In the current context, I simply want to know the rules for the playing field.
|