doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc5716.txt b/doc/rfc/rfc5716.txt
new file mode 100644
index 0000000..0d66ca7
--- /dev/null
+++ b/doc/rfc/rfc5716.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        J. Lentini
+Request for Comments: 5716                                   C. Everhart
+Category: Informational                                           NetApp
+ISSN: 2070-1721                                                D. Ellard
+                                                        BBN Technologies
+                                                               R. Tewari
+                                                                 M. Naik
+                                                             IBM Almaden
+                                                            January 2010
+
+
+                Requirements for Federated File Systems
+
+Abstract
+
+   This document describes and lists the functional requirements of a
+   federated file system and defines related terms.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5716.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Lentini, et al.               Informational                     [Page 1]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Overview ........................................................3
+      1.1. Requirements Language ......................................4
+   2. Purpose .........................................................5
+   3. Examples and Discussion .........................................5
+      3.1. Create a Fileset and Its FSL(s) ............................5
+           3.1.1. Creating a Fileset and an FSN .......................6
+           3.1.2. Adding a Replica of a Fileset .......................6
+      3.2. Junction Resolution ........................................7
+      3.3. Junction Creation ..........................................9
+   4. Glossary ........................................................9
+   5. Proposed Requirements ..........................................11
+      5.1. Basic Assumptions .........................................11
+      5.2. Requirements ..............................................14
+   6. Non-Requirements ...............................................20
+   7. Security Considerations ........................................21
+   8. References .....................................................22
+      8.1. Normative References ......................................22
+      8.2. Informative References ....................................23
+   Appendix A.  Acknowledgments ......................................25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lentini, et al.               Informational                     [Page 2]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+1.  Overview
+
+   This document describes and lists the functional requirements of a
+   federated file system and defines related terms.
+
+   We do not describe the mechanisms that might be used to implement
+   this functionality except in cases where specific mechanisms, in our
+   opinion, follow inevitably from the requirements.  Our focus is on
+   the interfaces between the entities of the system, not on the
+   protocols or their implementations.
+
+   Today, there are collections of fileservers that inter-operate to
+   provide a single namespace comprised of filesystem resources provided
+   by different members of the collection, joined together with inter-
+   filesystem references.  The namespace can either be assembled at the
+   fileservers, the clients, or by an external namespace service, and is
+   often not easy or uniform to manage.  The requirements in this
+   document are meant to lead to a uniform server-based namespace that
+   is capable of spanning a whole enterprise and that is easy to manage.
+
+   We define some terms to better describe the solution space.  A
+   "fileset" is the abstract view of a filesystem in a uniform
+   namespace, and may be implemented behind that abstraction by one or
+   more physical filesystems at any given time.  Each fileset has a name
+   called an "FSN" (fileset name), and each physical filesystem has a
+   fileset location ("FSL").  A fileset is a directory tree containing
+   files and directories, and it may also contain references to other
+   filesets.  These references are called "junctions".  To provide
+   location independence, a junction does not contain information about
+   the location of the real resource(s), but instead contains an FSN
+   that can be used to look up the location information.  The service
+   that can be used to map from the FSN to the FSL(s) is called a
+   namespace database (NSDB) service.  The NSDB provides a level of
+   indirection from the virtual paths in the uniform namespace to the
+   actual locations of files.  By design, the NSDB does not store the
+   junctions.  This allows junction administration and NSDB
+   administration to be separate roles.
+
+   The servers direct clients to the proper locations by existing
+   mechanisms (e.g., the referrals mechanism within [RFC3530] and
+   [RFC5661]).  Updates to the locations make it possible to support
+   migration and replication of physical filesystems that comprise the
+   namespace, in a way that is transparent to filesystem applications.
+
+
+
+
+
+
+
+
+Lentini, et al.               Informational                     [Page 3]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+   Figure 1 shows an example of a federation.  This federation has two
+   members, named ALPHA and BETA.  Federation members may contain an
+   arbitrary number of fileservers and NSDB nodes; in this illustration,
+   ALPHA and BETA each have three servers, one NSDB node, and are
+   administered separately.
+
+      +----------------------+       +----------------------+
+      |  Federation Member   |       |  Federation Member   |
+      |        ALPHA         |       |         BETA         |
+      |                      |       |                      |
+      |                      |       |                      |
+      |    +------------+    |       |    +------------+    |
+      |    |    NSDB    |    |       |    |    NSDB    |    |
+      |    |            |    |       |    |            |    |
+      |    +------------+    |       |    +------------+    |
+      |                      |       |                      |
+      |                      |       |                      |
+      |                      |       |                      |
+      |         +----------+ |       |         +----------+ |
+      |         |          | |       |         |          | |
+      |     +-- | Servers  | |       |     +-- | Servers  | |
+      |     |   |          | |       |     |   |          | |
+      | +-- |   |          | |       | +-- |   |          | |
+      | |   |   +----------+ |       | |   |   +----------+ |
+      | |   |          |     |       | |   |          |     |
+      | |   +----------+     |       | |   +----------+     |
+      | |          |         |       | |          |         |
+      | +----------+         |       | +----------+         |
+      +----------------------+       +----------------------+
+
+                                 Figure 1
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   Note that this is a requirements document, and in many instances
+   where these words are used in this document they refer to qualities
+   of a specification for a system that satisfies the document, or
+   requirements of a system that matches that specification.  These
+   cases are distinguished when there is potential for ambiguity.
+
+
+
+
+
+
+
+
+Lentini, et al.               Informational                     [Page 4]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+2.  Purpose
+
+   Our objective is to specify a set of protocols by which fileservers
+   or collections of fileservers, with different administrators, can
+   form a federation of fileservers and NSDB nodes that provides a
+   namespace composed of the filesets hosted on the different
+   fileservers and fileserver collections.
+
+   It should be possible, using a system that implements the protocols,
+   to share a common namespace across all the fileservers in the
+   federation.  It should also be possible for different fileservers in
+   the federation to project different namespaces and enable clients to
+   traverse them.
+
+   Such a federation may contain an arbitrary number of NSDB nodes, each
+   belonging to a different administrative entity, and each providing
+   the mappings that define a part of a namespace.  Such a federation
+   may also have an arbitrary number of administrative entities, each
+   responsible for administering a subset of the fileservers and NSDB
+   nodes.  Acting in concert, the administrators should be able to build
+   and administer this multi-fileserver, multi-collection namespace.
+
+   It is not the intent of the federation to guarantee namespace
+   consistency across all client views.  Since different parts of the
+   namespace may be administered by different entities, it is possible
+   that a client could be accessing a stale area of the namespace
+   managed by one entity because a part of the namespace above it,
+   managed by another entity, has changed.
+
+3.  Examples and Discussion
+
+   In this section we provide examples and discussion of the basic
+   operations facilitated by the federated file system protocol:
+   creating a fileset, adding a replica of a fileset, resolving a
+   junction, and creating a junction.
+
+3.1.  Create a Fileset and Its FSL(s)
+
+   A fileset is the abstraction of a set of files and the directory tree
+   that contains them.  The fileset abstraction is the fundamental unit
+   of data management in the federation.  This abstraction is
+   implemented by an actual directory tree whose root location is
+   specified by a fileset location (FSL).
+
+   In this section, we describe the basic requirements for starting with
+   a directory tree and creating a fileset that can be used in the
+   federation protocols.  Note that we do not assume that the process of
+   creating a fileset requires any transformation of the files or the
+
+
+
+Lentini, et al.               Informational                     [Page 5]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+   directory hierarchy.  The only thing that is required by this process
+   is assigning the fileset a fileset name (FSN) and expressing the
+   location(s) of the implementation of the fileset as FSL(s).
+
+   There are many possible variations to this procedure, depending on
+   how the FSN that binds the FSL is created, and whether other replicas
+   of the fileset exist, are known to the federation, and need to be
+   bound to the same FSN.
+
+   It is easiest to describe this in terms of how to create the initial
+   implementation of the fileset, and then describe how to add replicas.
+
+3.1.1.  Creating a Fileset and an FSN
+
+   1.  Choose the NSDB node that will keep track of the FSL(s) and
+       related information for the fileset.
+
+   2.  Request that the NSDB node register a new FSN for the fileset.
+
+       The FSN may either be chosen by the NSDB node or by the server.
+       The latter case is used if the fileset is being restored, perhaps
+       as part of disaster recovery, and the server wishes to specify
+       the FSN in order to permit existing junctions that reference that
+       FSN to work again.
+
+       At this point, the FSN exists, but its location is unspecified.
+
+   3.  Send the FSN, the local volume path, the export path, and the
+       export options for the local implementation of the fileset to the
+       NSDB node.  Annotations about the FSN or the location may also be
+       sent.
+
+       The NSDB node records this information and creates the initial
+       FSL for the fileset.
+
+3.1.2.  Adding a Replica of a Fileset
+
+   Adding a replica is straightforward: the NSDB node and the FSN are
+   already known.  The only remaining step is to add another FSL.
+
+   Note that the federation protocols do not include methods for
+   creating or managing replicas: this is assumed to be a platform-
+   dependent operation (at least at this time).  The only requirement is
+   that these fileset replicas be registered and unregistered with the
+   NSDB.
+
+
+
+
+
+
+Lentini, et al.               Informational                     [Page 6]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+3.2.  Junction Resolution
+
+   A fileset may contain references to other filesets.  These references
+   are represented by junctions.  If a client requests access to a
+   fileset object that is a junction, the server resolves the junction
+   to discover the FSL(s) that implements the referenced fileset.
+
+   There are many possible variations to this procedure, depending on
+   how the junctions are represented and how the information necessary
+   to perform resolution is represented by the server.
+
+   Step 4 is the only step that interacts directly with the federation
+   protocols.  The rest of the steps may use platform-specific
+   interfaces.
+
+   1.  The server determines that the object being accessed is a
+       junction.
+
+   2.  Using the junction, the server does a local lookup to find the
+       FSN of the target fileset.
+
+   3.  Using the FSN, the server finds the NSDB node responsible for the
+       target object.
+
+   4.  The server contacts that NSDB node and asks for the set of FSLs
+       that implement the target FSN.  The NSDB node responds with a set
+       of FSLs.
+
+   5.  The server converts one or more of the FSLs to the location type
+       used by the client (e.g., a Network File System (NFSv4)
+       fs_location, as described in [RFC3530]).
+
+   6.  The server redirects (in whatever manner is appropriate for the
+       client) the client to the location(s).
+
+   These steps are illustrated in Figure 2.  The client sends request 1
+   to server X, in federation member ALPHA, in an attempt to reference
+   an object (which appears to the client as a directory).  Server X
+   recognizes that the referenced object is actually a junction that
+   refers to a directory in a different fileset.  Server X finds, from
+   the FSN in the junction, that the NSDB responsible for knowing the
+   location of the target of the junction is the NSDB of federation
+   member BETA.  Server X sends request 2 to the NSDB of BETA, asking
+   for the current location of the directory.  The NSDB sends response 3
+   to server X, telling the server that the directory is located on
+   server Y.  Server X sends response 4 to the client, indicating that
+   the directory is in a "new" location on server Y.  The client then
+   sends request 5 to server Y, repeating the initial request.
+
+
+
+Lentini, et al.               Informational                     [Page 7]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+   Given the current requirements and definitions, this resolution
+   method MUST work.  However, there is no requirement that this is the
+   only resolution method that can be used.  This method may be used as
+   the fallback when all else fails (or, for a simple implementation, it
+   could be the only method).  This is a degenerate implementation of
+   the NSDB service as a simple composition of NSDB nodes; we expect
+   that large federations will use more sophisticated methods to share
+   the FSN and FSL information among multiple NSDB nodes.
+
+          +---------------+
+          |               |
+          |    Client     | >--------------------------+
+          |               |                            |
+          +---------------+                            |
+            v   ^                                      |
+      +-----+---+-------------+      +-----------------+-----+
+      |     |   |   Federation|      |Federation       |     |
+      |     |   |   member    |      |member           |     |
+      |     |   |   ALPHA     |      |BETA             |     |
+      |     |   |             |      |                 |     |
+      |     |   |             |      |                 |     |
+      |     |   |             |      |                 |     |
+      |     |   |             |      |                 |     |
+      |     |   |             |      |   +---------+   |     |
+      |     |   |   +---------+------+-> |         |   |     |
+      |     |   |   |         |      |   | NSDB Y  |   |     |
+      |     |   |   |   +-----+------+-< |         |   |     |
+      |     |   |   |   |     |      |   +---------+   |     |
+      |     |   |   |   |     |      |                 |     |
+      |     |   |   |   |     |      |                 |     |
+      |     |   |   |   |     |      |                 |     |
+      |    1|  4|  2|  3|     |      |                5|     |
+      |     v   ^   ^   v     |      |                 v     |
+      |   +---------------+   |      |   +---------------+   |
+      |   |               |   |      |   |               |   |
+      |   |   Server X    |   |      |   |   Server Y    |   |
+      |   |               |   |      |   |               |   |
+      |   +---------------+   |      |   +---------------+   |
+      |                       |      |                       |
+      +-----------------------+      +-----------------------+
+
+                                 Figure 2
+
+
+
+
+
+
+
+
+
+Lentini, et al.               Informational                     [Page 8]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+3.3.  Junction Creation
+
+   Given a local path and the FSN of a remote fileset, an administrator
+   can create a junction from the local path to the remote fileset.
+
+   There are many possible variations to this procedure, depending on
+   how the junctions are represented and how the information necessary
+   to perform resolution is represented by the server.
+
+   Step 1 is the only step that uses the federation interfaces.  The
+   remaining step may use platform-specific interfaces.
+
+   1.  The administrator requests the server create a junction to the
+       FSN of the remote fileset at the given path.
+
+   2.  The server inserts the junction to the FSN, at the given path,
+       into the local filesystem.
+
+4.  Glossary
+
+   Administrator:  user with the necessary authority to initiate
+      administrative tasks on one or more servers.
+
+   Admin Entity:  A server or agent that administers a collection of
+      fileservers and persistently stores the namespace information.
+
+   Client:  Any client that accesses the fileserver data using a
+      supported filesystem access protocol.
+
+   Federation:  A set of server collections and singleton servers that
+      use a common set of interfaces and protocols in order to provide
+      to their clients a federated namespace accessible through a
+      filesystem access protocol.
+
+   Fileserver:  A server exporting a filesystem via a network filesystem
+      access protocol.
+
+   Fileset:  The abstraction of a set of files and the directory tree
+      that contains them.  A fileset is the fundamental unit of data
+      management in the federation.
+
+      Note that all files within a fileset are descendants of one
+      directory, and that filesets do not span filesystems.
+
+
+
+
+
+
+
+
+Lentini, et al.               Informational                     [Page 9]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+   Filesystem:  A self-contained unit of export for a fileserver, and
+      the mechanism used to implement filesets.  The fileset does not
+      need to be rooted at the root of the filesystem, nor at the export
+      point for the filesystem.
+
+      A single filesystem MAY implement more than one fileset, if the
+      client protocol and the fileserver permit this.
+
+   Filesystem Access Protocol:  A network filesystem access protocol
+      such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or CIFS
+      (Common Internet File System) [MS-SMB] [MS-SMB2] [MS-CIFS].
+
+   FSL (Fileset Location):  The location of the implementation of a
+      fileset at a particular moment in time.  An FSL MUST be something
+      that can be translated into a protocol-specific description of a
+      resource that a client can access directly, such as an fs_location
+      (for NFSv4), or share name (for CIFS).  Note that not all FSLs
+      need to be explicitly exported as long as they are contained
+      within an exported path on the fileserver.
+
+   FSN (Fileset Name):  A platform-independent and globally unique name
+      for a fileset.  Two FSLs that implement replicas of the same
+      fileset MUST have the same FSN, and if a fileset is migrated from
+      one location to another, the FSN of that fileset MUST remain the
+      same.
+
+   Junction:  A filesystem object used to link a directory name in the
+      current fileset with an object within another fileset.  The
+      server-side "link" from a leaf node in one fileset to the root of
+      another fileset.
+
+   Namespace:  A filename/directory tree that a sufficiently authorized
+      client can observe.
+
+   NSDB (Namespace Database) Service:  A service that maps FSNs to FSLs.
+      The NSDB may also be used to store other information, such as
+      annotations for these mappings and their components.
+
+   NSDB Node:  The name or location of a server that implements part of
+      the NSDB service and is responsible for keeping track of the FSLs
+      (and related info) that implement a given partition of the FSNs.
+
+   Referral:  A server response to a client access that directs the
+      client to evaluate the current object as a reference to an object
+      at a different location (specified by an FSL) in another fileset,
+      and possibly hosted on another fileserver.  The client re-attempts
+      the access to the object at the new location.
+
+
+
+
+Lentini, et al.               Informational                    [Page 10]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+   Replica:  A replica is a redundant implementation of a fileset.  Each
+      replica shares the same FSN, but has a different FSL.
+
+      Replicas may be used to increase availability or performance.
+      Updates to replicas of the same fileset MUST appear to occur in
+      the same order, and therefore each replica is self-consistent at
+      any moment.
+
+      We do not assume that updates to each replica occur
+      simultaneously.  If a replica is offline or unreachable, the other
+      replicas may be updated.
+
+   Server Collection:  A set of fileservers administered as a unit.  A
+      server collection may be administered with vendor-specific
+      software.
+
+      The namespace provided by a server collection could be part of the
+      federated namespace.
+
+   Singleton Server:  A server collection containing only one server; a
+      stand-alone fileserver.
+
+5.  Proposed Requirements
+
+   The phrase "USING THE FEDERATION INTERFACES" implies that the
+   subsequent requirement must be satisfied, in its entirety, via the
+   federation interfaces.
+
+   Note that the requirements are described in terms of correct behavior
+   by all entities.  We do not address the requirements of the system in
+   the presence of faults.
+
+5.1.  Basic Assumptions
+
+   Several of the requirements are so fundamental that we treat them as
+   basic assumptions; if any of these assumptions are violated, the rest
+   of the requirements must be reviewed in their entirety.
+
+   A1:  The federation protocols do not require any changes to existing
+        client-facing protocols, and MAY be extended to incorporate new
+        client-facing protocols.
+
+
+
+
+
+
+
+
+
+
+Lentini, et al.               Informational                    [Page 11]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+   A2:  A client SHOULD NOT require any a priori knowledge of the
+        general structure or composition of the federation.
+
+        The client may require some specific knowledge in order to find
+        and access an instance of the fileset that defines the root of
+        its view of the namespace.  As the client traverses the
+        namespace, the client discovers the information it needs in
+        order to locate the filesets it accesses.
+
+   A3:  All requirements MUST be satisfiable via the federation
+        protocols and the standard protocols used by the fileservers
+        (i.e., NFS, CIFS, DNS, etc.).
+
+        USING THE FEDERATION INTERFACES, a federation operation that
+        requires an interaction between two (or more) entities that are
+        members of the federation MUST be possible without requiring any
+        proprietary protocols.
+
+   A4:  All the entities participating in a federation operation MUST be
+        able to authenticate each other.
+
+        All principals (clients, users, administrator of a singleton or
+        server collection, hosts, NSDB nodes, etc.) that can assume a
+        role defined by the federation protocol can identify themselves
+        to each other via an authentication mechanism.  This mechanism
+        is not defined or further described in this document.
+
+        The authority of a principal to request that a second principal
+        perform a specific operation is ultimately determined by the
+        second.  Authorization may be partitioned by server collection
+        or set of servers as well as by operation.  For example, if a
+        user has administrative privileges on one server in the
+        federation, this does not imply that they have administrative
+        privileges (or, for that matter, any privileges whatsoever) on
+        any other server in the federation.
+
+        In order to access the functionality provided by the federation
+        interfaces, it may be necessary to have elevated privileges or
+        authorization.  The authority required by different operations
+        may be different.  For example, the authority required to query
+        the NSDB about the FSLs bound to an FSN may be different than
+        the authority required to change the bindings of that FSN.
+
+        An operation attempted by an unauthorized entity MUST fail in a
+        manner that indicates that the failure was due to insufficient
+        authorization.
+
+
+
+
+
+Lentini, et al.               Informational                    [Page 12]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+        This document does not enumerate the authorization necessary for
+        any operation.
+
+   A5:  The federation protocols MUST NOT require changes to existing
+        authentication/authorization mechanisms in use at the
+        fileservers for client-facing protocols.
+
+        A user's view of the namespace may be limited by the
+        authentication and authorization privileges it has on the
+        different fileservers in the federation.  As such, users may
+        only be able to traverse the parts of the namespace to which
+        they have access.
+
+        The federation protocols do not impose any restrictions on how
+        users are represented within the federation.  For example, a
+        single enterprise could employ a common identity for users
+        across the federation.  A grid environment could utilize user
+        mapping or translations across different administrative domains.
+
+   A6:  In a federated system, we assume that an FSN MUST express, or
+        can be used to discover, the following two pieces of
+        information:
+
+        1.  The location of the NSDB node that is responsible for
+            knowing the filesystem location(s) (FSLs) of the named
+            fileset.
+
+            The NSDB node must be specified because there may be many
+            NSDB nodes in a federation.  We do not assume that any
+            single entity knows the location of all of the NSDB nodes,
+            and therefore exhaustive search is not an option.
+
+            There are several ways in which a fileserver can locate the
+            NSDB node responsible for a given fileset.  One approach,
+            given a DNS infrastructure, is to specify the location of
+            the NSDB node by the Fully-Qualified Domain Name (FQDN) of
+            the server hosting the NSDB node.  Another approach is to
+            use a separate DNS-style hierarchy to resolve the location
+            of the NSDB node.
+
+        2.  The FSN identifier.
+
+            The FSN identifier is the index used by the NSDB node to
+            identify the target fileset.
+
+            There are several ways to represent FSN identifiers.  One
+            approach could use 128-bit Universally Unique IDentifiers
+            (UUIDs) as described in [RFC4122].
+
+
+
+Lentini, et al.               Informational                    [Page 13]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+        As an example, an FSN could be represented by a URL of the form
+        nsdb://nsdb.example.com/UUID where nsdb is the scheme name,
+        nsdb.example.com is the FQDN of the server hosting the NSDB
+        node, and UUID is the string representation of the identifier.
+
+        Note that it is not assumed that it is always required for a
+        server to contact the NSDB node specified by the FSN in order to
+        find the FSLs.  The relevant information stored in that NSDB
+        node may also be cached local to the server or on a proxy NSDB
+        node "near" the server.
+
+   A7:  All federation servers and NSDB nodes are assumed to execute the
+        federation protocols correctly.  The behavior of the federation
+        is undefined in the case of Byzantine behavior by any federation
+        server or NSDB node.
+
+   A8:  The locations of federation services (such as NSDBs and FSLs)
+        can be specified in a manner such that they can be correctly
+        interpreted by all members of the federation that will access
+        them.
+
+        For example, if an NSDB node is specified by an FQDN, then this
+        implies that every member of the federation that needs to access
+        this NSDB node can resolve this FQDN to an IP address for that
+        NSDB node.  (It is not necessary that the FQDN always resolve to
+        the same address; the same service may appear at different
+        addresses on different networks.)
+
+        It is the responsibility of each federation member to ensure
+        that the resources it wishes to expose have accessible network
+        locations and that the necessary resolution mechanisms (i.e.,
+        DNS) are given the necessary data to perform the resolution
+        correctly.
+
+5.2.  Requirements
+
+   R1:   Requirements of each FSN:
+
+         a.  Each FSN MUST be unique within the scope of its NSDB (so
+             that the FSN is globally unique).
+
+         b.  The FSN MUST be sufficiently descriptive to locate an
+             instance of the fileset it names within the federation at
+             any time.
+
+         c.  All FSNs MUST be invariant when their underlying
+             filesystems move or are replicated; only mappings from FSN
+             to FSL(s) change under these transformations.
+
+
+
+Lentini, et al.               Informational                    [Page 14]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+         d.  All files accessible from the global namespace MUST be part
+             of a fileset that has an assigned FSN.
+
+         Not all filesets in the federation are required to have an FSN
+         or be reachable by an FSL.  Only those filesets that are the
+         target of a junction (as described in R3) are required to have
+         an FSN.
+
+         The FSN format MAY be of variable size.  If the format is
+         variable in size, fileserver implementations MAY have a maximum
+         supported FSN size.  By bounding the FSN size, some fileserver
+         implementations might be able to efficiently organize FSNs in
+         stable storage.  For interoperability, the federation protocols
+         SHOULD define an FSN size that all fileservers support.
+
+   R2:   USING THE FEDERATION INTERFACES, it MUST be possible to create
+         an FSN for a fileset, and it must be possible to bind an FSL to
+         that FSN.  These operations are NSDB operations and do not
+         require any action on the part of a file server.
+
+         It is possible to create an FSN for a fileset that has not
+         actually been created.  It is also possible to bind a
+         nonexistent FSL to an FSN.  It is also possible to create a
+         fileset without assigning it an FSN.  The binding between an
+         FSN and an FSL is defined entirely within the context of the
+         NSDB; the servers do not "know" whether the filesets they host
+         have been assigned FSNs (or, if so, what those FSNs are).
+
+         The requirement that filesets can exist prior to being assigned
+         an FSN and the requirement that FSNs can exist independent of
+         filesets are intended to simplify the construction of the
+         namespace in a convenient manner.  For example, they permit an
+         admin to assign FSNs to existing filesets and thereby
+         incorporate existing filesets into the namespace.  They also
+         permit the structure of the namespace to be defined prior to
+         creation of the component filesets.  In either case, it is the
+         responsibility of the entity updating the NSDB with FSNs and
+         FSN-to-FSL mappings to ensure that the namespace is constructed
+         in a consistent manner.  (The simplest way to accomplish this
+         is to ensure that the FSN and FSN-to-FSL mappings are always
+         recorded in the NSDB prior to the creation of any junctions
+         that refer to that FSN.)
+
+         a.  An administrator MAY specify the entire FSN (including both
+             the NSDB node location and the identifier) of the newly
+             created FSL, or the administrator MAY specify only the NSDB
+             node and have the system choose the identifier.
+
+
+
+
+Lentini, et al.               Informational                    [Page 15]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+             The admin can choose to specify the FSN explicitly in order
+             to recreate a lost fileset with a given FSN (for example,
+             as part of disaster recovery).  It is an error to assign an
+             FSN that is already in use by an active fileset.
+
+             Note that creating a replica of an existing filesystem is
+             NOT accomplished by assigning the FSN of the filesystem you
+             wish to replicate to a new filesystem.
+
+         b.  USING THE FEDERATION INTERFACES, it MUST be possible to
+             create a federation FSL by specifying a specific local
+             volume, path, export path, and export options.
+
+   R3:   USING THE FEDERATION INTERFACES, and given the FSN of a target
+         fileset, it MUST be possible to create a junction to that
+         fileset at a named place in another fileset.
+
+         After a junction has been created, clients that access the
+         junction transparently interpret it as a reference to the
+         FSL(s) that implement the FSN associated with the junction.
+
+         a.  It SHOULD be possible to have more than one junction whose
+             target is a given fileset.  In other words, it SHOULD be
+             possible to mount a fileset at multiple named places.
+
+         b.  If the fileset in which the junction is created is
+             replicated, then the junction MUST eventually appear in all
+             of its replicas.
+
+             The operation of creating a junction within a fileset is
+             treated as an update to the fileset, and therefore obeys
+             the general rules about updates to replicated filesets.
+
+   R4:   USING THE FEDERATION INTERFACES, it MUST be possible to delete
+         a specific junction from a fileset.
+
+         If a junction is deleted, clients who are already viewing the
+         fileset referred to by the junction after traversing the
+         junction MAY continue to view the old namespace.  They might
+         not discover that the junction no longer exists (or has been
+         deleted and replaced with a new junction, possibly referring to
+         a different FSN).
+
+         After a junction is deleted, another object with the same name
+         (another junction, or an ordinary filesystem object) may be
+         created.
+
+
+
+
+
+Lentini, et al.               Informational                    [Page 16]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+         The operation of deleting a junction within a fileset is
+         treated as an update to the fileset, and therefore obeys the
+         general rules about updates to replicated filesets.
+
+   R5:   USING THE FEDERATION INTERFACES, it MUST be possible to
+         invalidate an FSN.
+
+         a.  If a junction refers to an FSN that is invalid, attempting
+             to traverse the junction MUST fail.
+
+         An FSN that has been invalidated MAY become valid again if the
+         FSN is recreated (i.e., as part of a disaster recovery
+         process).
+
+         If an FSN is invalidated, clients who are already viewing the
+         fileset named by the FSN MAY continue to view the old
+         namespace.  They might not discover that the FSN is no longer
+         valid until they try to traverse a junction that refers to it.
+
+   R6:   USING THE FEDERATION INTERFACES, it MUST be possible to
+         invalidate an FSL.
+
+         a.  An invalid FSL MUST NOT be returned as the result of
+             resolving a junction.
+
+         An FSL that has been invalidated MAY become valid again if the
+         FSL is recreated (i.e., as part of a disaster recovery
+         process).
+
+         If an FSL is invalidated, clients who are already viewing the
+         fileset implemented by the FSL MAY continue to use that FSL.
+         They might not discover that the FSL is no longer valid until
+         they try to traverse a junction that refers to the fileset
+         implemented by the FSL.
+
+         Note that invalidating an FSL does not imply that the
+         underlying export or share (depending on the file access
+         protocol in use) is changed in any way -- it only changes the
+         mappings from FSNs to FSLs on the NSDB.
+
+   R7:   It MUST be possible for the federation of servers to provide
+         multiple namespaces.
+
+   R8:   USING THE FEDERATION INTERFACES:
+
+         a.  It MUST be possible to query the fileserver named in an FSL
+             to discover whether a junction exists at a given path
+             within that FSL.
+
+
+
+Lentini, et al.               Informational                    [Page 17]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+         b.  It MAY be possible to query the fileserver named in an FSL
+             to discover the junctions, if any, in that FSL.  If this
+             feature is implemented, the fileserver SHOULD report each
+             junction's path within the FSL and the targeted FSN.
+
+   R9:   The projected namespace (and the objects named by the
+         namespace) MUST be accessible to clients via at least one of
+         the following standard filesystem access protocols:
+
+         a.  The namespace SHOULD be accessible to clients via versions
+             of the CIFS (Common Internet File System) protocol as
+             described in [MS-SMB] [MS-SMB2] [MS-CIFS].
+
+         b.  The namespace SHOULD be accessible to clients via the NFSv4
+             protocol as described in [RFC3530].
+
+         c.  The namespace SHOULD be accessible to clients via the NFSv3
+             protocol as described in [RFC1813].
+
+         d.  The namespace SHOULD be accessible to clients via the NFSv2
+             protocol as described in [RFC1094].
+
+         It must be understood that some of these protocols, such as
+         NFSv3 and NFSv2, have no innate ability to access a namespace
+         of this kind.  Where such protocols have been augmented with
+         other protocols and mechanisms (such as autofs or amd for
+         NFSv3) to provide an extended namespace, we propose that these
+         protocols and mechanisms may be used, or extended, in order to
+         satisfy the requirements given in this document, and different
+         clients may use different mechanisms.
+
+   R10:  USING THE FEDERATION INTERFACES, it MUST be possible to modify
+         the NSDB mapping from an FSN to a set of FSLs to reflect the
+         migration from one FSL to another.
+
+   R11:  FSL migration SHOULD have little or no impact on the clients,
+         but this is not guaranteed across all federation members.
+
+         Whether FSL migration is performed transparently depends on
+         whether the source and destination servers are able to do so.
+         It is the responsibility of the administrator to recognize
+         whether or not the migration will be transparent, and advise
+         the system accordingly.  The federation, in turn, MUST advise
+         the servers to notify their clients, if necessary.
+
+
+
+
+
+
+
+Lentini, et al.               Informational                    [Page 18]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+         For example, on some systems, it may be possible to migrate a
+         fileset from one system to another with minimal client impact
+         because all client-visible metadata (inode numbers, etc.) are
+         preserved during migration.  On other systems, migration might
+         be quite disruptive.
+
+   R12:  USING THE FEDERATION INTERFACES, it MUST be possible to modify
+         the NSDB mapping from an FSN to a set of FSLs to reflect the
+         addition/removal of a replica at a given FSL.
+
+   R13:  Replication SHOULD have little or no negative impact on the
+         clients.
+
+         Whether FSL replication is performed transparently depends on
+         whether the source and destination servers are able to do so.
+         It is the responsibility of the administrator initiating the
+         replication to recognize whether or not the replication will be
+         transparent, and advise the federation accordingly.  The
+         federation MUST advise the servers to notify their clients, if
+         necessary.
+
+         For example, on some systems, it may be possible to mount any
+         FSL of an FSN read/write, while on other systems, there may be
+         any number of read-only replicas but only one FSL that can be
+         mounted as read/write.
+
+   R14:  USING THE FEDERATION INTERFACES, it SHOULD be possible to
+         annotate the objects and relations managed by the federation
+         protocol with arbitrary name/value pairs.
+
+         These annotations are not used by the federation protocols --
+         they are intended for use by higher-level protocols.  For
+         example, an annotation that might be useful for a system
+         administrator browsing the federation would be the "owner" of
+         each FSN (i.e., "this FSN is for the home directory of Joe
+         Smith").  As another example, the annotations may express hints
+         used by the clients (such as priority information for NFSv4.1).
+
+         Both FSNs and FSLs may be annotated.  For example, an FSN
+         property might be "This is Joe Smith's home directory", and an
+         FSL property might be "This instance of the FSN is at the
+         remote backup site".
+
+
+         a.  USING THE FEDERATION INTERFACES, it MUST be possible to
+             query the system to find the annotations for a junction.
+
+
+
+
+
+Lentini, et al.               Informational                    [Page 19]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+         b.  USING THE FEDERATION INTERFACES, it MUST be possible to
+             query the system to find the annotations for an FSN.
+
+         c.  USING THE FEDERATION INTERFACES, it MUST be possible to
+             query the system to find the annotations for an FSL.
+
+   R15:  It MUST be possible for the federation to project a namespace
+         with a common root.
+
+
+         a.  It SHOULD be possible to define a root fileset that is
+             exported by one or more fileservers in the federation as
+             the top level of a namespace.  (Corollary: There is one
+             root fileset per namespace and it is possible to support
+             multiple namespaces per federation.)
+
+         b.  It SHOULD be possible for a fileserver to locate an NSDB
+             that stores the layout of a root fileset.
+
+         c.  It SHOULD be possible to access, store, and update
+             information related to a root fileset using the federation
+             protocols.
+
+         d.  It SHOULD be possible to replicate root fileset information
+             across multiple repositories.
+
+         e.  If a root fileset is defined, it SHOULD be possible to
+             enable a fileserver to export that root fileset for client
+             access.
+
+         f.  If a root fileset is defined, it SHOULD be possible for
+             multiple fileservers to project a common root with defined
+             consistency semantics.
+
+         g.  If a root fileset is defined, it SHOULD be stored using a
+             compact representation that is compatible with
+             heterogeneous fileserver implementations.  The root
+             fileset's internal format SHOULD contain enough information
+             to generate any attributes, including referrals, required
+             by the standard filesystem access protocols in R9.
+
+
+
+
+
+
+
+
+
+
+
+Lentini, et al.               Informational                    [Page 20]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+6.  Non-Requirements
+
+   N1:  It is not necessary for the namespace to be known by any
+        specific fileserver.
+
+        In the same manner that clients do not need to have a priori
+        knowledge of the structure of the namespace or its mapping onto
+        federation members, the projected namespace can exist without
+        individual fileservers knowing the entire organizational
+        structure, or, indeed, without knowing exactly where in the
+        projected namespace the filesets they host exist.
+
+        Fileservers do need to be able to handle referrals from other
+        fileservers, but they do not need to know what path the client
+        was accessing when the referral was generated.
+
+   N2:  It is not necessary for updates and accesses to the NSDB data to
+        occur in transaction or transaction-like contexts.
+
+        One possible requirement that is omitted from our current list
+        is that updates and accesses to the data stored in the NSDB (or
+        individual NSDB nodes) occur within a transaction context.  We
+        were not able to agree whether the benefits of transactions are
+        worth the complexity they add (both to the specification and its
+        eventual implementation), but this topic is open for discussion.
+
+        Below is the draft of a proposed requirement that provides
+        transactional semantics:
+
+           There MUST be a way to ensure that sequences of operations,
+           including observations of the namespace (including finding
+           the locations corresponding to a set of FSNs) and changes to
+           the namespace or related data stored in the system (including
+           the creation, renaming, or deletion of junctions, and the
+           creation, altering, or deletion of mappings between FSN and
+           filesystem locations), can be performed in a manner that
+           provides predictable semantics for the relationship between
+           the observed values and the effect of the changes.
+
+           It MUST be possible to protect sequences of operations by
+           transactions with NSDB-wide or server-wide Atomicity,
+           Consistency, Isolation, and Durability (ACID) semantics.
+
+
+
+
+
+
+
+
+
+Lentini, et al.               Informational                    [Page 21]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+7.  Security Considerations
+
+   Assuming the Internet threat model, the federated resolution
+   mechanism described in this document MUST be implemented in such a
+   way to prevent loss of CONFIDENTIALITY, DATA INTEGRITY, and PEER
+   ENTITY AUTHENTICATION, as described in [RFC3552].
+
+   CONFIDENTIALITY may be violated if an unauthorized party is able to
+   eavesdrop on the communication between authorized servers and NSDB
+   nodes and thereby learn the locations or other information about FSNs
+   that they would not be authorized to discover via direct queries.
+   DATA INTEGRITY may be compromised if a third party is able to
+   undetectably alter the contents of the communication between servers
+   and NSDB nodes.  PEER ENTITY AUTHENTICATION is defeated if one server
+   can masquerade as another server without proper authority, or if an
+   arbitrary host can masquerade as a NSDB node.
+
+   Well-established techniques for providing authenticated channels may
+   be used to defeat these attacks, and the protocol MUST support at
+   least one of them.
+
+   For example, if Lightweight Directory Access Protocol (LDAP) is used
+   to implement the query mechanism [RFC4510], then Transport Layer
+   Security (TLS) may be used to provide both authentication and
+   integrity [RFC5246] [RFC4513].  If the query protocol is implemented
+   on top of Open Network Computing / Remote Procedure Call (ONC/RPC),
+   then RPCSEC_GSS may be used to fill the same role [RFC2203]
+   [RFC2743].
+
+   A federation could contain multiple Public Key Infrastructure (PKI)
+   trust anchors [RFC5280].  The federation protocols SHOULD define a
+   mechanism for managing a fileserver's NSDB trust anchors
+   [TA-MGMT-REQS].  A general purpose trust anchor management protocol
+   [TAMP] would be appropriate, though it might be desirable for the
+   federation protocols to facilitate trust anchor management by, for
+   example, using trust anchor interchange formats [TA-FORMAT].
+
+   It is useful to note that the requirements described in this document
+   lead naturally to a system with distributed authorization, which has
+   scalability and manageability benefits.
+
+   FSNs are likely to be long-lived resources.  Therefore, the privilege
+   to create FSNs SHOULD be carefully controlled.  To assist in
+   determining if an FSN is referenced by a junction somewhere in the
+   federation, the NSDB records SHOULD include non-authoritative
+   informational annotations recording the locations of any such
+   junctions.  These annotations are non-authoritative because a
+
+
+
+
+Lentini, et al.               Informational                    [Page 22]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+   junction might be created, deleted, or modified by an individual that
+   does not have permission to modify the NSDB records.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3530]       Shepler, S., Callaghan, B., Robinson, D., Thurlow,
+                   R., Beame, C., Eisler, M., and D. Noveck, "Network
+                   File System (NFS) version 4 Protocol", RFC 3530,
+                   April 2003.
+
+   [RFC3552]       Rescorla, E. and B. Korver, "Guidelines for Writing
+                   RFC Text on Security Considerations", BCP 72,
+                   RFC 3552, July 2003.
+
+   [RFC4122]       Leach, P., Mealling, M., and R. Salz, "A Universally
+                   Unique IDentifier (UUID) URN Namespace", RFC 4122,
+                   July 2005.
+
+   [RFC4510]       Zeilenga, K., "Lightweight Directory Access Protocol
+                   (LDAP): Technical Specification Road Map", RFC 4510,
+                   June 2006.
+
+   [RFC5280]       Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+                   Housley, R., and W. Polk, "Internet X.509 Public Key
+                   Infrastructure Certificate and Certificate Revocation
+                   List (CRL) Profile", RFC 5280, May 2008.
+
+   [RFC5661]       Shepler, S., Eisler, M., and D. Noveck, "Network File
+                   System Version 4 Minor Version 1", RFC 5661,
+                   January 2010.
+
+8.2.  Informative References
+
+   [MS-CIFS]       Microsoft Corporation, "Common Internet File System
+                   (CIFS) Protocol Specification", MS-CIFS 2.0,
+                   November 2009.
+
+   [MS-SMB]        Microsoft Corporation, "Server Message Block (SMB)
+                   Protocol Specification", MS-SMB 17.0, November 2009.
+
+   [MS-SMB2]       Microsoft Corporation, "Server Message Block (SMB)
+                   Version 2 Protocol Specification", MS-SMB2 19.0,
+                   November 2009.
+
+
+
+Lentini, et al.               Informational                    [Page 23]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+   [RFC1094]       Nowicki, B., "NFS: Network File System Protocol
+                   specification", RFC 1094, March 1989.
+
+   [RFC1813]       Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
+                   Version 3 Protocol Specification", RFC 1813,
+                   June 1995.
+
+   [RFC2203]       Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS
+                   Protocol Specification", RFC 2203, September 1997.
+
+   [RFC2743]       Linn, J., "Generic Security Service Application
+                   Program Interface Version 2, Update 1", RFC 2743,
+                   January 2000.
+
+   [RFC4513]       Harrison, R., "Lightweight Directory Access Protocol
+                   (LDAP): Authentication Methods and Security
+                   Mechanisms", RFC 4513, June 2006.
+
+   [RFC5246]       Dierks, T. and E. Rescorla, "The Transport Layer
+                   Security (TLS) Protocol Version 1.2", RFC 5246,
+                   August 2008.
+
+   [TA-FORMAT]     Housley, R., Ashmore, S., and C. Wallace, "Trust
+                   Anchor Format", Work in Progress, October 2009.
+
+   [TA-MGMT-REQS]  Reddy, R. and C. Wallace, "Trust Anchor Management
+                   Requirements", Work in Progress, September 2009.
+
+   [TAMP]          Housley, R., Ashmore, S., and C. Wallace, "Trust
+                   Anchor Management Protocol (TAMP)", Work in Progress,
+                   December 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lentini, et al.               Informational                    [Page 24]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+Appendix A.  Acknowledgments
+
+   We would like to thank Robert Thurlow of Sun Microsystems for helping
+   to author this document.
+
+   We would also like to thank Peter McCann and Nicolas Williams for
+   their comments and suggestions.
+
+Authors' Addresses
+
+   James Lentini
+   NetApp
+   1601 Trapelo Rd, Suite 16
+   Waltham, MA  02451
+   US
+
+   Phone: +1 781-768-5359
+   EMail: jlentini@netapp.com
+
+
+   Craig Everhart
+   NetApp
+   7301 Kit Creek Rd
+   Research Triangle Park, NC  27709
+   US
+
+   Phone: +1 919-476-5320
+   EMail: everhart@netapp.com
+
+
+   Daniel Ellard
+   BBN Technologies
+   10 Moulton Street
+   Cambridge, MA  02138
+   US
+
+   Phone: +1 617-873-8000
+   EMail: dellard@bbn.com
+
+
+   Renu Tewari
+   IBM Almaden
+   650 Harry Rd
+   San Jose, CA  95120
+   US
+
+   EMail: tewarir@us.ibm.com
+
+
+
+
+Lentini, et al.               Informational                    [Page 25]
+
+RFC 5716         Requirements for Federated File Systems    January 2010
+
+
+   Manoj Naik
+   IBM Almaden
+   650 Harry Rd
+   San Jose, CA  95120
+   US
+
+   EMail: manoj@almaden.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lentini, et al.               Informational                    [Page 26]
+