draft-ietf-nfsv4-federated-fs-protocol-14.txt   draft-ietf-nfsv4-federated-fs-protocol-15.txt 
NFSv4 Working Group J. Lentini NFSv4 Working Group J. Lentini
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track D. Ellard Intended status: Standards Track D. Ellard
Expires: May 14, 2013 Raytheon BBN Technologies Expires: June 15, 2013 Raytheon BBN Technologies
R. Tewari R. Tewari
IBM Almaden IBM Almaden
C. Lever, Ed. C. Lever, Ed.
Oracle Corporation Oracle Corporation
November 10, 2012 December 12, 2012
NSDB Protocol for Federated Filesystems NSDB Protocol for Federated Filesystems
draft-ietf-nfsv4-federated-fs-protocol-14 draft-ietf-nfsv4-federated-fs-protocol-15
Abstract Abstract
This document describes a filesystem federation protocol that enables This document describes a filesystem federation protocol that enables
file access and namespace traversal across collections of file access and namespace traversal across collections of
independently administered fileservers. The protocol specifies a set independently administered fileservers. The protocol specifies a set
of interfaces by which fileservers with different administrators can of interfaces by which fileservers with different administrators can
form a fileserver federation that provides a namespace composed of form a fileserver federation that provides a namespace composed of
the filesystems physically hosted on and exported by the constituent the filesystems physically hosted on and exported by the constituent
fileservers. fileservers.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 14, 2013. This Internet-Draft will expire on June 15, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 22 skipping to change at page 3, line 22
2.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Fileset . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.6. Fileset . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7. Fileset Name (FSN) . . . . . . . . . . . . . . . . . . . . 7 2.7. Fileset Name (FSN) . . . . . . . . . . . . . . . . . . . . 7
2.8. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 8 2.8. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 8
2.8.1. The NFS URI scheme . . . . . . . . . . . . . . . . . . 9 2.8.1. The NFS URI scheme . . . . . . . . . . . . . . . . . . 9
2.8.2. Mutual Consistency across Fileset Locations . . . . . 10 2.8.2. Mutual Consistency across Fileset Locations . . . . . 10
2.8.3. Caching of Fileset Locations . . . . . . . . . . . . . 11 2.8.3. Caching of Fileset Locations . . . . . . . . . . . . . 11
2.8.4. Generating A Referral from Fileset Locations . . . . . 12 2.8.4. Generating A Referral from Fileset Locations . . . . . 12
2.9. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 13 2.9. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 13
2.9.1. NSDB Client . . . . . . . . . . . . . . . . . . . . . 14
2.10. Junctions and Referrals . . . . . . . . . . . . . . . . . 14 2.10. Junctions and Referrals . . . . . . . . . . . . . . . . . 14
2.11. Unified Namespace and the Root Fileset . . . . . . . . . . 14 2.11. Unified Namespace and the Root Fileset . . . . . . . . . . 15
2.12. UUID Considerations . . . . . . . . . . . . . . . . . . . 15 2.12. UUID Considerations . . . . . . . . . . . . . . . . . . . 15
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Creating a Fileset and its FSL(s) . . . . . . . . . . . . 16 3.1. Creating a Fileset and its FSL(s) . . . . . . . . . . . . 16
3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 16 3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 17
3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 17 3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 17
3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 17 3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 17
3.3. Example Use Cases for Fileset Annotations . . . . . . . . 18 3.3. Example Use Cases for Fileset Annotations . . . . . . . . 18
4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 18 4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 19
4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 19 4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 19
4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 20 4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 23 4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 23
4.2.2. LDAP Object Classes . . . . . . . . . . . . . . . . . 37 4.2.2. LDAP Object Classes . . . . . . . . . . . . . . . . . 37
5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 40 5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 40
5.1. NSDB Operations for Administrators . . . . . . . . . . . . 41 5.1. NSDB Operations for Administrators . . . . . . . . . . . . 41
5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 41 5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 41
5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 42 5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 42
5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 43 5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 43
5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 46 5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 46
5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 47 5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 47
5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 48 5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 48
skipping to change at page 7, line 41 skipping to change at page 7, line 41
FsnUuid: a UUID (universally unique identifier), conforming to FsnUuid: a UUID (universally unique identifier), conforming to
[RFC4122], that is used to uniquely identify an FSN. [RFC4122], that is used to uniquely identify an FSN.
FsnTTL: the time-to-live of the FSN's FSL information, in FsnTTL: the time-to-live of the FSN's FSL information, in
seconds. Fileservers MUST NOT use cached FSL records after the seconds. Fileservers MUST NOT use cached FSL records after the
parent FSN's FsnTTL has expired. An FsnTTL value of zero parent FSN's FsnTTL has expired. An FsnTTL value of zero
indicates that fileservers MUST NOT cache the results of indicates that fileservers MUST NOT cache the results of
resolving this FSN. resolving this FSN.
The FsnUuid is a required attribute of an FSN record, but the The NsdbName is not physically stored as an attribute of the record.
NsdbName is not stored as an attribute of the record. The NsdbName The NsdbName is obvious to any client that accesses an NSDB, and is
is obvious to NSDB clients, and is indeed authenticated in cases indeed authenticated in cases where TLS security is in effect.
where TLS security is in effect.
The FsnUuid and NsdbName values never change during an FSN's The FsnUuid and NsdbName values never change during an FSN's
lifetime. However, an FSN's FSL information can change over time, lifetime. However, an FSN's FSL information can change over time,
and is typically cached on fileservers for performance. More detail and is typically cached on fileservers for performance. More detail
on FSL caching is provided in Section 2.8.3. on FSL caching is provided in Section 2.8.3.
An FSN record may also contain: An FSN record may also contain:
Annotations: optional name/value pairs that can be interpreted by Annotations: name/value pairs that can be interpreted by a
a fileserver. The semantics of this field are not defined by fileserver. The semantics of this field are not defined by
this document. These tuples are intended to be used by higher- this document. These tuples are intended to be used by higher-
level protocols. level protocols.
Descriptions: optional text descriptions. The semantics of this Descriptions: text descriptions. The semantics of this field are
field are not defined by this document. not defined by this document.
2.8. Fileset Location (FSL) 2.8. Fileset Location (FSL)
An FSL describes one physical location where a complete copy of the An FSL describes one physical location where a complete copy of the
fileset's data resides. An FSL contains generic and type specific fileset's data resides. An FSL contains generic and type specific
information which together describe how to access the fileset data at information which together describe how to access the fileset data at
this location. An FSL's attributes can be used by a fileserver to this location. An FSL's attributes can be used by a fileserver to
decide which locations it will return to a file-access client. decide which locations it will return to a file-access client.
An FSL consists of: An FSL consists of:
skipping to change at page 8, line 36 skipping to change at page 8, line 36
FsnUuid: the UUID of the FSL's FSN. FsnUuid: the UUID of the FSL's FSN.
NsdbName: the network location of the NSDB node that contains NsdbName: the network location of the NSDB node that contains
authoritative information for this FSL. authoritative information for this FSL.
The NsdbName is not stored as an attribute of an FSL record for the The NsdbName is not stored as an attribute of an FSL record for the
same reason it is not stored in FSN records. same reason it is not stored in FSN records.
An FSL record may also contain: An FSL record may also contain:
Annotations: optional name/value pairs that can be interpreted by Annotations: name/value pairs that can be interpreted by a
a fileserver. The semantics of this field are not defined by fileserver. The semantics of this field are not defined by
this document. These tuples are intended to be used by higher- this document. These tuples are intended to be used by higher-
level protocols. level protocols.
Descriptions: optional text descriptions. The semantics of this Descriptions: text descriptions. The semantics of this field are
field are not defined by this document. not defined by this document.
In addition to the attributes defined above, an FSL record contains
attributes that allow a fileserver to construct referrals. For each
file-access protocol, a corresponding FSL record subtype is defined.
This document defines an FSL subtype for NFS. An NFS FSL contains This document defines an FSL subtype for NFS. An NFS FSL contains
information suitable for use in one of the NFSv4 referral attributes information suitable for use in one of the NFSv4 referral attributes
(e.g., fs_locations or fs_locations_info). (e.g., fs_locations or fs_locations_info, described in [RFC5661]).
Section 4.2.2.4 describes the contents of an NFS FSL record.
A fileset MAY be accessible by protocols other than NFS. For each A fileset also may be accessible by file-access protocols other than
such protocol, a corresponding FSL subtype SHOULD be defined. The NFS. The contents and format of such FSL subtypes are not defined in
contents and format of such FSL subtypes are not defined in this this document.
document.
2.8.1. The NFS URI scheme 2.8.1. The NFS URI scheme
To capture the location of an NFSv4 fileset, we extend the NFS URL To capture the location of an NFSv4 fileset, we extend the NFS URL
scheme specified in [RFC2224]. This extension follows rules for scheme specified in [RFC2224]. This extension follows rules for
defining Uniform Resource Identifier schemes (see [RFC3986]). In the defining Uniform Resource Identifier schemes (see [RFC3986]). In the
following text, we refer to this extended NFS URL scheme as an NFS following text, we refer to this extended NFS URL scheme as an NFS
URI. URI.
An NFS URI MUST contain both an authority and a path component. It An NFS URI MUST contain both an authority and a path component. It
skipping to change at page 9, line 42 skipping to change at page 9, line 46
The rules for encoding the path component of a generic URI are The rules for encoding the path component of a generic URI are
specified in section 3.3 of [RFC3986]. specified in section 3.3 of [RFC3986].
According to sections 5 and 6 of [RFC2224], NFS URLs specify a According to sections 5 and 6 of [RFC2224], NFS URLs specify a
pathname relative to an NFS fileserver's "public filehandle." pathname relative to an NFS fileserver's "public filehandle."
However, NFSv4 fileservers do not expose a "public filehandle." However, NFSv4 fileservers do not expose a "public filehandle."
Instead, NFSv4 pathnames contained in an NFS URI are evaluated Instead, NFSv4 pathnames contained in an NFS URI are evaluated
relative to the pseudoroot of the fileserver identified in the URI's relative to the pseudoroot of the fileserver identified in the URI's
authority component. authority component.
The component4 elements of an NFSv4 pathname are encoded as path Each component of an NFSv4 pathname is represented as a component4
segments in an NFS URI. NFSv4 pathnames MUST be expressed in an NFS string (see Section 3.2, "Basic Data Types" of [RFC5661]). The
URI as an absolute path. An NFS URI path component MUST NOT be component4 elements of an NFSv4 pathname are encoded as path segments
empty. The NFS URI path component starts with a slash ("/") in an NFS URI. NFSv4 pathnames MUST be expressed in an NFS URI as an
character, followed by one or more path segments which each start absolute path. An NFS URI path component MUST NOT be empty. The NFS
with a slash ("/") character [RFC3986]. URI path component starts with a slash ("/") character, followed by
one or more path segments which each start with a slash ("/")
character [RFC3986].
Therefore, a double slash always follows the authority component of Therefore, a double slash always follows the authority component of
an NFS URI. For example, the NFSv4 pathname "/" is represented by an NFS URI. For example, the NFSv4 pathname "/" is represented by
two slash ("/") characters following an NFS URI's authority two slash ("/") characters following an NFS URI's authority
component. component.
The component4 elements of an NFSv4 pathname SHOULD be prepared using The component4 elements of an NFSv4 pathname MUST be prepared using
the component4 rules defined in Chapter 12 "Internationalization" of the component4 rules defined in Chapter 12 "Internationalization" of
[3530bis] prior to encoding the path component of an NFS URI. As [3530bis] prior to encoding the path component of an NFS URI. As
specified in [RFC3986], any non-ASCII UTF-8 code points and any URI- specified in [RFC3986], any non-ASCII characters and any URI-reserved
reserved characters, such as the slash ("/") character, contained in characters, such as the slash ("/") character, contained in a
a component4 element MUST be represented by URI percent encoding. component4 element MUST be represented by URI percent encoding.
2.8.1.3. Encoding an NFS location in an FSL 2.8.1.3. Encoding an NFS location in an FSL
The path component of an NFS URI encodes the "rootpath" field of the The path component of an NFS URI encodes the "rootpath" field of the
NFSv4 fs_location4 data type or the "fli_rootpath" of the NFSv4 NFSv4 fs_location4 data type or the "fli_rootpath" of the NFSv4
fs_locations_item4 data type (see [RFC5661]). fs_locations_item4 data type (see [RFC5661]).
In its "server" field, the NFSv4 fs_location4 data type contains a In its "server" field, the NFSv4 fs_location4 data type contains a
list of universal addresses or UTF-8 hostnames. Each may optionally list of universal addresses and DNS labels. Each may optionally
include a port number. The NFSv4 fs_locations_item4 data type include a port number. The exact encoding requirements for this
contains this data in its "fli_entries" field (see [RFC5661]). This information is found in Section 12.6 of [3530bis]. The NFSv4
information is encoded in the authority component of an NFS URI. fs_locations_item4 data type encodes the same data in its
"fli_entries" field (see [RFC5661]). This information is encoded in
the authority component of an NFS URI.
The "server" and "fli_entries" fields can encode multiple server The "server" and "fli_entries" fields can encode multiple server
hostnames that share the same pathname. An NFS URI, and hence an FSL hostnames that share the same pathname. An NFS URI, and hence an FSL
record, represents only a single hostname and pathname pair. An NFS record, represents only a single hostname and pathname pair. An NFS
fileserver MUST NOT combine a set of FSL records into a single fileserver MUST NOT combine a set of FSL records into a single
fs_location4 or fs_locations_item4 unless each FSL record in the set fs_location4 or fs_locations_item4 unless each FSL record in the set
contains the same rootpath value and extended filesystem information. contains the same rootpath value and extended filesystem information.
2.8.2. Mutual Consistency across Fileset Locations 2.8.2. Mutual Consistency across Fileset Locations
skipping to change at page 14, line 6 skipping to change at page 14, line 15
server. server.
Each NSDB node is managed by a single administrative entity. A Each NSDB node is managed by a single administrative entity. A
single administrative entity can manage multiple NSDB nodes. single administrative entity can manage multiple NSDB nodes.
Each NSDB node stores the definition of the FSNs for which it is Each NSDB node stores the definition of the FSNs for which it is
authoritative. It also stores the definitions of the FSLs associated authoritative. It also stores the definitions of the FSLs associated
with those FSNs. An NSDB node is authoritative for the filesets that with those FSNs. An NSDB node is authoritative for the filesets that
it defines. it defines.
Each NSDB node supports an LDAP [RFC4510] interface. The information
stored on an NSDB node is accessed and updated by LDAP clients.
An NSDB MAY be replicated throughout the federation. If an NSDB is An NSDB MAY be replicated throughout the federation. If an NSDB is
replicated, the NSDB MUST exhibit loose, converging consistency as replicated, the NSDB MUST exhibit loose, converging consistency as
defined in [RFC3254]. The mechanism by which this is achieved is defined in [RFC3254]. The mechanism by which this is achieved is
outside the scope of this document. Many LDAP implementations outside the scope of this document. Many LDAP implementations
support replication. These features MAY be used to replicate the support replication. These features MAY be used to replicate the
NSDB. NSDB.
2.9.1. NSDB Client
Each NSDB node supports an LDAP [RFC4510] interface. An NSDB client
is software that uses the LDAP protocol to access or update namespace
information stored on an NSDB node. Details of these transactions
are discussed in Section 4.
A domain's administrative entity uses NSDB client software to manage
information stored on NSDB nodes.
Fileservers act as an NSDB client when contacting a particular NSDB
node to resolve an FSN to a set of FSL records. The resulting
location information is then transferred to file-access clients via
referrals. Therefore file-access clients never have need to access
NSDBs directly.
2.10. Junctions and Referrals 2.10. Junctions and Referrals
A junction is a point in a particular fileset namespace where a A junction is a point in a particular fileset namespace where a
specific target fileset may be attached. If a file-access client specific target fileset may be attached. If a file-access client
traverses the path leading from the root of a federated namespace to traverses the path leading from the root of a federated namespace to
the junction referring to a target fileset, it should be able to the junction referring to a target fileset, it should be able to
mount and access the data in that target fileset (assuming mount and access the data in that target fileset (assuming
appropriate permissions). In other words, a junction can be viewed appropriate permissions). In other words, a junction can be viewed
as a reference from a directory in one fileset to the root of the as a reference from a directory in one fileset to the root of the
target fileset. target fileset.
skipping to change at page 20, line 6 skipping to change at page 20, line 27
+---- [o=fedfs] +---- [o=fedfs]
| fedfsNceDN: o=fedfs | fedfsNceDN: o=fedfs
| |
| |
+---- [dc=example,dc=com] +---- [dc=example,dc=com]
| fedfsNceDN: ou=fedfs,ou=corp-it,dc=example,dc=com | fedfsNceDN: ou=fedfs,ou=corp-it,dc=example,dc=com
| |
| |
+---- [ou=system] +---- [ou=system]
In this case, the o=fedfs namingContext has an NSBD Container Entry In this case, the o=fedfs namingContext has an NSDB Container Entry
at o=fedfs, the dc=example,dc=com namingContext has an NSDB Container at o=fedfs, the dc=example,dc=com namingContext has an NSDB Container
Entry at ou=fedfs,ou=corp-it,dc=example,dc=com, and the ou=system Entry at ou=fedfs,ou=corp-it,dc=example,dc=com, and the ou=system
namingContext has no NSDB Container Entry. namingContext has no NSDB Container Entry.
The NSDB SHOULD be configured with one or more privileged LDAP users. The NSDB SHOULD be configured with one or more privileged LDAP users.
These users are able to modify the contents of the LDAP database. An These users are able to modify the contents of the LDAP database. An
administrator that performs the operations described in Section 5.1 administrator that performs the operations described in Section 5.1
SHOULD authenticate using the DN of a privileged LDAP user. SHOULD authenticate using the DN of a privileged LDAP user.
It MUST be possible for an unprivileged (unauthenticated) user to It MUST be possible for an unprivileged (unauthenticated) user to
skipping to change at page 23, line 7 skipping to change at page 23, line 7
/// # LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, /// # LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
/// # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING /// # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
/// # IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF /// # IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
/// # ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. /// # ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
/// # /// #
<CODE ENDS> <CODE ENDS>
4.2.1. LDAP Attributes 4.2.1. LDAP Attributes
This section describes the required attributes of the NSDB LDAP The following definitions are used below:
schema. The following definitions are used below:
o The "name" attribute described in [RFC4519]. o The "name" attribute described in [RFC4519].
o The Integer syntax (1.3.6.1.4.1.1466.115.121.1.27) described in o The Integer syntax (1.3.6.1.4.1.1466.115.121.1.27) described in
[RFC4517]. [RFC4517].
o The "integerMatch" rule described in [RFC4517]. o The "integerMatch" rule described in [RFC4517].
o The Octet String syntax (1.3.6.1.4.1.1466.115.121.1.40) described o The Octet String syntax (1.3.6.1.4.1.1466.115.121.1.40) described
in [RFC4517]. in [RFC4517].
skipping to change at page 24, line 43 skipping to change at page 24, line 43
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.3. fedfsFsnTTL 4.2.1.3. fedfsFsnTTL
A fedfsFsnTTL is the time-to-live in seconds of a cached FSN and its A fedfsFsnTTL is the time-to-live in seconds of a cached FSN and its
child FSL records. It corresponds to the FsnTTL as defined in child FSL records. It corresponds to the FsnTTL as defined in
Section 2.7. See also Section Section 2.8.3 for information about Section 2.7. See also Section Section 2.8.3 for information about
caching FSLs. A fedfsFsnTTL MUST be encoded as an Integer syntax caching FSLs. A fedfsFsnTTL MUST be encoded as an Integer syntax
value [RFC4517]. value [RFC4517] in the range [0, 4294967295].
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.11 NAME 'fedfsFsnTTL' /// 1.3.6.1.4.1.31103.1.11 NAME 'fedfsFsnTTL'
/// DESC 'Time to live of an FSN tree' /// DESC 'Time to live of an FSN tree'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
skipping to change at page 26, line 27 skipping to change at page 26, line 27
A fedfsAnnotation contains an object annotation formatted as a key/ A fedfsAnnotation contains an object annotation formatted as a key/
value pair. value pair.
This attribute is multi-valued; an object type that permits This attribute is multi-valued; an object type that permits
annotations may have any number of annotations per instance. annotations may have any number of annotations per instance.
A fedfsAnnotation attribute is a human-readable sequence of UTF-8 A fedfsAnnotation attribute is a human-readable sequence of UTF-8
characters with no non-terminal NUL characters. The value MUST be characters with no non-terminal NUL characters. The value MUST be
formatted according to the following ABNF [RFC5234] rules: formatted according to the following ABNF [RFC5234] rules:
ANNOTATION = KEY EQUALS VALUE ANNOTATION = KEY "=" VALUE
KEY = ITEM KEY = ITEM
VALUE = ITEM VALUE = ITEM
ITEM = BLANK DQUOTE STR DQUOTE BLANK ITEM = *WSP DQUOTE UTF8-octets DQUOTE *WSP
BLANK = 0*EMPTY
EMPTY = SPACE / HTAB
HTAB = %x09 ; horizontal tab
STR = 0*UTF8
The DQUOTE, EQUALS, UTF8, and SPACE rules are defined in [RFC4512]. DQUOTE and WSP are defined in [RFC5234], and UTF8-octets is defined
in [RFC3629].
The following escape sequences are allowed: The following escape sequences are allowed:
+-----------------+-------------+ +-----------------+-------------+
| escape sequence | replacement | | escape sequence | replacement |
+-----------------+-------------+ +-----------------+-------------+
| \\ | \ | | \\ | \ |
| \" | " | | \" | " |
+-----------------+-------------+ +-----------------+-------------+
skipping to change at page 28, line 17 skipping to change at page 28, line 17
/// DESC 'Description of an object' /// DESC 'Description of an object'
/// SUP name /// SUP name
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.8. fedfsNfsURI 4.2.1.8. fedfsNfsURI
A fedfsNfsURI stores the host and pathname components of an FSL. A A fedfsNfsURI stores the host and pathname components of an FSL. A
fedfsNfsURI MUST be encoded as an NFS URI Section 2.8.1. fedfsNfsURI MUST be encoded as an NFS URI (see Section 2.8.1).
The fedfsNfsURI is a subtype of the labeledURI type [RFC2079], with The fedfsNfsURI is a subtype of the labeledURI type [RFC2079], with
the same encoding rules. the same encoding rules.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
skipping to change at page 41, line 14 skipping to change at page 41, line 14
The first and second sub-protocols are defined as LDAP operations, The first and second sub-protocols are defined as LDAP operations,
using the schema defined in the previous section. If each NSDB node using the schema defined in the previous section. If each NSDB node
is a standard LDAP server, then, in theory, it is unnecessary to is a standard LDAP server, then, in theory, it is unnecessary to
describe the LDAP operations in detail, because the operations are describe the LDAP operations in detail, because the operations are
ordinary LDAP operations to query and update records. However, we do ordinary LDAP operations to query and update records. However, we do
not require that an NSDB node implement a complete LDAP service, and not require that an NSDB node implement a complete LDAP service, and
therefore we define in these sections the minimum level of LDAP therefore we define in these sections the minimum level of LDAP
functionality required to implement an NSDB node. functionality required to implement an NSDB node.
The NSDB sub-protocols are defined in the next two sub-sections. The The NSDB sub-protocols are defined in Section 5.1 and Section 5.2.
descriptions of LDAP messages in these sections use the LDAP Data The descriptions of LDAP messages in these sections use the LDAP Data
Interchange Format (LDIF) [RFC2849]. In order to differentiate Interchange Format (LDIF) [RFC2849]. In order to differentiate
constant and variable strings in the LDIF specifications, variables constant and variable strings in the LDIF specifications, variables
are prefixed by a $ character and use all upper case characters. For are prefixed by a $ character and use all upper case characters. For
example, a variable named FOO would be specified as $FOO. example, a variable named FOO would be specified as $FOO.
This document uses the term NSDB client to refer to an LDAP client This document uses the term NSDB client to refer to an LDAP client
that uses either of the NSDB sub-protocols. that uses either of the NSDB sub-protocols.
The third sub-protocol defines the queries and other requests that The third sub-protocol defines the queries and other requests that
are sent to a fileserver in order to get information from it or to are sent to a fileserver in order to get information from it or to
skipping to change at page 42, line 8 skipping to change at page 42, line 8
5.1.1. Create an FSN 5.1.1. Create an FSN
This operation creates a new FSN in the NSDB by adding a new fedfsFsn This operation creates a new FSN in the NSDB by adding a new fedfsFsn
entry in the NSDB's LDAP directory. entry in the NSDB's LDAP directory.
A fedfsFsn entry contains a fedfsFsnUuid. The administrator chooses A fedfsFsn entry contains a fedfsFsnUuid. The administrator chooses
the fedfsFsnUuid by a process described in Section 2.12). A fedfsFsn the fedfsFsnUuid by a process described in Section 2.12). A fedfsFsn
entry also contains a fedfsFsnTTL. The fedfsFsnTTL is chosen by the entry also contains a fedfsFsnTTL. The fedfsFsnTTL is chosen by the
administrator as described in Section 2.8.3. administrator as described in Section 2.8.3.
The NSDB node that receives the request SHOULD check all of the
attributes for validity and consistency, but this is not generally
possible for LDAP servers because the consistency requirements cannot
be expressed in the LDAP schema (although many LDAP servers can be
extended, via plug-ins or other mechanisms, to add functionality
beyond the strict definition of LDAP).
5.1.1.1. LDAP Request 5.1.1.1. LDAP Request
This operation is implemented using the LDAP ADD request described by This operation is implemented using the LDAP ADD request described by
the LDIF below. the LDIF below.
dn: fedfsFsnUuid=$FSNUUID,$NCE dn: fedfsFsnUuid=$FSNUUID,$NCE
changeType: add changeType: add
objectClass: fedfsFsn objectClass: fedfsFsn
fedfsFsnUuid: $FSNUUID fedfsFsnUuid: $FSNUUID
fedfsFsnTTL: $TTL fedfsFsnTTL: $TTL
skipping to change at page 47, line 21 skipping to change at page 47, line 21
readability the DN is split into two lines): readability the DN is split into two lines):
dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3, dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3,
fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
changeType: delete changeType: delete
5.1.5. Update an FSL 5.1.5. Update an FSL
This operation updates the attributes of a given FSL. This command This operation updates the attributes of a given FSL. This command
results in a change in the attributes of the fedfsFsl at the NSDB results in a change in the attributes of the fedfsFsl at the NSDB
node maintaining this FSL. The attributes that must not change are node maintaining this FSL. The values of the fedfsFslUuid and
the fedfsFslUuid and the fedfsFsnUuid of the fileset this FSL fedfsFsnUuid attributes MUST NOT change during an FSL update.
implements.
5.1.5.1. LDAP Request 5.1.5.1. LDAP Request
The admin sends an LDAP MODIFY request to the NSDB node to update the The admin sends an LDAP MODIFY request to the NSDB node to update the
FSL. FSL.
dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE
changeType: modify changeType: modify
replace: $ATTRIBUTE-TYPE replace: $ATTRIBUTE-TYPE
skipping to change at page 50, line 21 skipping to change at page 50, line 21
Both the NFSv4 and LDAPv3 protocols provide security mechanisms. Both the NFSv4 and LDAPv3 protocols provide security mechanisms.
When used in conjunction with the federated filesystem protocols When used in conjunction with the federated filesystem protocols
described in this document, the use of these mechanisms is described in this document, the use of these mechanisms is
RECOMMENDED. Specifically, the use of RPCSEC_GSS [RFC2203], which is RECOMMENDED. Specifically, the use of RPCSEC_GSS [RFC2203], which is
built on the GSS-API [RFC2743], is RECOMMENDED on all NFS connections built on the GSS-API [RFC2743], is RECOMMENDED on all NFS connections
between a file-access client and fileserver. The "Security between a file-access client and fileserver. The "Security
Considerations" sections of the NFSv4.0 [3530bis] and NFSv4.1 Considerations" sections of the NFSv4.0 [3530bis] and NFSv4.1
[RFC5661] specifications contain special considerations for the [RFC5661] specifications contain special considerations for the
handling of GETATTR operations for the fs_locations and handling of GETATTR operations for the fs_locations and
fs_locations_info attributes. For all LDAP connections established fs_locations_info attributes.
by the federated filesystem protocols, the use of TLS [RFC5246], as
described in [RFC4513], is RECOMMENDED. NSDB nodes and NSDB clients MUST implement support for TLS [RFC5246],
as described in [RFC4513]. For all LDAP connections established by
the federated filesystem protocols, the use of TLS is RECOMMENDED.
If an NSDB client chooses to follow an LDAP referral, the NSDB client If an NSDB client chooses to follow an LDAP referral, the NSDB client
SHOULD authenticate the LDAP referral's target NSDB using the target SHOULD authenticate the LDAP referral's target NSDB using the target
NSDB's credentials (not the credentials of the NSDB that generated NSDB's credentials (not the credentials of the NSDB that generated
the LDAP referral). The NSDB client SHOULD NOT follow an LDAP the LDAP referral). The NSDB client SHOULD NOT follow an LDAP
referral that targets an NSDB for which it does not know the NSDB's referral that targets an NSDB for which it does not know the NSDB's
credentials. credentials.
Within a federation, there are two types of components an attacker Within a federation, there are two types of components an attacker
may compromise: a fileserver and an NSDB. may compromise: a fileserver and an NSDB.
skipping to change at page 51, line 46 skipping to change at page 51, line 48
registration. For viewing, the registry should be sorted registration. For viewing, the registry should be sorted
lexicographically by key. There are no initial assignments for this lexicographically by key. There are no initial assignments for this
registry. registry.
7.2. Registry for FedFS Object Identifiers 7.2. Registry for FedFS Object Identifiers
Using the process described in [RFC2578], one of the authors was Using the process described in [RFC2578], one of the authors was
assigned the Internet Private Enterprise Numbers range assigned the Internet Private Enterprise Numbers range
1.3.6.1.4.1.31103.x. Within this range, the subrange 1.3.6.1.4.1.31103.x. Within this range, the subrange
1.3.6.1.4.1.31103.1.x is permanently dedicated for use by the 1.3.6.1.4.1.31103.1.x is permanently dedicated for use by the
federated file system protocols. federated file system protocols. Unassigned OIDs in this range MAY
be used for Private Use or Experimental Use as defined in [RFC5226].
New permanent FedFS OID assignments MUST NOT be made using OIDs in
this range.
IANA is to create and maintain a new registry entitled "FedFS Object IANA is to create and maintain a new registry entitled "FedFS Object
Identifiers" for the purpose of administering the FedFS Object Identifiers" for the purpose of recording the allocations of FedFS
Identifier (OID) range. The location of this registry should be Object Identifiers (OIDs) specified by this document. No future
under the heading "Federated File System (FedFS) Parameters", created allocations in this registry are allowed.
in Section 7.1. The URL address can be based off of the new heading
name, for example: http://www.iana.org/assignments/fedfs-parameters/
...
Future allocations from the 1.3.6.1.4.1.31103.1.x range are to be The location of this registry should be under the heading "Federated
assigned by IANA using the "RFC Required" policy defined in File System (FedFS) Parameters", created in Section 7.1. The URL
[RFC5226]. Registration requests MUST include an OID value from the address can be based off of the new heading name, for example:
1.3.6.1.4.1.31103.1.x range, a short description of the OID, and a http://www.iana.org/assignments/fedfs-parameters/ ...
reference to the specification that defines the OID's usage. For
viewing, the registry should be sorted numerically by OID value. The For viewing, the registry should be sorted numerically by OID value.
initial contents of the FedFS Object Identifiers registry are given The contents of the FedFS Object Identifiers registry are given in
in Table 1. Table 1.
Note: A descriptor designated below as "historic" reserves an OID Note: A descriptor designated below as "historic" reserves an OID
used in a past version of the NSDB protocol. Registering such OIDs used in a past version of the NSDB protocol. Registering such OIDs
retains compatibility among existing implementations of the NSDB retains compatibility among existing implementations of the NSDB
protocol. This document does not otherwise refer to historic OIDs. protocol. This document does not otherwise refer to historic OIDs.
+--------------------------+-------------------------+-----------+ +--------------------------+-------------------------+-----------+
| OID | Description | Reference | | OID | Description | Reference |
+--------------------------+-------------------------+-----------+ +--------------------------+-------------------------+-----------+
| 1.3.6.1.4.1.31103.1.1 | fedfsUuid | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.1 | fedfsUuid | RFC-TBD1 |
skipping to change at page 54, line 31 skipping to change at page 54, line 31
Object Identifier: 1.3.6.1.4.1.31103.1.2 Object Identifier: 1.3.6.1.4.1.31103.1.2
Descriptor (short name): fedfsNetAddr Descriptor (short name): fedfsNetAddr
Usage: attribute type (historic) Usage: attribute type (historic)
Object Identifier: 1.3.6.1.4.1.31103.1.3 Object Identifier: 1.3.6.1.4.1.31103.1.3
Descriptor (short name): fedfsNetPort Descriptor (short name): fedfsNetPort
Usage: attribute type (historic) Usage: attribute type (historic)
Object Identifier: 1.3.6.1.4.1.31103.1.4 Object Identifier: 1.3.6.1.4.1.31103.1.4
Descriptor (short name): fedfsFsnUuid Descriptor (short name): fedfsFsnUuid
Usage: attribute type (historic) Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.5 Object Identifier: 1.3.6.1.4.1.31103.1.5
Descriptor (short name): fedfsNsdbName Descriptor (short name): fedfsNsdbName
Usage: attribute type (historic) Usage: attribute type (historic)
Object Identifier: 1.3.6.1.4.1.31103.1.6 Object Identifier: 1.3.6.1.4.1.31103.1.6
Descriptor (short name): fedfsNsdbPort Descriptor (short name): fedfsNsdbPort
Usage: attribute type (historic) Usage: attribute type (historic)
Object Identifier: 1.3.6.1.4.1.31103.1.7 Object Identifier: 1.3.6.1.4.1.31103.1.7
skipping to change at page 58, line 8 skipping to change at page 58, line 8
Usage: object class Usage: object class
8. Glossary 8. Glossary
Administrator: A user with the necessary authority to initiate Administrator: A 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 fileserver data using a supported File-access Client: Standard off-the-shelf network attached storage
file-access protocol. (NAS) client software that communicates with fileservers using a
standard file-access protocol.
Federation: A set of server collections and singleton servers that Federation: A set of fileserver collections and singleton
use a common set of interfaces and protocols in order to provide fileservers that use a common set of interfaces and protocols in
to their clients a federated namespace accessible through a order to provide to file-access clients a federated namespace
filesystem access protocol. accessible through a filesystem access protocol.
Fileserver: A server exporting one or more filesystems via a file- Fileserver: A server that stores physical fileset data, or refers
access protocol. file-access clients to other fileservers. A fileserver provides
access to its shared filesystem data via a file-access protocol.
Fileset: The abstraction of a set of files and the directory tree Fileset: The abstraction of a set of files and the directory tree
that contains them. 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. file-access protocol and the fileserver permit this.
File-access Protocol: A network filesystem access protocol such as File-access Protocol: A network filesystem access protocol such as
NFSv3 [RFC1813], NFSv4 [3530bis], or CIFS (Common Internet File NFSv3 [RFC1813], NFSv4 [3530bis], or CIFS (Common Internet File
System) [MS-SMB] [MS-SMB2] [MS-CIFS]. 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. An 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 an resource that a file-access client can access directly, such as an
fs_locations attribute (for NFSv4), or a share name (for CIFS). fs_locations attribute (for NFSv4), or a share name (for CIFS).
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. file-access 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.
Referral: A server response to a client access that directs the Referral: A server response to a file-access client access that
client to evaluate the current object as a reference to an object directs the client to evaluate the current object as a reference
at a different location (specified by an FSL) in another fileset, to an object at a different location (specified by an FSL) in
and possibly hosted on another fileserver. The client re-attempts another fileset, and possibly hosted on another fileserver. The
the access to the object at the new location. client re-attempts the access to the object at the new location.
Replica: A replica is a redundant implementation of a fileset. Each Replica: A replica is a redundant implementation of a fileset. Each
replica shares the same FSN, but has a different FSL. replica shares the same FSN, but has a different FSL.
Replicas may be used to increase availability or performance. Replicas may be used to increase availability or performance.
Updates to replicas of the same fileset MUST appear to occur in Updates to replicas of the same fileset MUST appear to occur in
the same order, and therefore each replica is self-consistent at the same order, and therefore each replica is self-consistent at
any moment. any moment.
We do not assume that updates to each replica occur We do not assume that updates to each replica occur
skipping to change at page 60, line 29 skipping to change at page 60, line 29
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[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.
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
Technical Specification", RFC 2849, June 2000. Technical Specification", RFC 2849, June 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[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.
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, (LDAP): Technical Specification Road Map", RFC 4510,
skipping to change at page 62, line 34 skipping to change at page 62, line 37
[RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Requirements for Federated File Systems", RFC 5716, Naik, "Requirements for Federated File Systems", RFC 5716,
January 2010. January 2010.
[RFC6641] Everhart, C., Adamson, W., and J. Zhang, "Using DNS SRV to [RFC6641] Everhart, C., Adamson, W., and J. Zhang, "Using DNS SRV to
Specify a Global File Namespace with NFS Version 4", Specify a Global File Namespace with NFS Version 4",
RFC 6641, June 2012. RFC 6641, June 2012.
Appendix A. Acknowledgments Appendix A. Acknowledgments
We would like to thank Andy Adamson of NetApp, Paul Lemahieu of EMC, The authors and editor would like to thank Craig Everhart and Manoj
Robert Thurlow of Oracle, and Mario Wurzl of EMC for helping to Naik, who were co-authors of an earlier version of this document. In
author this document. addition, we would like to thank Andy Adamson, Paul Lemahieu, Mario
Wurzl, and Robert Thurlow for helping to author this document.
We would like to thank Craig Everhart and Manoj Naik, who were co- We would like to thank George Amvrosiadis, Trond Myklebust, Howard
authors of an earlier version of this document. Chu, and Nicolas Williams for their comments and review.
We would also like to thank George Amvrosiadis, Chuck Lever, Trond The editor gratefully acknowledges the IESG reviewers, whose
Myklebust, Howard Chu, and Nicolas Williams for their comments. constructive comments helped make this a much stronger document.
Finally, we would also like to thank Andy Adamson, Rob Thurlow, Tom Finally, we would like to thank Andy Adamson, Rob Thurlow, and Tom
Haynes, and Chuck Lever for the editing effort to get this document Haynes for helping to get this document out the door.
out the door.
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 [RFC5662]. described by the authors of the NFSv4.1 XDR specification [RFC5662].
Authors' Addresses Authors' Addresses
James Lentini James Lentini
NetApp NetApp
1601 Trapelo Rd, Suite 16 1601 Trapelo Rd, Suite 16
Waltham, MA 02451 Waltham, MA 02451
 End of changes. 49 change blocks. 
111 lines changed or deleted 127 lines changed or added

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