draft-ietf-nfsv4-federated-fs-admin-03.txt   draft-ietf-nfsv4-federated-fs-admin-04.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: April 29, 2010 D. Ellard Expires: July 25, 2010 D. Ellard
BBN Technologies BBN Technologies
R. Tewari R. Tewari
M. Naik M. Naik
IBM Almaden IBM Almaden
October 26, 2009 January 21, 2010
Administration Protocol for Federated Filesystems Administration Protocol for Federated Filesystems
draft-ietf-nfsv4-federated-fs-admin-03 draft-ietf-nfsv4-federated-fs-admin-04
Abstract
This document describes the administration protocol for a federated
file system that enables file access and namespace traversal across
collections of independently administered fileservers. The protocol
specifies a set of interfaces by which fileservers with different
administrators can form a fileserver federation that provides a
namespace composed of the filesystems physically hosted on and
exported by the constituent fileservers.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering 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 April 29, 2010. This Internet-Draft will expire on July 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes the administration protocol for a federated described in the BSD License.
file system that enables file access and namespace traversal across
collections of independently administered fileservers. The protocol
specifies a set of interfaces by which fileservers and collections of
fileservers with different administrators can form a fileserver
federation that provides a namespace composed of the filesystems
physically hosted on and exported by the constituent fileservers.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document may contain material from IETF Documents or IETF
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Contributions published or made publicly available before November
document are to be interpreted as described in [RFC2119]. 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Error Definitions . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Administrator-Initiated Operations . . . . . . . . . . . . . . 6 3. Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Basic Definition . . . . . . . . . . . . . . . . . . . . . 6 4. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Required Procedures . . . . . . . . . . . . . . . . . . . 8 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. FEDFS_CREATE_JUNCTION . . . . . . . . . . . . . . . . 9 5.1. FEDFS_CREATE_JUNCTION . . . . . . . . . . . . . . . . . . 11
3.2.2. FEDFS_DELETE_JUNCTION . . . . . . . . . . . . . . . . 10 5.2. FEDFS_DELETE_JUNCTION . . . . . . . . . . . . . . . . . . 13
3.2.3. FEDFS_LOOKUP_FSN . . . . . . . . . . . . . . . . . . . 11 5.3. FEDFS_LOOKUP_FSN . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5.4. FEDFS_SET_NSDB_PARAMS . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5.5. FEDFS_GET_NSDB_PARAMS . . . . . . . . . . . . . . . . . . 16
6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.6. FEDFS_GET_LIMITED_NSDB_PARAMS . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.2. Informational References . . . . . . . . . . . . . . . . . 15 8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 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
skipping to change at page 4, line 36 skipping to change at page 4, 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.
2. Error Definitions 2. Protocol
The RPC protocol used by the administration operations is ONC RPC
[RFC5531]. The data structures used for the parameters and return
values of these procedures are expressed in this document in XDR
[RFC4506].
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:
<CODE BEGINS>
#!/bin/sh
grep '^ *///' | sed 's?^ */// ??' | sed 's?^ *///$??'
<CODE ENDS>
If the above script is stored in a file called "extract.sh", and this
document is in a file called "spec.txt", then the reader can do:
<CODE BEGINS>
sh extract.sh < spec.txt > admin1.xdr
<CODE ENDS>
The effect of the script is to remove leading white space from each
line, plus a sentinel sequence of "///".
The protocol definition in XDR notation is shown below. We begin by
defining basic constants and structures used by the protocol. We
then present the procedures defined by the protocol.
<CODE BEGINS>
/// enum FedFsStatus {
/// 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,
/// FEDFS_ERR_NSDB_ROUTE = 15,
/// FEDFS_ERR_NSDB_DOWN = 16,
/// FEDFS_ERR_NSDB_CONN = 17,
/// FEDFS_ERR_NSDB_AUTH = 18,
/// FEDFS_ERR_NSDB_LDAP = 19,
/// FEDFS_ERR_NSDB_NOFSN = 20,
/// FEDFS_ERR_NSDB_NOFSL = 21,
/// FEDFS_ERR_NSDB_RESPONSE = 22,
/// FEDFS_ERR_NSDB_FAULT = 23,
/// FEDFS_ERR_NSDB_PARAMS = 24
/// };
///
/// typedef opaque FedFsUuid<16>;
///
/// typedef opaque FedFsNsdbName<>;
///
/// typedef opaque FedFsPathComponent<>;
/// typedef FedFsPathComponent FedFsPathName<>;
///
/// typedef opaque FedFsNsdbContainerEntry<>;
///
/// struct FedFsFsn {
/// FedFsUuid fsnUuid;
/// FedFsNsdbName nsdbName;
/// FedFsNsdbContainerEntry nce;
/// };
///
/// struct FedFsCreateJunctionArgs {
/// FedFsPathName path;
/// FedFsFsn fsn;
/// };
///
/// enum FedFsResolveType {
/// FEDFS_RESOLVE_NONE = 0,
/// FEDFS_RESOLVE_CACHE = 1,
/// FEDFS_RESOLVE_NSDB = 2
/// };
///
/// struct FedFsLookupFsnArgs {
/// FedFsPathName path;
/// FedFsResolveType resolve;
/// };
///
/// union FedFsResolveRes switch (FedFsResolveType resolve) {
/// case FEDFS_RESOLVE_NONE:
/// void;
/// default: /* CACHE or NSDB */
/// FedFsUuid fslUuid<>;
/// };
///
/// struct FedFsLookupFsnResOk {
/// FedFsFsn fsn;
/// FedFsResolveRes resolveResult;
/// };
///
/// union FedFsLookupFsnRes switch (FedFsStatus status) {
/// case FEDFS_OK:
/// FedFsLookupFsnResOk resok;
/// case FEDFS_ERR_NSDB_LDAP:
/// unsigned int ldapResultCode<1>;
/// default:
/// void;
/// };
///
/// enum FedFsConnectionSec {
/// FEDFS_SEC_NONE = 0,
/// FEDFS_SEC_TLS = 1 /* StartTLS mechanism; RFC4513, Section 3 */
/// /* other mechanisms TBD */
/// };
///
/// struct FedFsNsdbParams {
/// FedFsConnectionSec secType;
/// /* type specific data follows */
/// opaque secData<>;
/// };
///
/// struct FedFsSetNsdbParamsArgs {
/// FedFsNsdbName nsdbName;
/// FedFsNsdbParams params;
/// };
///
/// union FedFsGetNsdbParamsRes switch (FedFsStatus status) {
/// case FEDFS_OK:
/// FedFsNsdbParams params;
/// default:
/// void;
/// };
///
/// union FedFsGetLimitedNsdbParamsRes switch (FedFsStatus status) {
/// case FEDFS_OK:
/// FedFsConnectionSec secType;
/// default:
/// void;
/// };
///
/// program FEDFS_PROG {
/// version FEDFS_VERSION {
/// void FEDFS_NULL(void) = 0;
/// FedFsStatus FEDFS_CREATE_JUNCTION(
/// FedFsCreateJunctionArgs) = 1;
/// FedFsStatus FEDFS_DELETE_JUNCTION(
/// FedFsPathName) = 2;
/// FedFsLookupFsnRes FEDFS_LOOKUP_FSN(
/// FedFsLookupFsnArgs) = 3;
/// FedFsStatus FEDFS_SET_NSDB_PARAMS(
/// FedFsSetNsdbParamsArgs) = 4;
/// FedFsGetNsdbParamsRes FEDFS_GET_NSDB_PARAMS(
/// FedFsNsdbName) = 5;
/// FedFsGetLimitedNsdbParamsRes FEDFS_GET_LIMITED_NSDB_PARAMS(
/// FedFsNsdbName) = 6;
/// } = 1;
/// } = 100418;
<CODE ENDS>
3. Error Values
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 6, line 5 skipping to change at page 9, line 33
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.
3. Administrator-Initiated Operations FEDFS_ERR_NSDB_ROUTE The fileserver was unable to find a route to
the NSDB.
The RPC protocol used by the administration operations is ONC RPC
[RFC5531]. The data structures used for the parameters and return
values of these procedures are expressed in this document in XDR
[RFC4506].
3.1. Basic Definition
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
rest of this subsection.
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:
<CODE BEGINS>
#!/bin/sh FEDFS_ERR_NSDB_DOWN The fileserver determined that the NSDB was
grep '^ *///' | sed 's?^ */// ??' | sed 's?^ *///$??' down.
<CODE ENDS> FEDFS_ERR_NSDB_CONN The fileserver was unable to establish a
connection with the NSDB.
If the above script is stored in a file called "extract.sh", and this FEDFS_ERR_NSDB_AUTH The fileserver was unable to authenticate and
document is in a file called "spec.txt", then the reader can do: establish a secure connection with the NSDB.
<CODE BEGINS> FEDFS_ERR_NSDB_LDAP An LDAP error occurred on the connection between
the fileserver and NSDB.
sh extract.sh < spec.txt > admin1.xdr FEDFS_ERR_NSDB_NOFSN The fileserver was unable to locate the given
FSN in the appropriate NSDB.
<CODE ENDS> FEDFS_ERR_NSDB_NOFSL The fileserver was unable to locate any FSLs
for the given FSN in the appropriate NSDB.
The effect of the script is to remove leading white space from each FEDFS_ERR_NSDB_NOFSL The fileserver received a malformed response
line, plus a sentinel sequence of "///". from the NSDB.
<CODE BEGINS> FEDFS_ERR_NSDB_FAULT An unanticipated error related to the NSDB
occurred.
/// enum FedFsStatus { FEDFS_ERR_NSDB_PARAMS The fileserver does not have any connection
/// FEDFS_OK = 0, parameters on record for the specified NSDB.
/// 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 FedFsPathComponent<>;
/// typedef FedFsPathComponent FedFsPathName<>;
/// typedef opaque FedFsNsdbContainerEntry<>;
///
/// struct FedFsFsn {
/// FedFsFsnUuid fsnUuid;
/// FedFsNsdbName nsdbName;
/// FedFsNsdbContainerEntry nce;
/// };
///
/// 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 ENDS> 4. Data Types
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 FedFsUuid: 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 DNS name notation.
notation. The format is the same as that specified for an
fs_location4's server array elements in section 11.9 of [NFSv4.1]. The DNS name MUST be represented using a fully qualified domain
name followed by an optional ":port" suffix where "port" is the
UTF-8 string representing the transport port number's decimal
value. A system (i.e. fileserver or administrative host) SHOULD
resolve the fully qualified domain name to a network address using
the system's standard resolution mechanisms.
If the optional port suffix is omitted, the standard LDAP port
number, 389, SHOULD be assumed.
FSNs are immutable and invariant. The attributes of an FSN,
including the fedfsNsdbName, are expected to remain constant.
Therefore, a fedfsNsdbName SHOULD NOT contain a network address,
such as an IPv4 or IPv6 address, as this would indefinitely assign
the network address.
FedFsPathComponent: A case sensitive UTF-8 string containing a
filesystem path component.
FedFsPathName: A variable length array of FedFsPathComponent values FedFsPathName: A variable length array of FedFsPathComponent values
representing a filesystem path. The path's first component is representing a filesystem path. The path's first component is
stored at the first position of the array, the second component is stored at the first position of the array, the second component is
stored at the second position of the array, and so on. Each stored at the second position of the array, and so on.
FedFsPathComponent is a case sensitive UTF-8 string containing a
component of the filesystem path.
FedFsNsdbContainerEntry: A case sensitive UTF-8 string containing FedFsNsdbContainerEntry: A case sensitive UTF-8 string containing
the distinguished name of the NSDB Container Entry (NCE). A the distinguished name of the NSDB Container Entry (NCE). A
string of up to 128 characters MUST be supported. A string string of up to 128 characters MUST be supported. A string
greater than 128 characters MAY be supported. greater than 128 characters MAY be supported.
3.2. Required Procedures FedFsNsdbParams: A set of parameters for connecting to an NSDB.
Conceptually the fileserver contains a data structure that maps an
NSDB name (DNS name and port value) to these LDAP connection
parameters.
The secType field indicates the security mechanism that MUST be
used to protect all connections to the NSDB with the connection
parameters.
A value of FEDFS_SEC_NONE indicates that no security mechanism is
necessary. In this case, the secData array will have 0 (zero)
length.
A value of FEDFS_SEC_TLS indicates that the StartTLS security
mechanism [RFC4513] MUST be used to protect all connections to the
NSDB. In this case, the secData array will contain an X.509v3
certificate in binary DER format [RFC5280]. The certificate
SHOULD be used by the fileserver to authenticate the identity of
the NSDB. In particular, this certificate SHOULD be used to
validate the NSDB's TLS certificate list chain (see 7.4.2 of
[RFC5246]). The certificate could be that of a certificate
authority or a self-signed certificate.
5. 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.
FEDFS_DELETE_JUNCTION Delete an existing junction from some location FEDFS_DELETE_JUNCTION Delete an existing junction from some location
on the server (defined as a pathname). on the server (defined as a pathname).
FEDFS_LOOKUP_FSN Query the server to discover the current value of FEDFS_LOOKUP_FSN Query the server to discover the current value of
the junction (if any) at a given path in the server namespace. the junction (if any) at a given path in the server namespace.
The FEDFS_CREATE_JUNCTION, FEDFS_DELETE_JUNCTION, and FEDFS_SET_NSDB_PARAMS Set the connection parameters for the
FEDFS_LOOKUP_FSN operations are described in more detail in the specified NSDB.
following sections.
FEDFS_GET_NSDB_PARAMS Get the connection parameters for the
specified NSDB.
FEDFS_GET_LIMITED_NSDB_PARAMS Get a limited subset of the connection
parameters for the specified NSDB.
The FEDFS_CREATE_JUNCTION, FEDFS_DELETE_JUNCTION, FEDFS_LOOKUP_FSN,
FEDFS_SET_NSDB_PARAMS, FEDFS_GET_NSDB_PARAMS, and
FEDFS_GET_LIMITED_NSDB_PARAMS procedures are described in more detail
in the following sections.
Fileservers that participate as "leaf" nodes in the namespace (i.e., Fileservers that participate as "leaf" nodes in the namespace (i.e.,
fileservers that host filesets that are the target of junctions, but fileservers that host filesets that are the target of junctions, but
that do not contain any junctions) are not required to implement any that do not contain any junctions) are not required to implement any
of these operations. of these operations.
Note that operations that modify the state of a replicated fileset Note that operations that modify the state of a replicated fileset
MUST result in the update of all of the replicas in a consistent MUST result in the update of all of the replicas in a consistent
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.
3.2.1. FEDFS_CREATE_JUNCTION 5.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 identified by a pathname in The junction directory on the server is identified by a pathname in
the form of an array of one or more UTF-8 path component strings. It the form of an array of one or more UTF-8 path component strings. It
is not required that this path be accessible in any other manner 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 parallel the server namespace, nor is it required global namespace parallel the server namespace, nor is it required
skipping to change at page 10, line 15 skipping to change at page 13, line 30
The last component of the path MUST be an empty directory. If any The last component of the path MUST be an empty directory. If any
component of the path does not exist, or the final component is not a component of the path does not exist, or the final component is not a
directory, then the operation fails with status FEDFS_ERR_INVAL. directory, then the operation fails with status FEDFS_ERR_INVAL.
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 final component is an unexecutable insufficient permissions, or the final component is an unexecutable
or unwritable directory, then the operation MAY fail with status or unwritable directory, then the operation MAY fail with status
FEDFS_ERR_ACCESS. FEDFS_ERR_ACCESS.
The operation SHOULD fail with status FEDFS_ERR_NSDB_PARAMS if the
fileserver does not have any connection parameters on record for the
specified NSDB.
The association between the path and the FSN MUST be durable before The association between the path and the FSN MUST be durable before
the operation may return successfully. If the operation return codes the operation may return successfully. If the operation return codes
indicates success, then the caller may assume that the junction was indicates success, then the caller may assume that the junction was
successfully created and is immediately accessible. successfully created and is immediately accessible.
If successful, subsequent references via NFSv4 [RFC3530] or NFSv4.1 If successful, subsequent references via NFSv4 [RFC3530] or NFSv4.1
[NFSv4.1] clients to the directory that has been replaced by the [NFSv4.1] clients to the directory that has been replaced by the
junction will result in a referral to a current location of the junction will result in a referral to a current location of the
target fileset [FEDFS-NSDB]. target fileset [FEDFS-NSDB].
skipping to change at page 10, line 36 skipping to change at page 14, line 7
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.
3.2.2. FEDFS_DELETE_JUNCTION 5.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 As with FEDFS_CREATE_JUNCTION, the junction on the server is
identified by a pathname in the form of an array of one or more UTF-8 identified by a pathname in the form of an array of one or more UTF-8
path component strings. It is not required that this path be path component strings. 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
skipping to change at page 11, line 43 skipping to change at page 15, line 15
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.
3.2.3. FEDFS_LOOKUP_FSN After removal of the junction, the fileserver MAY check if any of its
existing junctions reference the NSDB specified in the removed
junction's FSN. If the NSDB is not referenced, the fileserver MAY
delete the connection parameters of the unreferenced NSDB.
5.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
and the filerserver's ability to resolve the junction.
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 an As with FEDFS_CREATE_JUNCTION, the pathname must be in the form of an
array of one or more UTF-8 path component strings. It is not array of one or more UTF-8 path component strings. It is not
required that this path be accessible in any other manner (e.g., to a required that this path be accessible in any other manner (e.g., to a
client). This path does not appear in the federated namespace, client). This path does not appear in the federated namespace,
except by coincidence; there is no requirement that the global except by coincidence; there is no requirement that the global
skipping to change at page 12, line 32 skipping to change at page 16, line 11
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 is
unexecutable or unwritable directory, then the operation MAY fail an unexecutable or unwritable directory, then the operation MAY fail
with status FEDFS_ERR_ACCESS. with status FEDFS_ERR_ACCESS.
4. Security Considerations If the junction exists, the resolve parameter allows for testing the
fileserver's ability to resolve the junction. If the junction does
not exist, the fileserver will ignore the resolve parameter.
If the junction exists and the resolve parameter is set to
FEDFS_RESOLVE_NONE, the fileserver MUST NOT attempt to resolve the
FSN. This will allow the administrator to obtain the junction's FSN
even if the resolution would fail.
If the junction exists and the resolve parameter is set to
FEDFS_RESOLVE_CACHE, the fileserver MUST attempt to resolve the FSN
using its FSL cache, if one exists. The fileserver MUST NOT resolve
the FSN by contacting the appropriate NSDB. If the fileserver does
not have a cache or its cache does not have a mapping for the FSN in
question, the result of the operation MUST be FEDFS_OK with the
FedFsResolveRes's resolve value set to FEDFS_RESOLVE_NONE.
If the junction exists and the resolve parameter is set to
FEDFS_RESOLVE_NSDB, the fileserver MUST attempt to resolve the FSN by
contacting the appropriate NSDB. The FSN MUST NOT be resolved using
cached information. The resolution MAY fail with
FEDFS_ERR_NSDB_ROUTE, FEDFS_ERR_NSDB_DOWN, FEDFS_ERR_NSDB_CONN,
FEDFS_ERR_NSDB_AUTH, FEDFS_ERR_NSDB_LDAP, FEDFS_ERR_NSDB_NOFSN,
FEDFS_ERR_NSDB_NOFSL, FEDFS_ERR_NSDB_RESPONSE, or
FEDFS_ERR_NSDB_FAULT depending on the nature of the failure. In the
case of a FEDFS_ERR_NSDB_LDAP failure, the fileserver MAY indicate
the LDAP protocol error value that was encountered in the
FedFsLookupFsnRes's ldapResultCode (see the resultCode values in
Section 4.1.9 of [RFC4511]).
If the fileserver has a cache of FSL records, the process of
resolving an FSN using an NSDB SHOULD result in the cache being
updated. New FSLs for the given FSN SHOULD be added to the cache and
deleted FSLs SHOULD be removed from the cache. This behavior is
desirable because it allows an administrator to proactively request
that the fileserver refresh its FSL cache. For example, the
administrator might like to refresh the fileserver's cache when
changes are made to an FSN's FSLs.
If the junction is resolved, the fileserver will indicate the type of
resolution that was performed using the FedFsResolveRes's resolve
value and include a list of UUIDs for the FSN's FSLs in the
FedFsResolveRes's fslUuid array.
5.4. FEDFS_SET_NSDB_PARAMS
This operations allows the administrator to set the connection
parameters for a given NSDB.
If a record for the given NSDB does not exist, a new record is
created with the specified connection parameters.
If a record for the given NSDB does exist, the existing connection
parameters are replaced with the specified connection parameters.
An NSDB is specified using a FedFsNsdbName. Two FedFsNsdbNames are
considered equal if both their DNS name and port values are the same.
As described above, the standard LDAP port number, 389, SHOULD be
assumed if no port number is explicitly specified. Therefore, the
FedFsNsdbName "nsdb.example.com" is considered equal to
"nsdb.example.com:389" but not equal to "nsdb.example.com:1066" or
"nsdb.foo.example.com:389.
The given NSDB need not be referenced by any junctions on the
fileserver. This situation will occur when connection parameters for
a new NSDB are installed.
The format of the connection parameters is described above.
On success, this operation returns FEDFS_OK. When the operation
returns, the new connection parameters SHOULD be used for all
subsequent LDAP connections to the given NSDB. Existing connections
MAY be terminated and re-established using the new connection
parameters. The connection parameters SHOULD be durable across
fileserver reboots.
On failure, an error value indicating the type of error is returned.
The operation MAY return FEDFS_ERR_ACCESS if the operation's
associated user does not have sufficient permissions to create/modify
NSDB connection parameters.
5.5. FEDFS_GET_NSDB_PARAMS
This operations allows the administrator to retrieve connection
parameters, if they exist, for the given NSDB.
An NSDB is specified using a FedFsNsdbName. Two FedFsNsdbNames are
considered equal if both their DNS name and port values are the same.
As described above, the standard LDAP port number, 389, SHOULD be
assumed if no port number is explicitly specified. Therefore, the
FedFsNsdbName "nsdb.example.com" is considered equal to
"nsdb.example.com:389" but not equal to "nsdb.example.com:1066" or
"nsdb.foo.example.com:389.
A set of connection parameters is considered a match if their
associated NSDB is equal (as defined above) to the operation's NSDB
argument. Therefore, there is at most one set of connection
parameters that can match the query described by this operation.
The format of the connection parameters is described above.
On success, this operation returns FEDFS_OK and the connection
parameters on record for the given NSDB.
On failure, an error value indicating the type of error is returned.
This operation MAY return FEDFS_ERR_NSDB_PARAMS to indicate that
there are no connection parameters on record for the given NSDB. The
operation MAY return FEDFS_ERR_ACCESS if the operation's associated
user does not have sufficient permissions to view NSDB connection
parameters.
5.6. FEDFS_GET_LIMITED_NSDB_PARAMS
This operations allows the administrator to retrieve a limited subset
of information on the connection parameters, if they exist, for the
given NSDB.
An NSDB is specified using a FedFsNsdbName. Two FedFsNsdbNames are
considered equal if both their DNS name and port values are the same.
As described above, the standard LDAP port number, 389, SHOULD be
assumed if no port number is explicitly specified. Therefore, the
FedFsNsdbName "nsdb.example.com" is considered equal to
"nsdb.example.com:389" but not equal to "nsdb.example.com:1066" or
"nsdb.foo.example.com:389.
A set of connection parameters is considered a match if their
associated NSDB is equal (as defined above) to the operation's NSDB
argument. Therefore, there is at most one set of connection
parameters that can match the query described by this operation.
This operation returns a limited subset of the connection parameters.
Only the FedFsConnectionSec mechanism that is used to protect
communication between the fileserver and NSDB is returned.
Viewing the limited subset of NSDB connection parameters returned by
FEDFS_GET_LIMITED_NSDB_PARAMS MAY be a less privileged operation than
viewing the entire set of NSDB connection parameters returned by
FEDFS_GET_NSDB_PARAMS. For example, the full contents of an NSDB's
connection parameters could contain sensitive information for some
security mechanisms. FEDFS_GET_LIMITED_NSDB_PARAMS allows the
fileserver to communicate a subset of the connection parameters (the
security mechanism) to users with sufficient permissions without
revealing more sensitive information.
On success, this operation returns FEDFS_OK and the
FedFsConnectionSec value on record for the given NSDB.
On failure, an error value indicating the type of error is returned.
This operation MAY return FEDFS_ERR_NSDB_PARAMS to indicate that
there are no connection parameters on record for the given NSDB. The
operation MAY return FEDFS_ERR_ACCESS if the operation's associated
user does not have sufficient permissions to view the subset of NSDB
connection parameters returned by this procedure.
6. 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.
5. IANA Considerations 7. IANA Considerations
A range of ONC RPC program numbers were assigned for use by FedFS A range of ONC RPC program numbers were assigned for use by FedFS
using the procedure described in Section 7.3 "Program Number using the procedure described in Section 7.3 "Program Number
Assignment" of [RFC5531]. The FedFS range is: Assignment" of [RFC5531]. The FedFS range is:
IETF NFSv4 Working Group - FedFS 100418 - 100421 IETF NFSv4 Working Group - FedFS 100418 - 100421
This document describes version 1 of the ONC RPC program 100418. This document describes version 1 of the ONC RPC program 100418.
6. Glossary 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.
Federation: A set of server collections and singleton servers that Federation: A set of server collections and singleton servers that
use a common set of interfaces and protocols in order to provide use a common set of interfaces and protocols in order to provide
to their clients a federated namespace accessible through a to their clients a federated namespace accessible through a
filesystem access protocol. filesystem access protocol.
Fileserver: A server exporting a filesystem via a network filesystem Fileserver: A server exporting a filesystem via a network filesystem
access protocol. access protocol.
Fileset: The abstraction of a set of files and their containing Fileset: The abstraction of a set of files and the directory tree
directory tree. A fileset is the fundamental unit of data that contains them. A fileset is the fundamental unit of data
management in the federation. management in the federation.
Note that all files within a fileset are descendants of one Note that all files within a fileset are descendants of one
directory, and that filesets do not span filesystems. directory, and that filesets do not span filesystems.
Filesystem: A self-contained unit of export for a fileserver, and Filesystem: A self-contained unit of export for a fileserver, and
the mechanism used to implement filesets. The fileset does not the mechanism used to implement filesets. The fileset does not
need to be rooted at the root of the filesystem, nor at the export need to be rooted at the root of the filesystem, nor at the export
point for the filesystem. point for the filesystem.
A single filesystem MAY implement more than one fileset, if the A single filesystem MAY implement more than one fileset, if the
client protocol and the fileserver permit this. client protocol and the fileserver permit this.
Filesystem access protocol: A network filesystem access protocol Filesystem Access Protocol: A network filesystem access protocol
such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or CIFS
CIFS. (Common Internet File System) [MS-SMB] [MS-SMB2] [MS-CIFS].
FSL (Fileset location): The location of the implementation of a FSL (Fileset Location): The location of the implementation of a
fileset at a particular moment in time. A FSL MUST be something fileset at a particular moment in time. An FSL MUST be something
that can be translated into a protocol-specific description of a that can be translated into a protocol-specific description of a
resource that a client can access directly, such as a fs_location resource that a client can access directly, such as an fs_location
(for NFSv4), or share name (for CIFS). Note that not all FSLs (for NFSv4), or share name (for CIFS). Note that not all FSLs
need to be explicitly exported as long as they are contained need to be explicitly exported as long as they are contained
within an exported path on the fileserver. within an exported path on the fileserver.
FSN (Fileset name): A platform-independent and globally unique name FSN (Fileset Name): A platform-independent and globally unique name
for a fileset. Two FSLs that implement replicas of the same for a fileset. Two FSLs that implement replicas of the same
fileset MUST have the same FSN, and if a fileset is migrated from fileset MUST have the same FSN, and if a fileset is migrated from
one location to another, the FSN of that fileset MUST remain the one location to another, the FSN of that fileset MUST remain the
same. same.
Junction: A filesystem object used to link a directory name in the Junction: A filesystem object used to link a directory name in the
current fileset with an object within another fileset. The current fileset with an object within another fileset. The
server-side "link" from a leaf node in one fileset to the root of server-side "link" from a leaf node in one fileset to the root of
another fileset. another fileset.
Namespace: A filename/directory tree that a sufficiently-authorized Namespace: A filename/directory tree that a sufficiently authorized
client can observe. client can observe.
NSDB (Namespace Database) Service: A service that maps FSNs to FSLs. NSDB (Namespace Database) Service: A service that maps FSNs to FSLs.
The NSDB may also be used to store other information, such as The NSDB may also be used to store other information, such as
annotations for these mappings and their components. annotations for these mappings and their components.
NSDB Node: The name or location of a server that implements part of NSDB Node: The name or location of a server that implements part of
the NSDB service and is responsible for keeping track of the FSLs the NSDB service and is responsible for keeping track of the FSLs
(and related info) that implement a given partition of the FSNs. (and related info) that implement a given partition of the FSNs.
skipping to change at page 15, line 9 skipping to change at page 21, line 49
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. References 9. 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.
[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.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006.
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, May 2009. Specification Version 2", RFC 5531, May 2009.
7.2. Informational References 9.2. Informative References
[FEDFS-NSDB] [FEDFS-NSDB]
Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "NSDB Protocol for Federated Filesystems", Naik, "NSDB Protocol for Federated Filesystems",
draft-ietf-nfsv4-federated-fs-protocol (Work In Progress), draft-ietf-nfsv4-federated-fs-protocol (Work In Progress),
2009. 2009.
[FEDFS-REQTS] [FEDFS-REQTS]
Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Requirements for Federated File Systems", Naik, "Requirements for Federated File Systems", RFC 5716,
draft-ietf-nfsv4-federated-fs-reqts (Work In Progress), January 2010.
2009.
[NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 [MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS)
Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work Protocol Specification", MS-CIFS 2.0, November 2009.
in progress), December 2008.
[MS-SMB] Microsoft Corporation, "Server Message Block (SMB)
Protocol Specification", MS-SMB 17.0, November 2009.
[MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version
2 Protocol Specification", MS-SMB2 19.0, November 2009.
[NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010.
[NFSv4.1-XDR] [NFSv4.1-XDR]
Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 Shepler, S., Eisler, M., and D. Noveck, "Network File
Minor Version 1 XDR Description", System (NFS) Version 4 Minor Version 1 External Data
draft-ietf-nfsv4-minorversion1-dot-x-12 (work in Representation Standard (XDR) Description", RFC 5662,
progress), December 2008. January 2010.
[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.
We would also like to thank Trond Myklebust for suggesting We would also like to thank Trond Myklebust for suggesting
improvements to the FSL pathname format. improvements to the FSL pathname format and Nicolas Williams for his
suggestions.
The extract.sh shell script and formatting conventions were first The extract.sh shell script and formatting conventions were first
described by the authors of the NFSv4.1 XDR specification described by the authors of the NFSv4.1 XDR specification
[NFSv4.1-XDR]. [NFSv4.1-XDR].
Authors' Addresses Authors' Addresses
James Lentini James Lentini
NetApp NetApp
1601 Trapelo Rd, Suite 16 1601 Trapelo Rd, Suite 16
 End of changes. 49 change blocks. 
181 lines changed or deleted 531 lines changed or added

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