- From: Keith Moore <moore@cs.utk.edu>
- Date: Fri, 16 Jun 1995 13:22:14 -0400
- To: Michael.Mealling@oit.gatech.edu (Michael Mealling)
- Cc: mshapiro@ncsa.uiuc.edu (Michael Shapiro), uri@bunyip.com, moore@cs.utk.edu
> 1. Existing DNS servers are already loaded trying to deal with the existing > namespace. A new port would seperate the load so that if the existing > DNS space becomes to loaded in the future it does not affect the URN > namespace and vice versa. Huh? If you run two servers on the same machine, they both contribute to the load on that system. If you run them on different hosts, it's not a problem. > 2. DNS server trees often do not correspond very well to the trees needed > for information hierarchies. A seperate port would allow the two DNS > trees to coexist but not comingle. Depends on how the naming authorities are defined. If a decision is made to use DNS, we would define naming authority names in such a way as to work well with DNS. > 3. DNS servers are optimized for an extremely flat namespace (look at > all the .com domains with no subdomains). A new namespace could > potentially have a much different organization and hence caching requirments. I wouldn't say that DNS servers are optimized for this case so much as that they've had to deal with it. The current burden in .com clearly stretches the originally anticpiated use of DNS; else they would have designed in incremental update from day one. Anyway, whether to run different server code is a separate issue than whether to use a different port. For the near term at least, it would be nice to be able to use vanilla named. > 4. In order for URNs to be 'public'. I.E. we allow anyone to publish, not > just those that have an in with the system admins; we need the URN > resolution process to be able to take place on non privilidged ports. Not if we separate the process of *location* of a resolution service from the resolution service itself. DNS will do just fine for the former; not nearly so well for the latter. > 5. It gives us a much much easier upgrade path in the future without > affecting existing systems. We can have easy upgrade now, or later. We know what our current needs are. How well can we anticipate our needs even a few years from now? Anyway, if we use DNS only for location of the resolution service, we can easily add additional resolution services (protocols) later. So we still have an upgrade path. Keith
Received on Friday, 16 June 1995 13:21:44 UTC