RFC 3254

Definitions for talking about directories

📅 published April 2002, from ietf

RFC 3254: Definitions for talking about directories 🎀

Okay bestie, RFC 3254 is written by H. Alvestrand from Cisco Systems 💅 It's from the Network Working Group and dated April 2002. The category is Informational, so it's giving info, not a standard 🫶 The header doesn't list anything it obsoletes or updates, so there's no drama there ✨

Status of this Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🦋

So when people talk about systems that make information reachable across the Internet in standardized ways, it helps if everyone in the conversation means the same thing by the terms they use 🧚

For example, if you cite this document, you can all agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency 👑 Meanwhile an LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability 💜

This document talks about one group of these systems, known as "directories" 📚

1. Introduction and basic terms 🌸

We suggest using these terms for the rest of the document:

  • Information: Facts and ideas that can be represented (encoded) as data in various forms.
  • Data: Information in a specific physical representation, usually a sequence of symbols that have meaning. It's especially a representation of information that a computer can process or produce. (From [SEC].)
  • Repository: An amount of data that is accessible through one or more access methods.
  • Requester: An entity that may (try to) access data in a repository. No assumption is made that the requester is animal, vegetable, or mineral 🙈
  • Maintainer: An entity that causes changes to the data in the repository. Usually all maintainers are requesters, since they need to look at the data too, but the roles are still distinct.
  • Access method: A well-defined series of operations that causes data available from a repository to be obtained by the requester.
  • Site: An entity that hosts all or part of a repository and makes it available through one or more access methods. In various contexts, a site may be a machine, a datacenter, a network of datacenters, or a single device 🍓

This document is not meant to be comprehensive or definitive. It's meant to help everyone understand each other when talking about information access methods that get built into Internet Standards-Track documents ✨

2. Dimensions of classification 👑

2.1 Uniqueness and scope 🍓

Some information systems are global, in the sense that only one of them can sensibly exist in the world 🌍

Others are inherently local. Each locality, site, or even box runs its own information store, independent of all the others 🏠

The following terms are suggested:

  • Global repository: A repository that there can be only one of in the world. The world itself is a prime example. The public telephone system's number assignments under E.164 are another.
  • Local repository: A class of repository where multiple instances can exist, each holding information relevant to that particular repository, with no need for coordination between them.
  • Centralized repository: A repository where all access to data has to pass through some single site.
  • Distributed repository: A repository that is not centralized. Access to data can happen through multiple sites.
  • Replicated repository: A distributed repository where all sites have the same information.
  • Cooperative repository: A distributed repository where not all sites have all the information, but mechanisms exist to get the info to the requester, even when it isn't available at the site originally asked.

Note: The term "global" is often a matter of social or legal context. For instance, the E.164 telephone numbering system is global by international treaty. Meanwhile, the debate about whether the Domain Name System is truly global, or just a local repository with ambitions, has proved to be bait for too many discussions to list 🙈

Some people claim globality is in the eye of the beholder, since "everything is local to some context." When talking about technology, it may be wise to say "very widely deployed" instead 💅

Note: Where the repositories are located changes with the scale you're looking at. For instance, the global DNS is considered a distributed cooperative repository. It's built out of zone repositories that may themselves be distributed, and distributed zone repositories are always replicated 🧚

2.2 Search, Lookup, Query and Notify 🔥

Another thing to consider when describing repositories is the types of method they offer for finding information 🔍

The main classifications are:

  • Lookup methods require the user to know or guess some exact value before asking for information. This is sometimes called a "lookup key" or "identifier," and sometimes a "name." The word "name" is NOT recommended, since it conflicts with other uses of that word. The response to a successful lookup is a single group of information, often called "information about the identified entity." A lookup method is binary (yes/no) in recall. It either returns one result or no result. If it does return a result, that result is the right one for that lookup key, so it's also binary in precision (no info, or completely relevant info) 💖
  • Search methods require the user to know some approximate value of some information. They usually return zero, one, or more responses that match the information supplied, according to some algorithm. Where the repository is structured around "entities," the information can be about zero, one, or many entities 🦋

In database terms, a lookup method corresponds to a query that exactly matches a unique key on a table. All other database queries would be classified as "search" methods 🌸

Generally, repositories that offer more flexible search methods may also make room for ad-hoc queries, refinements of a previous query, approximate matching, and other aids. This can lead to many different combinations of precision and recall 🎀

