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

This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/