draft-ietf-nfsv4-federated-fs-admin-01.txt   draft-ietf-nfsv4-federated-fs-admin-02.txt 
NFSv4 Working Group J. Lentini NFSv4 Working Group J. Lentini
Internet-Draft C. Everhart Internet-Draft C. Everhart
Intended status: Standards Track NetApp Intended status: Standards Track NetApp
Expires: September 7, 2009 D. Ellard Expires: January 11, 2010 D. Ellard
BBN Technologies BBN Technologies
R. Tewari R. Tewari
M. Naik M. Naik
IBM Almaden IBM Almaden
March 6, 2009 July 10, 2009
Administration Protocol for Federated Filesystems Administration Protocol for Federated Filesystems
draft-ietf-nfsv4-federated-fs-admin-01 draft-ietf-nfsv4-federated-fs-admin-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 September 7, 2009. This Internet-Draft will expire on January 11, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Abstract Abstract
This document describes the administration protocol for a federated This document describes the administration protocol for a federated
file system that enables file access and namespace traversal across file system that enables file access and namespace traversal across
collections of independently administered fileservers. The protocol collections of independently administered fileservers. The protocol
specifies a set of interfaces by which fileservers and collections of specifies a set of interfaces by which fileservers and collections of
fileservers with different administrators can form a fileserver fileservers with different administrators can form a fileserver
federation that provides a namespace composed of the filesystems federation that provides a namespace composed of the filesystems
physically hosted on and exported by the constituent fileservers. physically hosted on and exported by the constituent fileservers.
Table of Contents Requirements Language
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Error Definitions . . . . . . . . . . . . . . . . . . . . . . 5
4. Administrator-Initiated Operations . . . . . . . . . . . . . . 7
4.1. Basic Definition . . . . . . . . . . . . . . . . . . . . . 7
4.2. Required Procedures . . . . . . . . . . . . . . . . . . . 8
4.2.1. FEDFS_CREATE_JUNCTION . . . . . . . . . . . . . . . . 9
4.2.2. FEDFS_DELETE_JUNCTION . . . . . . . . . . . . . . . . 10
4.2.3. FEDFS_LOOKUP_FSN . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 14
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informational References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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].
2. Introduction Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Error Definitions . . . . . . . . . . . . . . . . . . . . . . 3
3. Administrator-Initiated Operations . . . . . . . . . . . . . . 5
3.1. Basic Definition . . . . . . . . . . . . . . . . . . . . . 5
3.2. Required Procedures . . . . . . . . . . . . . . . . . . . 7
3.2.1. FEDFS_CREATE_JUNCTION . . . . . . . . . . . . . . . . 8
3.2.2. FEDFS_DELETE_JUNCTION . . . . . . . . . . . . . . . . 9
3.2.3. FEDFS_LOOKUP_FSN . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informational References . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
A federated filesystem enables file access and namespace traversal in A federated filesystem enables file access and namespace traversal in
a uniform, secure and consistent manner across multiple independent a uniform, secure and consistent manner across multiple independent
fileservers within an enterprise (and possibly across multiple fileservers within an enterprise (and possibly across multiple
enterprises) with reasonably good performance. enterprises) with reasonably good performance.
Traditionally, building a namespace that spans multiple fileservers Traditionally, building a namespace that spans multiple fileservers
has been difficult for two reasons. First, the fileservers that has been difficult for two reasons. First, the fileservers that
export pieces of the namespace are often not in the same export pieces of the namespace are often not in the same
administrative domain. Second, there is no standard mechanism for administrative domain. Second, there is no standard mechanism for
skipping to change at page 5, line 5 skipping to change at page 3, line 36
The requirements for federated namespaces are described in The requirements for federated namespaces are described in
[FEDFS-REQTS]. [FEDFS-REQTS].
The filesystem federation protocol described in [FEDFS-NSDB] allows The filesystem federation protocol described in [FEDFS-NSDB] allows
fileservers from different vendors and/or with different fileservers from different vendors and/or with different
administrators to cooperatively build a namespace. administrators to cooperatively build a namespace.
This document describes the protocol used by administrators to This document describes the protocol used by administrators to
configure the fileservers and construct the namespace. configure the fileservers and construct the namespace.
3. Error Definitions 2. Error Definitions
The results of successful operations will consist of a status of The results of successful operations will consist of a status of
FEDFS_OK. The results of unsuccessful operations will begin with a FEDFS_OK. The results of unsuccessful operations will begin with a
status, other than FEDFS_OK, that indicates the reason why the status, other than FEDFS_OK, that indicates the reason why the
operation failed. operation failed.
Many of the error status names and meanings (and the prose for their Many of the error status names and meanings (and the prose for their
descriptions) are taken from the specification for NFSv4 [RFC3530]. descriptions) are taken from the specification for NFSv4 [RFC3530].
Note, however, that the literal values for the status codes are Note, however, that the literal values for the status codes are
different. different.
skipping to change at page 7, line 5 skipping to change at page 5, line 5
FEDFS_ERR_PERM The operation was not allowed because the caller is FEDFS_ERR_PERM The operation was not allowed because the caller is
either not a privileged user or not the owner of an object that either not a privileged user or not the owner of an object that
would be modified by the operation. would be modified by the operation.
FEDFS_ERR_ROFS A modifying operation was attempted on a read-only FEDFS_ERR_ROFS A modifying operation was attempted on a read-only
filesystem. filesystem.
FEDFS_ERR_SVRFAULT An unanticipated non-protocol error occurred on FEDFS_ERR_SVRFAULT An unanticipated non-protocol error occurred on
the server. the server.
4. Administrator-Initiated Operations 3. Administrator-Initiated Operations
The RPC protocol used by the administration operations is ONC RPC The RPC protocol used by the administration operations is ONC RPC
[RFC1831]. The data structures used for the parameters and return [RFC5531]. The data structures used for the parameters and return
values of these procedures are expressed in this document in XDR values of these procedures are expressed in this document in XDR
[RFC4506]. [RFC4506].
4.1. Basic Definition 3.1. Basic Definition
We begin by defining basic constants and structures, in XDR notation, We begin by defining basic constants and structures, in XDR notation,
that will be used to specify the types of the RPCs described in the that will be used to specify the types of the RPCs described in the
rest of this subsection. rest of this subsection.
<CODE BEGIN> The XDR definitions below are formatted to allow the reader to easily
extract them from the document. The reader can use the following
shell script to extract the definitions:
enum FedFsStatus { <CODE BEGINS>
FEDFS_OK = 0,
FEDFS_ERR_ACCESS = 1,
FEDFS_ERR_BADCHAR = 2,
FEDFS_ERR_BADXDR = 3,
FEDFS_ERR_EXIST = 4,
FEDFS_ERR_INVAL = 5,
FEDFS_ERR_IO = 6,
FEDFS_ERR_NOSPC = 7,
FEDFS_ERR_NOTDIR = 8,
FEDFS_ERR_NOTEMPTY = 9,
FEDFS_ERR_NOTJUNCT = 10,
FEDFS_ERR_NOTLOCAL = 11,
FEDFS_ERR_PERM = 12,
FEDFS_ERR_ROFS = 13,
FEDFS_ERR_SVRFAULT = 14
};
typedef opaque FedFsFsnUuid<16>; #!/bin/sh
typedef opaque FedFsNsdbName<>; grep '^ *///' | sed 's?^ */// ??' | sed 's?^ *///$??'
typedef opaque FedFsPathName<>;
struct FedFsFsn { <CODE ENDS>
FedFsFsnUuid fsnUuid;
FedFsNsdbName nsdbName;
};
struct FedFsCreateJunctionArgs { If the above script is stored in a file called "extract.sh", and this
FedFsPathName path; document is in a file called "spec.txt", then the reader can do:
FedFsFsn fsn;
};
union FedFsLookupFsnRes switch (FedFsStatus status) { <CODE BEGINS>
case FEDFS_OK:
FedFsFsn fsn;
default:
void;
};
program FEDFS_PROG { sh extract.sh < spec.txt > admin1.xdr
version FEDFS_VERSION {
void FEDFS_NULL(void) = 0; <CODE ENDS>
FedFsStatus FEDFS_CREATE_JUNCTION(
FedFsCreateJunctionArgs args) = 1; The effect of the script is to remove leading white space from each
FedFsStatus FEDFS_DELETE_JUNCTION( line, plus a sentinel sequence of "///".
FedFsPathName path) = 2;
FedFsLookupFsnRes FEDFS_LOOKUP_FSN( <CODE BEGIN>
FedFsPathName path) = 3;
} = 1; /// enum FedFsStatus {
} = 100418; /// FEDFS_OK = 0,
/// FEDFS_ERR_ACCESS = 1,
/// FEDFS_ERR_BADCHAR = 2,
/// FEDFS_ERR_BADXDR = 3,
/// FEDFS_ERR_EXIST = 4,
/// FEDFS_ERR_INVAL = 5,
/// FEDFS_ERR_IO = 6,
/// FEDFS_ERR_NOSPC = 7,
/// FEDFS_ERR_NOTDIR = 8,
/// FEDFS_ERR_NOTEMPTY = 9,
/// FEDFS_ERR_NOTJUNCT = 10,
/// FEDFS_ERR_NOTLOCAL = 11,
/// FEDFS_ERR_PERM = 12,
/// FEDFS_ERR_ROFS = 13,
/// FEDFS_ERR_SVRFAULT = 14
/// };
///
/// typedef opaque FedFsFsnUuid<16>;
/// typedef opaque FedFsNsdbName<>;
/// typedef opaque FedFsPathName<>;
///
/// struct FedFsFsn {
/// FedFsFsnUuid fsnUuid;
/// FedFsNsdbName nsdbName;
/// };
///
/// struct FedFsCreateJunctionArgs {
/// FedFsPathName path;
/// FedFsFsn fsn;
/// };
///
/// union FedFsLookupFsnRes switch (FedFsStatus status) {
/// case FEDFS_OK:
/// FedFsFsn fsn;
/// default:
/// void;
/// };
///
/// program FEDFS_PROG {
/// version FEDFS_VERSION {
/// void FEDFS_NULL(void) = 0;
/// FedFsStatus FEDFS_CREATE_JUNCTION(
/// FedFsCreateJunctionArgs args) = 1;
/// FedFsStatus FEDFS_DELETE_JUNCTION(
/// FedFsPathName path) = 2;
/// FedFsLookupFsnRes FEDFS_LOOKUP_FSN(
/// FedFsPathName path) = 3;
/// } = 1;
/// } = 100418;
<CODE END> <CODE END>
The basic data types defined above MUST be formatted as follows: The basic data types defined above MUST be formatted as follows:
FedFsFsnUuid: A universally unique identifier (UUID) as described in FedFsFsnUuid: A universally unique identifier (UUID) as described in
[RFC4122] as a version 1 UUID. The UUID should be formatted in [RFC4122] as a version 1 UUID. The UUID should be formatted in
network byte order. network byte order.
FedFsNsdbName: A variable length UTF-8 string that represents an FedFsNsdbName: A variable length UTF-8 string that represents an
NSDB's network location in either IPv4, IPv6, or DNS host name NSDB's network location in either IPv4, IPv6, or DNS host name
notation. notation.
FedFsPathName: A variable UTF-8 string that represents a file system FedFsPathName: A variable UTF-8 string that represents a file system
path. path.
4.2. Required Procedures 3.2. Required Procedures
Fileservers that participate as "internal" nodes in the federated Fileservers that participate as "internal" nodes in the federated
namespace MUST provide these procedures: namespace MUST provide these procedures:
FEDFS_NULL The null RPC, which is included, by convention, in every FEDFS_NULL The null RPC, which is included, by convention, in every
ONC RPC protocol. ONC RPC protocol.
FEDFS_CREATE_JUNCTION Create a new junction from some location on FEDFS_CREATE_JUNCTION Create a new junction from some location on
the server (defined as a pathname) to an FSN. the server (defined as a pathname) to an FSN.
skipping to change at page 9, line 32 skipping to change at page 8, line 5
manner. Ideally all of the replicas SHOULD be updated before any manner. Ideally all of the replicas SHOULD be updated before any
operation returns. If one or more of the replicas are unavailable, operation returns. If one or more of the replicas are unavailable,
the operation MAY succeed, but the changes MUST be applied before the the operation MAY succeed, but the changes MUST be applied before the
unavailable replicas are brought back online. We assume that unavailable replicas are brought back online. We assume that
replicas are updated via some protocol that permits state changes to replicas are updated via some protocol that permits state changes to
be reflected consistently across the set of replicas in such a manner be reflected consistently across the set of replicas in such a manner
that the replicas will converge to a consistent state within a that the replicas will converge to a consistent state within a
bounded number of successful message exchanges between the servers bounded number of successful message exchanges between the servers
hosting the replicas. hosting the replicas.
4.2.1. FEDFS_CREATE_JUNCTION 3.2.1. FEDFS_CREATE_JUNCTION
This operation creates a junction from a server-relative path to a This operation creates a junction from a server-relative path to a
(potentially) remote fileset named by the given FSN. (potentially) remote fileset named by the given FSN.
The junction directory on the server is named by a pathname in the The junction directory on the server is named by a pathname in the
form of a UTF-8 string that has a well-defined interpretation by the form of a UTF-8 string that has a well-defined interpretation by the
server). It is not required that this path be accessible in any server). It is not required that this path be accessible in any
other manner (e.g., to a client). This path does not appear in the other manner (e.g., to a client). This path does not appear in the
federated namespace, except by coincidence; there is no requirement federated namespace, except by coincidence; there is no requirement
that the global namespace parallel the server namespace, nor is it that the global namespace parallel the server namespace, nor is it
skipping to change at page 10, line 47 skipping to change at page 9, line 21
converted, by this operation, into a junction are the permissions of converted, by this operation, into a junction are the permissions of
the root directory of the target fileset. The original permissions the root directory of the target fileset. The original permissions
of the directory (and any other attributes it might have) are of the directory (and any other attributes it might have) are
subsumed by the junction. subsumed by the junction.
Note that this operation does not create a fileset at the location Note that this operation does not create a fileset at the location
targeted by the junction. If the target fileset does not exist, the targeted by the junction. If the target fileset does not exist, the
junction will still be created. An NFS client will discover the junction will still be created. An NFS client will discover the
missing fileset when it traverses the junction. missing fileset when it traverses the junction.
4.2.2. FEDFS_DELETE_JUNCTION 3.2.2. FEDFS_DELETE_JUNCTION
This operation removes a junction specified by a server-relative This operation removes a junction specified by a server-relative
path. path.
As with FEDFS_CREATE_JUNCTION, the junction on the server is named by As with FEDFS_CREATE_JUNCTION, the junction on the server is named by
a pathname in the form of a UTF-8 string that has a well-defined a pathname in the form of a UTF-8 string that has a well-defined
interpretation by the server. It is not required that this path be interpretation by the server. It is not required that this path be
accessible in any other manner (e.g., to a client). This path does accessible in any other manner (e.g., to a client). This path does
not appear in the federated namespace, except by coincidence; there not appear in the federated namespace, except by coincidence; there
is no requirement that the global namespace reflect the server is no requirement that the global namespace reflect the server
namespace, nor is it required that this path be relative to the namespace, nor is it required that this path be relative to the
server pseudo-root. It does not need to be a path that is accessible server pseudo-root. It does not need to be a path that is accessible
via NFS. via NFS.
If the fileset is read-only, then this operation SHOULD indicate this If the fileset is read-only, then this operation SHOULD indicate this
with a status of FEDFS_ERR_ROFS. with a status of FEDFS_ERR_ROFS.
If the path contains an invalid UTF-8 character, then status If the path contains an invalid UTF-8 character, then status
FEDFS_ERR_BADCHAR must be returned. FEDFS_ERR_BADCHAR must be returned.
It is NOT REQUIRED that the path used to delete a junction is the The path used to delete a junction might not be the same path that
same path that was used to create the junction. If the namespace on was used to create the junction. If the namespace on the server has
the server has changed, then the junction may now appear at a changed, then the junction may now appear at a different path than
different path than where it was created. If there is more than one where it was created. If there is more than one valid path to the
valid path to the junction, any of them may be used. junction, any of them may be used.
The path is REQUIRED to exist and be completely local to the server. The path is REQUIRED to exist and be completely local to the server.
It MUST NOT contain a junction, except as the final component, which It MUST NOT contain a junction, except as the final component, which
MUST be a junction. If any other component of the path is a MUST be a junction. If any other component of the path is a
junction, then this operation MUST fail with status junction, then this operation MUST fail with status
FEDFS_ERR_NOTLOCAL. If the last component of the path is not a FEDFS_ERR_NOTLOCAL. If the last component of the path is not a
junction then this operation MUST return status FEDFS_ERR_INVAL. The junction then this operation MUST return status FEDFS_ERR_INVAL. The
path may contain a symbolic link (if supported by the local server), path may contain a symbolic link (if supported by the local server),
but the traversal of the path must remain within the server-local but the traversal of the path must remain within the server-local
namespace. namespace.
skipping to change at page 12, line 6 skipping to change at page 10, line 28
The removal of the association between the path and the FSN MUST be The removal of the association between the path and the FSN MUST be
durable before the operation may return successfully. If the durable before the operation may return successfully. If the
operation return codes indicates success, then the caller may assume operation return codes indicates success, then the caller may assume
that the junction was successfully destroyed. that the junction was successfully destroyed.
The effective permissions and other attributes of the directory that The effective permissions and other attributes of the directory that
is restored by this operation SHOULD be identical to their value is restored by this operation SHOULD be identical to their value
prior to the creation of the junction. prior to the creation of the junction.
4.2.3. FEDFS_LOOKUP_FSN 3.2.3. FEDFS_LOOKUP_FSN
This operation queries a server to determine whether a given path This operation queries a server to determine whether a given path
ends in a junction, and if so, the FSN to which the junction refers. ends in a junction, and if so, the FSN to which the junction refers.
Ordinary NFSv4 operations do not provide any general mechanism to Ordinary NFSv4 operations do not provide any general mechanism to
determine whether an object is a junction -- there is no encoding determine whether an object is a junction -- there is no encoding
specified by the NFSv4 protocol that can represent this information. specified by the NFSv4 protocol that can represent this information.
As with FEDFS_CREATE_JUNCTION, the pathname must be in the form of a As with FEDFS_CREATE_JUNCTION, the pathname must be in the form of a
UTF-8 string that has a well-defined interpretation by the server. UTF-8 string that has a well-defined interpretation by the server.
It is not required that this path be accessible in any other manner It is not required that this path be accessible in any other manner
(e.g., to a client). This path does not appear in the federated (e.g., to a client). This path does not appear in the federated
namespace, except by coincidence; there is no requirement that the namespace, except by coincidence; there is no requirement that the
global namespace reflect the server namespace, nor is it required global namespace reflect the server namespace, nor is it required
that this path be relative to the server pseudo-root. It does not that this path be relative to the server pseudo-root. It does not
need to be a path that is accessible via NFS. need to be a path that is accessible via NFS.
If the path contains an invalid UTF-8 character, then status If the path contains an invalid UTF-8 character, then status
FEDFS_ERR_BADCHAR must be returned. FEDFS_ERR_BADCHAR must be returned.
It is NOT REQUIRED that the path used to lookup a junction is the The path used to lookup a junction might not be the same path that
same path that was used to create the junction. If the namespace on was used to create the junction. If the namespace on the server has
the server has changed, then a junction may now appear at a different changed, then a junction may now appear at a different path than
path than where it was created. If there is more than one valid path where it was created. If there is more than one valid path to the
to the junction, any of them may be used. junction, any of them may be used.
The path is REQUIRED to exist and be completely local to the server. The path is REQUIRED to exist and be completely local to the server.
It MUST NOT contain a junction, except as the final component. If It MUST NOT contain a junction, except as the final component. If
any other component of the path is a junction, then this operation any other component of the path is a junction, then this operation
MUST fail with status FEDFS_ERR_NOTLOCAL. If the last component of MUST fail with status FEDFS_ERR_NOTLOCAL. If the last component of
the path is not a junction then this operation MUST return the status the path is not a junction then this operation MUST return the status
FEDFS_ERR_NOTJUNCT. The path may contain a symbolic link (if FEDFS_ERR_NOTJUNCT. The path may contain a symbolic link (if
supported by the local server), but the traversal of the path must supported by the local server), but the traversal of the path must
remain within the server-local namespace. remain within the server-local namespace.
The server MAY enforce the local permissions on the path, including The server MAY enforce the local permissions on the path, including
the final component. If the path cannot be traversed because of the final component. If the path cannot be traversed because of
insufficient permissions, or the parent directory of the junction insufficient permissions, or the parent directory of the junction
unexecutable or unwritable directory, then the operation MAY fail unexecutable or unwritable directory, then the operation MAY fail
with status FEDFS_ERR_ACCESS. with status FEDFS_ERR_ACCESS.
5. Security Considerations 4. Security Considerations
The ONC RPC protocol supports authentication, integrity and privacy The ONC RPC protocol supports authentication, integrity and privacy
via the RPCSEC_GSS framework [RFC2203]. Fileservers which support via the RPCSEC_GSS framework [RFC2203]. Fileservers which support
the FedFS administration protocol described above MUST support the FedFS administration protocol described above MUST support
RPCSEC_GSS. RPCSEC_GSS.
6. IANA Requirements 5. IANA Considerations
A range of ONC RPC program numbers were assigned for use by FedFS as A range of ONC RPC program numbers were assigned for use by FedFS
described in section 7.3 "Program Number Assignment" of [RFC1831]: using the procedure described in Section 7.3 "Program Number
Assignment" of [RFC5531]. The FedFS range is:
IETF NFSv4 Working Group - FedFS 100418 - 100421 IETF NFSv4 Working Group - FedFS 100418 - 100421
This assignment is recorded in Section 17 "Appendix C: Current number
assignments" of [RFC1831bis].
This document describes version 1 of the ONC RPC program 100418. This document describes version 1 of the ONC RPC program 100418.
7. Conclusions 6. Glossary
The federated filesystem protocol manages multiple independently
administered fileservers to share namespace and referral information
to enable clients to traverse seamlessly across them.
8. 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.
skipping to change at page 19, line 5 skipping to change at page 13, line 44
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.
9. References 7. References
9.1. Normative References 7.1. Normative 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.
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, August 1995.
[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.
[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.
[RFC4506] Eisler, M., "XDR: External Data Representation Standard", [RFC4506] Eisler, M., "XDR: External Data Representation Standard",
STD 67, RFC 4506, May 2006. STD 67, RFC 4506, May 2006.
9.2. Informational References [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, May 2009.
7.2. Informational References
[FEDFS-NSDB] [FEDFS-NSDB]
J. Lentini, et al., "NSDB Protocol for Federated J. Lentini, et al., "NSDB Protocol for Federated
Filesystems (Work In Progress)", Filesystems (Work In Progress)",
draft-ietf-nfsv4-federated-fs-admin , 2009. draft-ietf-nfsv4-federated-fs-admin , 2009.
[FEDFS-REQTS] [FEDFS-REQTS]
J. Lentini, et al., "Requirements for Federated File J. Lentini, et al., "Requirements for Federated File
Systems (Work In Progress)", Systems (Work In Progress)",
draft-ietf-nfsv4-federated-fs-reqts , 2008. draft-ietf-nfsv4-federated-fs-reqts , 2008.
[NFSv4.1] S. Shepler, et al., "NFS Version 4 Minor Version 1 (Work [NFSv4.1] S. Shepler, et al., "NFS Version 4 Minor Version 1 (Work
In Progress)", draft-ietf-nfsv4-minorversion1 , 2008. In Progress)", draft-ietf-nfsv4-minorversion1 , 2008.
[RFC1831bis]
Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2 (Work In Progress)",
draft-ietf-nfsv4-rfc1831bis-13 , 2009.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
Appendix A. Acknowledgments Appendix A. Acknowledgments
We would like to thank Paul Lemahieu of EMC, Robert Thurlow of Sun We would like to thank Paul Lemahieu of EMC, Robert Thurlow of Sun
Microsystems, and Mario Wurzl of EMC for helping to author this Microsystems, and Mario Wurzl of EMC for helping to author this
document. document.
 End of changes. 33 change blocks. 
116 lines changed or deleted 124 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/