You can define terms to list what you get out of these repositories:

  • Precision is the degree to which what you asked for is what you wanted (no extraneous information).
  • Recall is the ability to assure yourself that all relevant data from the repository is returned.
  • Type I errors occur when relevant data exists in the repository but is not returned.
  • Type II errors occur when irrelevant data is returned with a query result.

Note that these concepts can only be applied when the property "relevance" is well defined. That is, it depends on what the repository is used for. More discussion of these topics can be found in [KORFHAGE] 📚

There's also a separate dimension that has to do with time:

  • Query repositories answer a request with a response and, once that's over with, do nothing more.
  • Notify repositories take a request from a user to have information returned at some later time, when it becomes available (current or whatever). They respond at that time with a notification that information is available 🔔
  • Subscription repositories are like notify repositories, but they transfer the actual information when it's available 💜

2.3 Consistency models 🌈

Consistency (or the lack of it) is a property of distributed repositories. For this discussion, we ignore semantically inconsistent data (such as occurrences of pregnant men). We focus on consistency problems, where inconsistency is defined as the same request, using the same credentials, being answered with different data at different sites 💅

Distributed repositories may have:

  • Strict consistency, where the problem above never arises. This is quite difficult. Repositories with this property are usually quite constrained and/or quite expensive 💀
  • Strict internal consistency, where replies always reflect a consistent picture of the total repository, but some sites may reflect an earlier version of the repository than others ⏳
  • Loose, converging consistency, where different parts of the repository may be updated at different times as seen from a single site. The process is designed so that if you stop making changes to the repository, all sites will sooner or later present the same information 🫶
  • Inconsistency, where no guarantee can be made whatsoever 😭

One interesting variant is subset consistency. The system is consistent (according to one of the definitions above), but not all questions will be answered at all sites. This can happen because different sites have different policies on what they make available (NetNews), or because different sites only need different subsets of the "whole picture" (BGP) 🦋

2.4 Security models 🔐

It's harder to describe security models in a few sentences than other properties of information systems. There's also a large specialized literature on security terminology, including [SEC] 📖

Some thoughts, though 💭

On trust in data: why do we trust a piece of data to be correct?

  • Because it's in the repository, and therefore must have been authorized. This is perimeter (or Eggshell) integrity.
  • Because it contains internal integrity checks, usually involving digital signatures by verifiable identities. This is item integrity. The granularity of the integrity, and the ability to do integrity checks on the relationships between objects, is extremely important and extremely hard to get right. So is establishing the roots of the trust chains 🔑
  • Because it fits other available information and causes the right things to happen when I use it. This is hopeful integrity 🤞

Which integrity model to choose is a matter of evaluating the cost of implementing the integrity (cost), the value to you of integrity of the resource being protected (value), and the impact of cost on doing business (risk) 💼

On access to information, the usual categories apply:

  • Open access: Anyone can get the information.
  • Property-based access: Access because of what you are, or where you are. For example, access limited to "same network," "physically present," or "resolvable DNS name."
  • Identity-based access: Access because of who you are (or successfully claim to be). This means things like username/password or personal certificates, or other verifiable information. These are then backed up by a layer specifying what the identity you have proven yourself to be has access to 🪪
  • Token-based access: Access because of what you have. This includes hardware tokens, smartcards, certificates, or capability keys. Access is given to everyone who can present that credential, without caring about their identity 🗝️

The most common approaches are identity-based and open access. However, "what you have" access is commonly used informally, for example on password-protected FTP or Web sites where the password is shared between all members of a group 🍓

2.5. Update models 🔄

Okay so update models are all about how the stuff inside a repository gets changed, bestie. A few examples:

  • Read-only repositories have no standard means of changing the information in them 🔒. This is usually accomplished through some other interface than the standard interface.
  • Read-mostly repositories are designed on the theory that reads will greatly outnumber updates 📖. That might show up as relatively slow consistency-updating protocols 🐢.
  • Read-write repositories assume the updates and the read operations are of the same order of magnitude ⚖️.
  • Write-mostly repositories are designed to store an incoming stream of data, then reproduce a relevant piece of it when needed 📒. Typical examples are insurance company databases and audit logs.

2.6. The term "Directory" 📂

Plot twist: the definitions above never used the term "Directory" 🙈.

In most common usages, the properties a repository must have before it's worthy of being called a directory are:

  • Search 🔍
  • Convergent consistency 💖

