Issues

The following issues must be considered:

• Transition issues. In general, it is difficult to build new infrastructure in the Internet, because the infrastructure must be in place before its costs can be justified by its benefits.
• Security and Survivability. It is difficult to provide network services that are immune to hostile attack or accidental damage. Doing so requires careful attention to the operation of the server machines, the ability to detect possible problems, and sufficient logging to analyze security breaches and recover from file loss or corruption.
• Consistency. Consistency models for replicated data range from strict one-copy serializability [1] to a best-effort, eventual convergence model. Because of the high overhead of maintaining strict consistency, most distributed databases and file replication schemes deployed on the Internet, such as the Domain Name System, use looser consistency models. However, some applications, for example an automatic program builder that retrieves software components from distributed sites and constructs an executable suitable for the user's platform, may require stricter consistency.
• DNS. There are both advantages and disadvantages to using the Domain Name System as a component of a resource cataloging system. On the positive side, DNS is widely deployed and implementations are already available for most platforms. On the negative side, DNS is known to be insecure against attack, to have problems with stale data, to have difficulty tolerating domains with a large fan-out (such as the .COM domain), and to be easy to misconfigure. All but the last of these problems are being addressed by IETF working groups, and similar issues would be encountered in any other widely distributed database.

The assumed significance of transition issues on the success of the project influenced our design in the following ways: (a) we allow ordinary URLs as one kind of resource name, (b) we use existing file servers and file access protocols, and (c) we employ DNS as a component of the system rather than building a new distributed database from the ground up.

The need for reliable authentication and integrity assurances, coupled with the difficulty of providing secure servers, prompted us to use end-to-end (between information provider and user) authentication, consisting of public-key signatures and cryptographically signed certificates, rather than depending on the security of resource catalog servers or file servers (though reasonable security for these is still required to thwart denial-of-service attacks).

We have implemented a flexible consistency model which combines a convergence based peer update protocol for resource locations with a stricter token-based protocol for catalog information.

Finally, some of the inherent limitations of DNS and the desire to separate administration of ``naming authority'' names from administration of resource names for a particular naming authority, led us to use DNS only as a means to identify one or more resource catalog servers for a particular resource naming authority, rather than to provide resource location or catalog information directly through DNS.