draft-ietf-nfsv4-federated-fs-reqts-00.txt   draft-ietf-nfsv4-federated-fs-reqts-01.txt 
Network Working Group D. Ellard NFSv4 Working Group J. Lentini
Internet-Draft BBN Technologies Internet-Draft C. Everhart
Intended status: Standards Track C. Everhart Intended status: Informational NetApp
Expires: March 30, 2009 J. Lentini Expires: June 26, 2009 D. Ellard
NetApp BBN Technologies
R. Tewari R. Tewari
M. Naik M. Naik
IBM Almaden IBM Almaden
September 26, 2008 December 23, 2008
Requirements for Federated File Systems Requirements for Federated File Systems
draft-ietf-nfsv4-federated-fs-reqts-00.txt draft-ietf-nfsv4-federated-fs-reqts-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 30, 2009. This Internet-Draft will expire on June 26, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2008 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.
Abstract Abstract
This draft 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. Our intent is to federated file system and defines related terms.
use this draft as a starting point and refine it, with input and
feedback from the file system community and other interested parties,
until we reach general agreement. We will then begin, again with the
help of any interested parties, to define standard, open federated
file system protocols that satisfy these requirements and are
suitable for implementation and deployment.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Draft Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Examples and Discussion . . . . . . . . . . . . . . . . . . . 7
5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8 4.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 7
5.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 8 4.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 7
5.1.1. Creating a Fileset and a FSN . . . . . . . . . . . . . 8 4.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 8
5.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 9 4.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 8
5.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 9 4.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 10
5.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 11 5. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 15
7. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 15 6.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 15
7.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 15 6.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 7. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 24
8. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.2. Informational References . . . . . . . . . . . . . . . . . 27
11.2. Informational References . . . . . . . . . . . . . . . . . 27 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Note, that this is a requirements document, and in many instances Note, that this is a requirements document, and in many instances
where these words are used in this document they refer to qualities where these words are used in this document they refer to qualities
of a specification for a system that satisfies the document, or of a specification for a system that satisfies the document, or
requirements of a system that matches that specification. These requirements of a system that matches that specification. These
cases are distinguished when there is potential for ambiguity. cases are distinguished when there is potential for ambiguity.
2. Draft Goals 2. Overview
This draft 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. Our intent is to federated file system and defines related terms.
use this draft as a starting point and refine it, with input and
feedback from the file system community and other interested parties,
until we reach general agreement. We will then begin, again with the
help of any interested parties, to define standard, open federated
file system protocols that satisfy these requirements and are
suitable for implementation and deployment.
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.
For the first version of this document, we are focused on the
following questions:
o Are any "MUST" requirements missing?
o Are there any "MUST" requirements that should be "SHOULD" or
"MAY"?
o Are there any "SHOULD" requirements that should be "MAY"?
o Are there better ways to articulate the requirements?
3. Overview
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 junctions. 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 -- the fileservers, the clients, or by an external namespace service, and is
mechanisms used to assemble the namespace may vary depending on the often not easy or uniform to manage. The requirements in this draft
filesystem access protocol used by the client. are meant to lead to a uniform server-based namespace that is capable
of spanning a whole enterprise and which is easy to manage.
These fileserver collections are, in general, administered by a
single administrative entity. This administrator builds the
namespace out of the filesystem resources and junctions. There are
also singleton servers that export some or all of their filesystem
resources, but which do not contain junctions to other filesystems.
Current server collections that provide a shared namespace usually do
so by means of a service that maps filesystem names to filesystem
locations. We refer to this as a namespace database service (NSDB).
In some distributed file systems, this service is embodied as a
volume location database (VLDB), and may be implemented by LDAP, NIS,
or any number of other mechanisms.
We use the term "fileset" to represent the abstraction of a We define some terms to better describe the solution space. A
filesystem. The fileset abstraction implies very little about how "fileset" is the abstract view of a filesystem in a uniform
the fileset is implemented, although in the simplest case a fileset namespace, and may be implemented behind that abstraction by one or
can be implemented by an exported filesystem. A fileset is a more physical filesystems at any given time. Each fileset has a name
directory tree that may contain files and references, called called an "FSN" (fileset name), and each physical filesystem has a
"junction", to other filesets. Each fileset has a fileset globally fileset location ("FSL"). A fileset is a directory tree containing
unique name (FSN) that is used as an identifier for the fileset. files and directories, and it may also contain references to other
Each implementation of a given fileset is specified by its fileset filesets. These references are called "junctions". To provide
location (FSL). 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 FSN to 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.
The primary purpose of the NSDB service is to provide a level of The servers direct clients to the proper locations by existing
indirection between the FSN the FSLs. If the NSDB service permits mechanisms (e.g. the referrals mechanism within [RFC3530] and
updates to the set of mappings, then the FSLs may be changed (e.g., [NFSv4.1 RFC TBD]). Updates to the locations make it possible to
moved or replicated) in a manner that is transparent to the referring support migration and replication of physical filesystems that
fileset and its server(s). comprise the namespace, in a way that is transparent to filesystem
clients.
Current approaches are unsuitable to build common namespaces across Figure 1 shows an example of a federation. This federation has two
systems with multiple administrative domains and multiple NSDB nodes. members, named ALPHA and BETA. Federation members may contain an
An approach which requires changing existing NSDB nodes to arbitrary number of file servers and NSDB nodes; in this illustration
collaborate or replacing them with a single NSDB node, while ALPHA and BETA each have three servers and one NSDB node.
possible, is not desirable.
Figure Figure 1 shows an example of a federation. This federation +----------------------+ +----------------------+
has two members, named ALPHA and BETA. Federation members may | Federation Member | | Federation Member |
contain an arbitrary number of file servers and NSDB nodes; in this | ALPHA | | BETA |
illustration ALPHA and BETA each have three servers and one NSDB | | | |
node. | | | |
| +------------+ | | +------------+ |
| | NSDB | | | | NSDB | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| | | |
| +----------+ | | +----------+ |
| | | | | | | |
| +-- | Servers | | | +-- | Servers | |
| | | | | | | | | |
| +-- | | | | | +-- | | | |
| | | +----------+ | | | | +----------+ |
| | | | | | | | | |
| | +----------+ | | | +----------+ |
| | | | | | | |
| +----------+ | | +----------+ |
+----------------------+ +----------------------+
A federation with two members, ALPHA and BETA. ALPHA and BETA each A federation with two members, ALPHA and BETA. ALPHA and BETA each
have their own NSDB node and several file servers, but are have their own NSDB node and several file servers, and they are
administered separately. administered separately.
Figure 1 Figure 1
4. Purpose 3. Purpose
Our objective is to specify a set of interfaces (and corresponding Our objective is to specify a set of protocols by which fileservers
protocols) by which such fileservers and collections of fileservers, or collections of fileservers, with different administrators, can
with different administrators, can form a federation of fileservers form a federation of fileservers and NSDB nodes that provides a
and NSDB nodes that provides a namespace composed of the filesets namespace composed of the filesets hosted on the different
hosted on the different fileservers and fileserver collections. fileservers and fileserver collections.
It should be possible, using a system that implements the interfaces, 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
federation. It should also be possible for different fileservers in federation. It should also be possible for different fileservers in
the federation to project different namespaces and enable clients to the federation to project different namespaces and enable clients to
traverse them. traverse them.
Such a federation may contain an arbitrary number of NSDB nodes, each Such a federation may contain an arbitrary number of NSDB nodes, each
belonging to a different administrative entity, and each providing belonging to a different administrative entity, and each providing
the mappings that define a part of a namespace. Such a federation the mappings that define a part of a namespace. Such a federation
may also have an arbitrary number of administrative entities, each may also have an arbitrary number of administrative entities, each
responsible for administering a subset of the servers and NSDB nodes. responsible for administering a subset of the fileservers and NSDB
Acting in concert, the administrators should be able to build and nodes. Acting in concert, the administrators should be able to build
administer this multi-fileserver, multi-collection namespace. and administer this multi-fileserver, multi-collection namespace.
Each singleton server can be presumed to provide its own NSDB node,
for example with a trivial mapping to local FSLs.
It is not the intent of the federation to guarantee namespace It is not the intent of the federation to guarantee namespace
consistency across all client views. Since different parts of the consistency across all client views. Since different parts of the
namespace may be administered by different entities, it is possible namespace may be administered by different entities, it is possible
that a client could be accessing a stale area of the namespace 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 one entity because a part of the namespace above it,
managed by another entity, has changed. managed by another entity, has changed.
5. Examples and Discussion 4. 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.
5.1. Create a Fileset and its FSL(s) 4.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 their containing
directory tree. The fileset abstraction is the fundamental unit of directory tree. The fileset abstraction is the fundamental unit of
data management in the federation. This abstraction is implemented data management in the federation. This abstraction is implemented
by an actual directory tree whose root location is specified by a by an actual directory tree whose root location is specified by a
fileset location (FSL). 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
skipping to change at page 8, line 36 skipping to change at page 7, line 36
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
how the FSN that binds the FSL is created, and whether other replicas 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 of the fileset exist, are known to the federation, and need to be
bound to the same FSN. bound to the same FSN.
It is easiest to describe this in terms of how to create the initial 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. implementation of the fileset, and then describe how to add replicas.
5.1.1. Creating a Fileset and a FSN 4.1.1. Creating a Fileset and an FSN
1. Choose the NSDB node that will keep track of the FSL(s) and 1. Choose the NSDB node that will keep track of the FSL(s) and
related information for the fileset. related information for the fileset.
2. Request that the NSDB node register a new FSN 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 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 The latter case is used if the fileset is being restored, perhaps
as part of disaster recovery, and the server wishes to specify as part of disaster recovery, and the server wishes to specify
the FSN in order to permit existing junctions that reference that the FSN in order to permit existing junctions that reference that
skipping to change at page 9, line 10 skipping to change at page 8, line 10
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 info and creates the initial FSL for
the fileset. the fileset.
5.1.2. Adding a Replica of a Fileset 4.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 interfaces 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 interface dependent operation (at least at this time). The only requirement is
required is the ability to register or remove the registration of that these fileset replicas be registered and unregistered with the
replicas for a fileset. NSDB.
5.2. Junction Resolution 4.2. Junction Resolution
A fileset may contain references to other filesets. These references A fileset may contain references to other filesets. These references
are represented by junctions. If a client requests access to a are represented by junctions. If a client requests access to a
fileset object that is a junction, the server resolves the junction fileset object that is a junction, the server resolves the junction
to discover the FSL(s) that implements the referenced fileset. to discover the FSL(s) that implements the referenced fileset.
There are many possible variations to this procedure, depending on There are many possible variations to this procedure, depending on
how the junctions are represented and how the information necessary how the junctions are represented and how the information necessary
to perform resolution is represented by the server. In this example, to perform resolution is represented by the server.
we assume that the only thing directly expressed by the junction is
the junction key; its mapping to FSN can be kept local to the server
hosting the junction.
Step 5 is the only step that interacts directly with the federation Step 4 is the only step that interacts directly with the federation
interfaces. The rest of the steps may use platform-specific protocols. The rest of the steps may use platform-specific
interfaces. interfaces.
1. The server determines that the object being accessed is a 1. The server determines that the object being accessed is a
junction. junction.
2. The server determines the junction key for the junction. 2. Using the junction, the server does a local lookup to find the
FSN of the target fileset.
3. Using the junction key, the server does a local lookup to find
the FSN of the target fileset.
4. 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.
5. 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.
6. The server converts the FSL to the location type used by the 5. The server converts one of the FSLs to the location type used by
client (e.g., fs_location for NFSv4, as described in [RFC3530]). the client (e.g., fs_location for NFSv4, as described in
[RFC3530]).
7. 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
skipping to change at page 11, line 5 skipping to change at page 10, line 5
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.
+---------------+
| |
| Client | >--------------------------+
| | |
+---------------+ |
v ^ |
+-----+---+-------------+ +-----------------+-----+
| | | Federation| |Federation | |
| | | member | |member | |
| | | ALPHA | |BETA | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | +---------+ | |
| | | +---------+------+-> | | | |
| | | | | | | NSDB Y | | |
| | | | +-----+------+-< | | | |
| | | | | | | +---------+ | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| 1| 4| 2| 3| | | 5| |
| v ^ ^ v | | v |
| +---------------+ | | +---------------+ |
| | | | | | | |
| | Server X | | | | Server Y | |
| | | | | | | |
| +---------------+ | | +---------------+ |
| | | |
+-----------------------+ +-----------------------+
Figure 2 Figure 2
5.3. Junction Creation 4.3. Junction Creation
Given a local path, a remote export and a path relative to that Given a local path, a remote export and a path relative to that
export, create a junction from the local path to the path within the export, create a junction from the local path to the path within the
remote export. remote export.
There are many possible variations to this procedure, depending on There are many possible variations to this procedure, depending on
how the junctions are represented and how the information necessary how the junctions are represented and how the information necessary
to perform resolution is represented by the server. In this example, to perform resolution is represented by the server.
we assume that the only thing directly expressed by the junction is
the junction key; its mapping to FSN can be kept local to the server
hosting the junction.
Step 1 is the only step that uses the federation interfaces. The Step 1 is the only step that uses the federation interfaces. The
rest of the steps may use platform-specific interfaces. rest of the steps may use platform-specific interfaces.
1. Contact the server named by the export and ask for the FSN for 1. Contact the server named by the export and ask for the FSN for
the fileset, given its path relative to that export. the fileset, given its path relative to that export.
2. Create a new local junction key. 2. Insert the junction to the FSN, at the given path, into the local
3. Insert, in the local junction info table, a mapping from the
local junction key to the FSN.
4. Insert the junction, at the given path, into the local
filesystem. filesystem.
6. Glossary 5. Glossary
The phrase "USING THE FEDERATION INTERFACES" implies that the
subsequent requirement must be satisfied, in its entirety, via the
federation interfaces.
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.
skipping to change at page 13, line 17 skipping to change at page 13, line 16
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.
Junction key: The UUID of a fileset, used as a key to lookup an FSN
within an NSDB node or a local table of information about
junctions.
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 15, line 5 skipping to change at page 15, line 5
Server Collection: A set of fileservers administered as a unit. A Server Collection: A set of fileservers administered as a unit. A
server collection may be administered with vendor-specific server collection may be administered with vendor-specific
software. software.
The namespace provided by a server collection could be part of the The namespace provided by a server collection could be part of the
federated namespace. federated namespace.
Singleton Server: A server collection containing only one server; a Singleton Server: A server collection containing only one server; a
stand-alone fileserver. stand-alone fileserver.
7. Proposed Requirements 6. 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 Note that the requirements are described in terms of correct behavior
by all entities. We do not address the requirements of the system in by all entities. We do not address the requirements of the system in
the presence of faults. the presence of faults.
7.1. Basic Assumptions 6.1. Basic Assumptions
Several of the requirements are so fundamental that we treat them as Several of the requirements are so fundamental that we treat them as
basic assumptions; if any of these assumptions are violated, the rest basic assumptions; if any of these assumptions are violated, the rest
of the requirements must be reviewed in their entirety. of the requirements must be reviewed in their entirety.
A1: The federation protocols do not require any changes to existing A1: The federation protocols do not require any changes to existing
client-facing protocols, and MAY be extended to incorporate new client-facing protocols, and MAY be extended to incorporate new
client-facing protocols. client-facing protocols.
A2: A client SHOULD NOT require any a priori knowledge of the A2: A client SHOULD NOT require any a priori knowledge of the
skipping to change at page 16, line 38 skipping to change at page 16, line 42
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 that they
have access to. have access to.
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 a FSN MUST express, or can A6: In a federated system, we assume that an FSN MUST express, or
be used to discover, the following two pieces of information: can be used to discover, the following two pieces of
information:
1. The location of the NSDB node that is responsible for 1. The location of the NSDB node that is responsible for
knowing the filesystem location(s) (FSLs) of the named knowing the filesystem location(s) (FSLs) of the named
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 FQDN of the server hosting the NSDB
node. Another approach is to use a separate DNS-style node. Another approach is to use a separate DNS-style
hierarchy to resolve the location of the NSDB node. hierarchy to resolve the location of the NSDB node.
2. The junction key. 2. The FSN identifier.
The junction key is the index used by the NSDB node to The FSN identifier is the index used by the NSDB node to
identify the FSN of the target fileset. identify the target fileset.
There are several ways to represent junction keys. 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 UUIDs as described described in
[RFC4122]. [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.example.com/UUID where nsdb.example.com is the FQDN of the nsdb.example.com/UUID where nsdb.example.com is the FQDN of the
server hosting the NSDB node and UUID is the string server hosting the NSDB node and UUID is the string
representation of the junction key. 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
node "near" the server. node "near" the server.
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
skipping to change at page 18, line 5 skipping to change at page 18, line 9
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
correctly. correctly.
7.2. Requirements 6.2. Requirements
R1: Requirements of each FSN: R1: Requirements of each FSN:
a. Each FSN MUST be globally unique. 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 b. The FSN MUST be sufficiently descriptive to locate an
instance of the fileset it names within the federation at instance of the fileset it names within the federation at
any time. any time.
c. An FSN is a name of a fileset. (An FSL is not the name of c. All FSNs MUST be invariant when their underlying
a fileset, but only a locator of an instance of a fileset filesystems move or are replicated; only mappings from FSN
at some point in time. For example, the same FSL may to FSL(s) change under these transformations.
implement different filesets at different times.)
+ If a fileset instance is moved to a new location, it
will have a new FSL, but its FSN is unchanged.
+ An instance of a different fileset may be placed at a
FSL previously occupied by an instance of a different
fileset.
d. If a fileset instance is migrated to another location, the
FSN remains the same in the new location.
e. If the fileset is replicated using the federation d. All files accessible from the global namespace MUST be part
interfaces, then all of the replicas have the same FSN. of a fileset that has an assigned FSN.
Not all filesets in the federation are required to have a FSN Not all filesets in the federation are required to have an FSN
or be reachable by a 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.
NOTE: this requirement has been called into question.
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 an NFS 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
nonexistant FSL to an FSN. It is also possible to create a nonexistant 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
skipping to change at page 19, line 21 skipping to change at page 19, line 13
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 junction key) 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 junction key. 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
wish to replicate to a new filesystem. wish to replicate to a new filesystem.
skipping to change at page 20, line 47 skipping to change at page 20, line 39
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
process). process).
If an FSN is invalidated, clients who are already viewing the If an FSN is invalidated, clients who are already viewing the
fileset named by the FSN MAY continue to view the old fileset named by the FSN MAY continue to view the old
namespace. They might not discover that the FSN is no longer namespace. They might not discover that the FSN is no longer
valid until they try to traverse a junction that refers to it. valid until they try to traverse a junction that refers to it.
R6: USING THE FEDERATION INTERFACES, it MUST be possible to R6: USING THE FEDERATION INTERFACES, it MUST be possible to
invalidate a FSL. invalidate an FSL.
a. An invalid FSL MUST NOT be returned as the result of a. An invalid FSL MUST NOT be returned as the result of
resolving a junction. resolving a junction.
An FSL that has been invalidated MAY become valid again if the An FSL that has been invalidated MAY become valid again if the
FSL is recreated (i.e., as part of a disaster recovery FSL is recreated (i.e., as part of a disaster recovery
process). process).
If an FSL is invalidated, clients who are already viewing the If an FSL is invalidated, clients who are already viewing the
fileset implemented by the FSL MAY continue to use that FSL. fileset implemented by the FSL MAY continue to use that FSL.
skipping to change at page 21, line 21 skipping to change at page 21, line 13
implemented by the FSL. implemented by the FSL.
Note that invalidating an FSL does not imply that the Note that invalidating an FSL does not imply that the
underlying export or share (depending on the file access underlying export or share (depending on the file access
protocol in use) is changed in any way -- it only changes the protocol in use) is changed in any way -- it only changes the
mappings from FSNs to FSLs on the NSDB. mappings from FSNs to FSLs on the NSDB.
R7: It MUST be possible for the federation of servers to provide R7: It MUST be possible for the federation of servers to provide
multiple namespaces. multiple namespaces.
R8: USING THE FEDERATION INTERFACES, it MUST be possible to perform R8: USING THE FEDERATION INTERFACES:
queries about the state of objects relevant to the
implementation of the federation namespace.
It MUST be possible to query the fileserver named in an FSL to a. It MUST be possible to query the fileserver named in an FSL
discover whether a junction exists at a given path within that to discover whether a junction exists at a given path
FSL. within that 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
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 R9: The projected namespace (and the objects named by the
namespace) MUST be accessible to clients via at least one namespace) MUST be accessible to clients via at least one
standard filesystem access protocol. standard filesystem access protocol.
a. The namespace SHOULD be accessible to clients via the CIFS a. The namespace SHOULD be accessible to clients via versions
protocol. of the CIFS (SMB) protocol.
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].
skipping to change at page 23, line 21 skipping to change at page 23, line 18
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 a 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 a FSL. query the system to find the annotations for an FSL.
8. Non-Requirements 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 file server to export that root fileset for client
access.
f. If a root fileset is defined it SHOULD be possible for
multiple file servers to project a common root with defined
consistency semantics.
7. 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.
In the same manner that clients do not need to have a priori In the same manner that clients do not need to have a priori
knowledge of the structure of the namespace or its mapping onto knowledge of the structure of the namespace or its mapping onto
federation members, the projected namespace can exist without federation members, the projected namespace can exist without
individual fileservers knowing the entire organizational individual fileservers knowing the entire organizational
structure, or, indeed, without knowing exactly where in the structure, or, indeed, without knowing exactly where in the
projected namespace the filesets they host exist. projected namespace the filesets they host exist.
skipping to change at page 25, line 5 skipping to change at page 25, line 5
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 ACID semantics."
9. IANA Requirements 8. Security Considerations
This document has no actions for IANA.
10. 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.
skipping to change at page 26, line 28 skipping to change at page 25, line 28
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 LDAP is used to implement the query mechanism
[RFC4511], then TLS may be used to provide both authentication and [RFC4511], then TLS may be used to provide both authentication and
integrity [RFC4346] [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 ONC/RPC, then RPCSEC_GSS may be used to fill the same role
[RFC2203] [RFC2743]. [RFC2203] [RFC2743].
11. References 9. IANA Considerations
11.1. Normative References This document has no actions for IANA.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
skipping to change at page 27, line 30 skipping to change at page 27, line 30
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006. (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol [RFC4513] Harrison, R., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms", (LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006. RFC 4513, June 2006.
11.2. Informational References [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
10.2. Informational References
[RFC1094] Nowicki, B., "NFS: Network File System Protocol [RFC1094] Nowicki, B., "NFS: Network File System Protocol
specification", RFC 1094, March 1989. specification", RFC 1094, March 1989.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, June 1995. Version 3 Protocol Specification", RFC 1813, June 1995.
Appendix A. Acknowledgements
We would like to thank Robert Thurlow of Sun Microsystems for helping
to author this document.
Authors' Addresses Authors' Addresses
Daniel Ellard James Lentini
BBN Technologies NetApp
10 Moulton Street 1601 Trapelo Rd, Suite 16
Cambridge, MA 02138 Waltham, MA 02451
US US
Phone: +1 617-873-8000 Phone: +1 781-768-5359
Email: ellard@gmail.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
James Lentini Daniel Ellard
NetApp BBN Technologies
1601 Trapelo Rd, Suite 16 10 Moulton Street
Waltham, MA 02451 Cambridge, MA 02138
US US
Phone: +1 781-768-5359 Phone: +1 617-873-8000
Email: jlentini@netapp.com Email: ellard@gmail.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
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 76 change blocks. 
234 lines changed or deleted 262 lines changed or added

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