All the other terms above may vary across the set of things that people call "directories". Very flexible, very iconic 💅.

3. Classification of some real systems 🌍

3.1. The Domain Name System 🌐

The DNS [DNS] is a global cooperative lookup repository with loose, converging consistency and query capability only 🦋.

It's either strictly read-only or read-mostly (with Dynamic DNS) 📖, has an open access model, and mainly perimeter integrity (some would say hopeful integrity 💀). DNSSEC [DNSSEC] aims to give it item integrity 🔐.

The DNS is built out of zone repositories that themselves may be distributed, and they are always replicated when distributed 🧚.

Note that, like many other systems, the DNS has some features that don't fit neatly in the classification 🎀. For instance, there's a (deprecated and not widely used) function called IQUERY, which allows a very limited query capability.

If you open up the box and look at the relationship between primary and secondary nameservers, that can be seen as a limited form of notify capability 👀. But this is not available to end-users of the total system.

3.2. The (imagined) X.500 Global Directory 📖

X.500 [X500] was intended to be a global search repository with loose, converging consistency 🌸.

It was intended to be read-mostly, perimeter secure and query-capable ✨. Ngl, it's giving "dream big" energy.

3.3. The Global BGP Routing Information Database 🛣️

The Global or top-level BGP routing information database [BGP1] is often viewed as a global read-write repository with loose, converging subset consistency (not all routes are carried everywhere) 🗺️. It has very limited integrity control, mostly intended to be perimeter integrity based on, "access control based on what you are" 🤷‍♀️.

One can argue that BGP [BGP2] is better viewed as a global mechanism for updating a set of local read/write repositories 🔁, since far from all routing information is carried everywhere, and the decision on what routes to accept is always considered a local policy matter. But from a security model perspective, a lot of the controls are applied at the periphery of the routing system, not at each local repository 🚧. This still makes it interesting to consider properties that apply to the BGP system as a whole 💜.

3.4. The NetNews system 📰

NetNews [NEWS] is a global read-write repository with loose (non-converging) subset consistency. Not all sites carry all articles, and article retention times differ 🗞️. Between sites it offers subscription capability. To users, it offers both search and lookup functionality 🔎.

3.5. SNMP MIBs 📟

An SNMP [SNMP] agent can be thought of as a local, centralized repository offering lookup functionality 🧸.

With SNMPv3, it offers all kinds of access models, but mostly, "access because of what you have", seems popular 🔑. Iykyk.

4. Security Considerations 🔐

Okay, bestie, this part is SERIOUS 😭. Security is a very relevant question when you're considering information access systems. Like, very relevant.

Some issues to consider are:

  • Controlled access to information 🚪
  • Controlled rights to update information ✍️
  • Protection of the information path from provider to consumer 🛡️
  • With personal information, privacy issues 🙈
  • Interactions between multiple ways to access the same information 🕸️

It is probably a Good Thing to consider carefully the security models from section 2.4 when designing repositories or repository access protocols. Do not skip this, periodt 💅🔥.

5. Acknowledgement 🫶

The author wishes to thank everyone who contributed to this document, including Patrik Faltstrom, Eric A. Hall, James Benedict, Ted Hardie, Urs Eppenberger, John Klensin, and many others 💖. Main character friends!

6. References 📚

  • [SEC] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
  • [DNS] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
  • [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
  • [E164] ITU-T Recommendation E.164/I.331 (05/97): The International Public Telecommunication Numbering Plan. 1997.
  • [BGP1] "Analyzing the Internet's BGP Routing Table", published in "The Internet Protocol Journal", Volume 4, No 1, April 2001. At the time of writing, available at http://www.telstra.net/gih/papers/ipj/4-1-bgp.pdf
  • [BGP2] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
  • [NEWS] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
  • [SNMP] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
  • [X500] Weider, C. and J. Reynolds, "Executive Introduction to Directory Services Using the X.500 Protocol", FYI 13, RFC 1308, March 1992.
  • [KORFHAGE] "Information Storage and Retrieval", Robert R. Korfhage, Wiley 1997. See page 194 for "precision" and "recall" definitions. 📖

7. Author's Address 📮

Harald Tveit Alvestrand
Cisco Systems
Weidemanns vei 27
N-7043 Trondheim
NORWAY

Phone: +47 41 44 29 94
EMail: Harald@alvestrand.no

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society ✨.

📦 where this page comes from