Trivia: 40% UNIX syscall overhead = filename resolution
        50% of filesystem calls are one of open(), stat(), lstat()

Names = hierarchical character strings
Operations: bind (create/delete/alter)
            query (status/list)
            map (lookup + execute operation on object)

Extends the likes of Lampson's GNS, Grapevine, Clearinghouse, which
are designed for infrequent name lookups, to a huge scale system with
files, windows, etc. as objects. They are skeptical of Locus.

3 directory levels: 

  a. Global (Lampson's or Al Demers' systems are good enough)
       - liaison servers are front ends and translators

  b. Administrational
       - critical to the functioning of the admin domain
       - consists of object managers (for bound names) and a directory
         manager (for unbound names); they all form the participant
         mcast group
       - dir mgr keeps a list of bound names (for fault diag + recovery
         as well as listing)
       - hierarchical trust
       - data in this level is more localized and dynamic than the global level
       - suggested collocation of dir mgr and liaison
       - if global level is down, can still function but cannot reference
         external objs (most likely wouldn't be able to access them anyhow)

  c. Managerial
       - each directory is in one object manager (which may have more dirs)
       - each obj mgr implements all ops on the names it covers
       - high performance is critical (dynamic, so caching doesn't help much);
       - collocation of naming and mgmt helps w/ performance, obj/obj names
         consistency, and security; it maintains the desired reliability
       - each obj mgr should function in the absence of the upper levels

Name prefix cache:

   - entry = { prefix, <mgr_id, dir_id> }
     * full hit: prefix --> obj mgr
     * near miss: prefix --> local admin dir (mcast probe to group of mgrs)
                  prefix --> local liaison server (bc. directory is external)
     * total miss: prefix --> nil (go to global dir via liaison)

   - on-use cache consistency (liaisons use client feedback to trigger refresh)

   - advantages:
     * prefix-based matching requires few cache entries --> high hit rates
     * near misses can reduce work considerably
     * on-use consistency eliminates the need for update pre-propagation


Performance: main trick is prefix caching
     * statistical model that predicts cache hit ratio > 99%  (measure 99.7%)
     * assumes no cache capacity restrictions (reasonable assumption)
     * one expects strong locality of ref. in large distributed sys
     * in the presence of such locality, global hit ratio is dominated 
       by pairwise client/subtree hit ratios.
   - cache inheritance: each prog has cache in its own address space, and 
     inherits it from parent process (transforms cold start into warm start)
   - name mapping is a common enough operation that warrants optimization
     (0.578 name-mapping ops/workstation/sec)
   - any dir with more than a few thousand entries should be made global

Fault tolerance: ABMA = "all but manager access"
     * mcast-based ABMA resiliency for access to objs w/in admin. domain
     * global access has poorer resiliency (global dir can fail, remote
       admin dir can fail)
     * liaison servers are stateless and migratable --> easy to restart
     * don't handle general byzantine faults

Secure NS: 1. servers only answer to authorized clients
           2. clients accept info only from auth. servers (use capabilities)
           3. servers don't accept unauthorized updates
     

ISSUES
------

1. Naming/Mgmt collocation allows you to use the same security
   mechanism for both; do we always want this?

2. On-use consistency trades mapping latency for reduced update; is
   this tolerable or not?

3. Bottom of p. 173 ("Finally ..."): the suggested collocation of the
   liaison with the dir mgr will make things even worse. Why is fault
   isolation not an issue on p. 158, right before sec. 2.5?

4. Generation of name-mapping requests is assumed to be a Poisson
   process, i.e., each arrival is random (a.k.a., white noise). In
   reality, however, computer stuff is bursty (arguably 1/f noise). Do
   computer scientists really model everything as a Poisson proc?

5. The capability described on p. 177 is a lot like a lease. How far
   can we push this analogy?

6. Last paragraph on p. 181: has anything become of it?