draft-ietf-nfsv4-federated-fs-protocol-07.txt   draft-ietf-nfsv4-federated-fs-protocol-08.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: February 14, 2011 D. Ellard Expires: February 19, 2011 D. Ellard
Raytheon BBN Technologies Raytheon BBN Technologies
R. Tewari R. Tewari
M. Naik M. Naik
IBM Almaden IBM Almaden
August 13, 2010 August 18, 2010
NSDB Protocol for Federated Filesystems NSDB Protocol for Federated Filesystems
draft-ietf-nfsv4-federated-fs-protocol-07 draft-ietf-nfsv4-federated-fs-protocol-08
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 February 14, 2011. This Internet-Draft will expire on February 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 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 37 skipping to change at page 3, line 37
4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 13 4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 13
4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 14 4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 14
4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 16 4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 16
4.2.2. LDAP Objects . . . . . . . . . . . . . . . . . . . . . 34 4.2.2. LDAP Objects . . . . . . . . . . . . . . . . . . . . . 34
5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 37 5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 37
5.1. NSDB Operations for Administrators . . . . . . . . . . . . 38 5.1. NSDB Operations for Administrators . . . . . . . . . . . . 38
5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 39 5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 39
5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 40 5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 40
5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 40 5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 40
5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 43 5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 44
5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 43 5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 44
5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 44 5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 45
5.2.1. NSDB Container Entry (NCE) Enumeration . . . . . . . . 44 5.2.1. NSDB Container Entry (NCE) Enumeration . . . . . . . . 45
5.2.2. Lookup FSLs for an FSN . . . . . . . . . . . . . . . . 44 5.2.2. Lookup FSLs for an FSN . . . . . . . . . . . . . . . . 45
6. Security Considerations . . . . . . . . . . . . . . . . . . . 46 6. Security Considerations . . . . . . . . . . . . . . . . . . . 47
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
7.1. LDAP Descriptor Registration . . . . . . . . . . . . . . . 47 7.1. LDAP Descriptor Registration . . . . . . . . . . . . . . . 48
8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.1. Normative References . . . . . . . . . . . . . . . . . . . 52 9.1. Normative References . . . . . . . . . . . . . . . . . . . 53
9.2. Informative References . . . . . . . . . . . . . . . . . . 54 9.2. Informative References . . . . . . . . . . . . . . . . . . 55
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 55 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
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 or across multiple enterprises. fileservers within an enterprise or across multiple enterprises.
This document specifies a set of protocols that allow fileservers, This document specifies a set of protocols that allow fileservers,
possibly from different vendors and with different administrators, to possibly from different vendors and with different administrators, to
cooperatively form a federation containing one or more federated cooperatively form a federation containing one or more federated
skipping to change at page 4, line 41 skipping to change at page 4, line 41
administrator may be able to use the proprietary tools to build a administrator may be able to use the proprietary tools to build a
shared namespace out of the exported filesystems. However, relying shared namespace out of the exported filesystems. However, relying
on vendor-specific proprietary tools does not work in larger on vendor-specific proprietary tools does not work in larger
enterprises or when collaborating across enterprises because the enterprises or when collaborating across enterprises because the
fileservers are likely to be from multiple vendors or use different fileservers are likely to be from multiple vendors or use different
software versions, each with their own namespace protocols, with no software versions, each with their own namespace protocols, with no
common mechanism to manage the namespace or exchange namespace common mechanism to manage the namespace or exchange namespace
information. information.
The federated filesystem protocols in this document define how to The federated filesystem protocols in this document define how to
construct a namespace accessible by an NFSv4 [RFC3530] or NFSv4.1 construct a namespace accessible by an NFSv4 [3530bis] or NFSv4.1
[RFC5661] client and have been designed to accommodate other file [RFC5661] client and have been designed to accommodate other file
access protocols in the future. access protocols in the future.
The requirements for federated filesystems are described in The requirements for federated filesystems are described in
[RFC5716]. A protocol for administering a fileserver's namespace is [RFC5716]. A protocol for administering a fileserver's namespace is
described in [FEDFS-ADMIN]. The mechanism for discovering the root described in [FEDFS-ADMIN]. The mechanism for discovering the root
of an NFSv4 namespace is described in [FEDFS-DNS-SRV]. In the rest of an NFSv4 namespace is described in [FEDFS-DNS-SRV]. In the rest
of the document, the term fileserver denotes a fileserver that is of the document, the term fileserver denotes a fileserver that is
part of a federation. part of a federation.
skipping to change at page 6, line 38 skipping to change at page 6, line 38
Annotations: optional name/value pairs that can be interpreted by Annotations: optional name/value pairs that can be interpreted by
a fileserver. The semantics of this field are not defined by a 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: optional text descriptions. The semantics of this
field are not defined by this document. field are not defined by this document.
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 an NFSv4 fs_locations [RFC3530] or information suitable for use in an NFSv4 fs_locations [3530bis] or
NFSv4.1 fs_locations_info attribute [RFC5661]. NFSv4.1 fs_locations_info attribute [RFC5661].
A fileset MAY be accessible by protocols other than NFS. For each A fileset MAY be accessible by protocols other than NFS. For each
such protocol, a corresponding FSL subtype SHOULD be defined. The such protocol, a corresponding FSL subtype SHOULD be defined. The
contents and format of such FSL subtypes are not defined in this contents and format of such FSL subtypes are not defined in this
document. document.
2.4.1. Mutual Consistency across Fileset Locations 2.4.1. Mutual Consistency across Fileset Locations
All of the FSLs that have the same FSN (and thereby reference the All of the FSLs that have the same FSN (and thereby reference the
skipping to change at page 12, line 48 skipping to change at page 12, line 48
3. Using the FSN, the fileserver finds the NSDB node responsible for 3. Using the FSN, the fileserver finds the NSDB node responsible for
the target FSN. the target FSN.
4. The fileserver contacts that NSDB node and asks for the set of 4. The fileserver contacts that NSDB node and asks for the set of
FSLs that implement the target FSN. The NSDB node responds with FSLs that implement the target FSN. The NSDB node responds with
a (possibly empty) set of FSLs. a (possibly empty) set of FSLs.
5. The fileserver converts one or more of the FSLs to the location 5. The fileserver converts one or more of the FSLs to the location
type used by the client (e.g., a Network File System (NFSv4) type used by the client (e.g., a Network File System (NFSv4)
fs_location, as described in [RFC3530]). fs_location, as described in [3530bis]).
6. The fileserver redirects (in whatever manner is appropriate for 6. The fileserver redirects (in whatever manner is appropriate for
the client) the client to the location(s). the client) the client to the location(s).
3.3. Example Use Cases for Fileset Annotations 3.3. Example Use Cases for Fileset Annotations
Fileset annotations MAY be used to convey additional attributes of a Fileset annotations MAY be used to convey additional attributes of a
fileset fileset
For example, fileset annotations can be used to define relationships For example, fileset annotations can be used to define relationships
skipping to change at page 17, line 29 skipping to change at page 17, line 29
/// DESC 'A UUID used by NSDB' /// DESC 'A UUID used by NSDB'
/// SUP name /// SUP name
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.2. fedfsNetAddr 4.2.1.2. fedfsNetAddr
A fedfsNetAddr is the locative name of a network service. It MUST be A fedfsNetAddr is the locative name of a network service in either
a UTF-8 string and represent a network location in either IPv4, IPv6, IPv4, IPv6, or DNS name notation. It MUST be a UTF-8 string and
or DNS name notation. SHOULD be prepared using the server4 rules defined in Chapter 12
"Internationalization" of [3530bis].
An IPv4 address MUST be represented using the standard dotted decimal An IPv4 address MUST be represented using the standard dotted decimal
format defined by the IPv4address rule in Section 3.2.2 of RFC 3986 format defined by the IPv4address rule in Section 3.2.2 of RFC 3986
[RFC3986]. An IPv6 address MUST be represented using the format [RFC3986]. An IPv6 address MUST be represented using the format
defined in Section 2.2 of RFC 4291 [RFC4291]. defined in Section 2.2 of RFC 4291 [RFC4291].
A DNS name MUST be represented using a fully qualified domain name. A DNS name MUST be represented using a fully qualified domain name.
A system (i.e. fileserver or administrative host) SHOULD resolve the A system (i.e. fileserver or administrative host) SHOULD resolve the
fully qualified domain name to a network address using the system's fully qualified domain name to a network address using the system's
standard resolution mechanisms. standard resolution mechanisms.
skipping to change at page 24, line 22 skipping to change at page 24, line 22
/// 1.3.6.1.4.1.31103.1.13 NAME 'fedfsDescr' /// 1.3.6.1.4.1.31103.1.13 NAME 'fedfsDescr'
/// DESC 'Description of an object' /// DESC 'Description of an object'
/// SUP name /// SUP name
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.14. fedfsNfsPath 4.2.1.14. fedfsNfsPath
A fedfsNfsPath is the path component of an FSL. The path MUST be the A fedfsNfsPath is the path attribute of an FSL. The path MUST be the
XDR encoded NFS pathname as defined by the fs_location's rootpath XDR encoded NFS path as defined by the NFS pathname4 XDR type of the
[RFC3530] and the fs_locations_item's fli_rootpath [RFC5661]. A fs_location's rootpath [3530bis] and the fs_locations_item's
pathname is an XDR encoded variable length array of variable length fli_rootpath [RFC5661]. The NFS pathname4 XDR type is a variable
opaque data. length array of component4 elements. The NFS component4 XDR type is
a variable length array of opaque data. A fedfsNfsPath attribute's
component4 elements SHOULD be prepared using the component4 rules
defined in Chapter 12 "Internationalization" of [3530bis].
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.100 NAME 'fedfsNfsPath' /// 1.3.6.1.4.1.31103.1.100 NAME 'fedfsNfsPath'
/// DESC 'Server-local path to a fileset' /// DESC 'Server-local path to a fileset'
/// EQUALITY octetStringMatch /// EQUALITY octetStringMatch
skipping to change at page 43, line 6 skipping to change at page 43, line 6
fedfsNfsClassReaddir: 9 fedfsNfsClassReaddir: 9
fedfsNfsReadRank: 7 fedfsNfsReadRank: 7
fedfsNfsReadOrder: 8 fedfsNfsReadOrder: 8
fedfsNfsWriteRank: 5 fedfsNfsWriteRank: 5
fedfsNfsWriteOrder: 6 fedfsNfsWriteOrder: 6
fedfsNfsVarSub: FALSE fedfsNfsVarSub: FALSE
fedfsNfsValidFor: 300 fedfsNfsValidFor: 300
fedfsAnnotation: "foo" = "bar" fedfsAnnotation: "foo" = "bar"
fedfsDescr: This is a description. fedfsDescr: This is a description.
5.1.3.2. Selecting fedfsNfsFsl Values
The fedfsNfsFSl object class is used to describe NFSv4 and NFSv4.1
accessible filesets. For the reasons described in Section 2.4.3,
administrators SHOULD choose reasonable values for all LDAP
attributes of an NFSv4 accessible fedfsNfsFsl even though some of
these LDAP attributes are not explicitly contained in the NFSv4
fs_locations attribute returned to an NFSv4 client.
When the administrator is unable to choose reasonable values for the
LDAP attributes not explicitly contained in a NFSv4 fs_locations
attribute, the values in the following table are RECOMMENDED.
+-------------------------+----------+------------------------------+
| LDAP attribute | LDAP | Notes |
| | value | |
+-------------------------+----------+------------------------------+
| fedfsNfsCurrency | negative | Indicates that the server |
| | value | does not know the currency |
| | | (see 11.10.1 of [RFC5661]). |
| fedfsNfsGenFlagWritable | FALSE | Leaving unset is not harmful |
| | | (see 11.10.1 of [RFC5661]). |
| fedfsNfsGenFlagGoing | FALSE | NFS client will detect a |
| | | migration event if the FSL |
| | | becomes unavailable. |
| fedfsNfsGenFlagSplit | TRUE | Safe to assume that the FSL |
| | | is split. |
| fedfsNfsTransFlagRdma | TRUE | NFS client will detect if |
| | | RDMA access is available. |
| fedfsNfsClassSimul | 0 | 0 (zero) is treated as |
| | | non-matching (see 11.10.1 of |
| | | [RFC5661]). |
| fedfsNfsClassHandle | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsClassFileid | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsClassWritever | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsClassChange | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsClassReaddir | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsReadRank | 0 | Highest value ensures FSL |
| | | will be tried. |
| fedfsNfsReadOrder | 0 | See fedfsNfsReadRank note. |
| fedfsNfsWriteRank | 0 | See fedfsNfsReadRank note. |
| fedfsNfsWriteOrder | 0 | See fedfsNfsReadRank note. |
| fedfsNfsVarSub | FALSE | NFSv4 does not define |
| | | variable substituion in |
| | | paths. |
| fedfsNfsValidFor | 0 | Indicates no appropriate |
| | | refetch interval (see |
| | | 11.10.2 of [RFC5661]). |
+-------------------------+----------+------------------------------+
5.1.4. Delete an FSL 5.1.4. Delete an FSL
This operation deletes the given Fileset location. The admin This operation deletes the given Fileset location. The admin
requests the NSDB node storing the fedfsFsl to delete it from its requests the NSDB node storing the fedfsFsl to delete it from its
database. This operation does not result in the fileset location's database. This operation does not result in the fileset location's
data being deleted at the fileserver. data being deleted at the fileserver.
5.1.4.1. LDAP Request 5.1.4.1. LDAP Request
The admin sends an LDAP DELETE request to the NSDB node to remove the The admin sends an LDAP DELETE request to the NSDB node to remove the
skipping to change at page 44, line 37 skipping to change at page 45, line 39
/* $BAR is a DN */ /* $BAR is a DN */
query for a fedfsNcePrefix value at $BAR query for a fedfsNcePrefix value at $BAR
/* /*
* The LDAP URL for this search would be * The LDAP URL for this search would be
* *
* ldap://foo.example.com:389/$BAR?fedfsNcePrefix?? * ldap://foo.example.com:389/$BAR?fedfsNcePrefix??
* (objectClass=fedfsNsdbContainerInfo) * (objectClass=fedfsNsdbContainerInfo)
* *
*/ */
if a fedfsNcePrefix value is found if a fedfsNcePrefix value is found
prepend value to $BAR and add to nce_list nce = prepend the fedfsNcePrefix value to $BAR
add nce to the nce_list
5.2.2. Lookup FSLs for an FSN 5.2.2. Lookup FSLs for an FSN
Using an LDAP search, the fileserver can obtain all of the FSLs for a Using an LDAP search, the fileserver can obtain all of the FSLs for a
given FSN. The FSN's fedfsFsnUuid is used as the search key. The given FSN. The FSN's fedfsFsnUuid is used as the search key. The
following examples use the LDAP URI format defined in [RFC4516]. following examples use the LDAP URI format defined in [RFC4516].
To obtain a list of all FSLs for $FSNUUID on the NSDB named To obtain a list of all FSLs for $FSNUUID on the NSDB named
$NSDBNAME, the following search can be used (for readability the URI $NSDBNAME, the following search can be used (for readability the URI
is split into two lines): is split into two lines):
skipping to change at page 46, line 13 skipping to change at page 47, line 17
Section 2.4.3. Section 2.4.3.
6. Security Considerations 6. Security Considerations
Both NFSv4/NFSv4.1 and LDAP provide security mechanisms. When used Both NFSv4/NFSv4.1 and LDAP provide security mechanisms. When used
in conjunction with the federated filesystem protocols described in in conjunction with the federated filesystem protocols described in
this document, the use of these mechanisms is RECOMMENDED. this document, the use of these mechanisms is RECOMMENDED.
Specifically, the use of RPCSEC_GSS [RFC2203], which is built on the Specifically, the use of RPCSEC_GSS [RFC2203], which is built on the
GSS-API [RFC2743], is RECOMMENDED on all NFS connections between a GSS-API [RFC2743], is RECOMMENDED on all NFS connections between a
client and fileserver. The "Security Considerations" sections of the client and fileserver. The "Security Considerations" sections of the
the NFSv4 [RFC3530] and NFSv4.1 [RFC5661] specifications contain the NFSv4 [3530bis] and NFSv4.1 [RFC5661] specifications contain
special considerations for the handling of GETATTR operations for the special considerations for the handling of GETATTR operations for the
fs_locations and fs_locations_info attributes. For all LDAP fs_locations and fs_locations_info attributes. For all LDAP
connections established by the federated filesystem protocols, the connections established by the federated filesystem protocols, the
use of TLS [RFC5246], as described in [RFC4513], is RECOMMENDED. use of TLS [RFC5246], as described in [RFC4513], is RECOMMENDED.
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.
If an attacker compromises a fileserver, the attacker can interfere If an attacker compromises a fileserver, the attacker can interfere
with the client's filesystem I/O operations (e.g. by returning with the client's filesystem I/O operations (e.g. by returning
skipping to change at page 51, line 24 skipping to change at page 52, line 29
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 CIFS such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [3530bis], or CIFS
(Common Internet File System) [MS-SMB] [MS-SMB2] [MS-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. 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 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.
skipping to change at page 52, line 41 skipping to change at page 53, line 48
The namespace provided by a server collection could be part of the The namespace provided by a server collection could be part of the
federated namespace. federated namespace.
Singleton Server: A server collection containing only one server; a Singleton Server: A server collection containing only one server; a
stand-alone fileserver. stand-alone fileserver.
9. References 9. References
9.1. Normative References 9.1. Normative References
[3530bis] Haynes, T. and D. Noveck, "NFS Version 4 Protocol",
draft-ietf-nfsv4-rfc3530bis (Work In Progress), 2010.
[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.
[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.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003.
[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.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
skipping to change at page 55, line 16 skipping to change at page 56, line 23
[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.
Appendix A. Acknowledgments Appendix A. Acknowledgments
We would like to thank Andy Adamson of NetApp, Paul Lemahieu of EMC, We would like to thank Andy Adamson of NetApp, Paul Lemahieu of EMC,
Robert Thurlow of Sun Microsystems, and Mario Wurzl of EMC for Robert Thurlow of Sun Microsystems, and Mario Wurzl of EMC for
helping to author this document. helping to author this document.
We would also like to thank George Amvrosiadis, Trond Myklebust, and We would also like to thank George Amvrosiadis, Chuck Lever, Trond
Nicolas Williams for their comments. Myklebust, and Nicolas Williams for their comments.
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
skipping to change at page 56, line 10 skipping to change at page 57, line 10
US US
Phone: +1 919-476-5320 Phone: +1 919-476-5320
Email: everhart@netapp.com Email: everhart@netapp.com
Daniel Ellard Daniel Ellard
Raytheon BBN Technologies Raytheon BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge, MA 02138 Cambridge, MA 02138
US US
Phone: +1 617-873-8000 Phone: +1 617-873-8004
Email: dellard@bbn.com Email: dellard@bbn.com
Renu Tewari Renu Tewari
IBM Almaden IBM Almaden
650 Harry Rd 650 Harry Rd
San Jose, CA 95120 San Jose, CA 95120
US US
Email: tewarir@us.ibm.com Email: tewarir@us.ibm.com
 End of changes. 18 change blocks. 
39 lines changed or deleted 93 lines changed or added

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