draft-ietf-nfsv4-federated-fs-admin-11.txt   draft-ietf-nfsv4-federated-fs-admin-12.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: December 16, 2012 D. Ellard Expires: March 29, 2013 D. Ellard
Raytheon BBN Technologies Raytheon BBN Technologies
R. Tewari R. Tewari
M. Naik M. Naik
IBM Almaden IBM Almaden
June 14, 2012 September 25, 2012
Administration Protocol for Federated Filesystems Administration Protocol for Federated Filesystems
draft-ietf-nfsv4-federated-fs-admin-11 draft-ietf-nfsv4-federated-fs-admin-12
Abstract Abstract
This document describes the administration protocol for a federated This document describes the administration protocol for a federated
file system that enables file access and namespace traversal across file system that enables file access and namespace traversal across
collections of independently administered fileservers. The protocol collections of independently administered fileservers. The protocol
specifies a set of interfaces by which fileservers with different specifies a set of interfaces by which fileservers with different
administrators can form a fileserver federation that provides a administrators can form a fileserver federation that provides a
namespace composed of the filesystems physically hosted on and namespace composed of the filesystems physically hosted on and
exported by the constituent fileservers. exported by the constituent 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 December 16, 2012. This Internet-Draft will expire on March 29, 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 4, line 7 skipping to change at page 4, line 7
5.9. FEDFS_GET_NSDB_PARAMS . . . . . . . . . . . . . . . . . . 32 5.9. FEDFS_GET_NSDB_PARAMS . . . . . . . . . . . . . . . . . . 32
5.9.1. Synopsis . . . . . . . . . . . . . . . . . . . . . . . 32 5.9.1. Synopsis . . . . . . . . . . . . . . . . . . . . . . . 32
5.9.2. Description . . . . . . . . . . . . . . . . . . . . . 32 5.9.2. Description . . . . . . . . . . . . . . . . . . . . . 32
5.9.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 32 5.9.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 32
5.10. FEDFS_GET_LIMITED_NSDB_PARAMS . . . . . . . . . . . . . . 32 5.10. FEDFS_GET_LIMITED_NSDB_PARAMS . . . . . . . . . . . . . . 32
5.10.1. Synopsis . . . . . . . . . . . . . . . . . . . . . . . 33 5.10.1. Synopsis . . . . . . . . . . . . . . . . . . . . . . . 33
5.10.2. Description . . . . . . . . . . . . . . . . . . . . . 33 5.10.2. Description . . . . . . . . . . . . . . . . . . . . . 33
5.10.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 33 5.10.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Normative References . . . . . . . . . . . . . . . . . . . 34 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35
8.2. Informative References . . . . . . . . . . . . . . . . . . 35 8.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
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 5, line 37 skipping to change at page 5, line 37
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.
1.1. Definitions 1.1. Definitions
Administrator: user with the necessary authority to initiate Administrator: An 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
skipping to change at page 6, line 24 skipping to change at page 6, line 24
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 [3530bis], or CIFS such as NFSv3 [RFC1813], NFSv4 [3530bis], or CIFS (Common Internet
(Common Internet File System) [MS-SMB] [MS-SMB2] [MS-CIFS]. 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.
FSN (Fileset Name): A platform-independent and globally unique name FSN (Fileset Name): A platform-independent and globally unique name
skipping to change at page 8, line 31 skipping to change at page 8, line 31
The effect of the script is to remove leading white space from each The effect of the script is to remove leading white space from each
line, plus a sentinel sequence of "///". line, plus a sentinel sequence of "///".
The protocol definition in XDR notation is shown below. We begin by The protocol definition in XDR notation is shown below. We begin by
defining basic constants and structures used by the protocol. We defining basic constants and structures used by the protocol. We
then present the procedures defined by the protocol. then present the procedures defined by the protocol.
<CODE BEGINS> <CODE BEGINS>
/// /* /// /*
/// * Copyright (c) 2010 IETF Trust and the persons identified /// * Copyright (c) 2010-2012 IETF Trust and the persons identified
/// * as authors of the code. All rights reserved. /// * as authors of the code. All rights reserved.
/// * /// *
/// * The authors of the code are the authors of /// * The authors of the code are the authors of
/// * [draft-ietf-nfsv4-federated-fs-admin-xx.txt]: J. Lentini, /// * [draft-ietf-nfsv4-federated-fs-admin-xx.txt]: J. Lentini,
/// * C. Everhart, D. Ellard, R. Tewari, and M. Naik. /// * C. Everhart, D. Ellard, R. Tewari, and M. Naik.
/// * /// *
/// * Redistribution and use in source and binary forms, with /// * Redistribution and use in source and binary forms, with
/// * or without modification, are permitted provided that the /// * or without modification, are permitted provided that the
/// * following conditions are met: /// * following conditions are met:
/// * /// *
skipping to change at page 10, line 17 skipping to change at page 10, line 17
/// FEDFS_ERR_NSDB_RESPONSE = 26, /// FEDFS_ERR_NSDB_RESPONSE = 26,
/// FEDFS_ERR_NSDB_FAULT = 27, /// FEDFS_ERR_NSDB_FAULT = 27,
/// FEDFS_ERR_NSDB_PARAMS = 28, /// FEDFS_ERR_NSDB_PARAMS = 28,
/// FEDFS_ERR_NSDB_LDAP_REFERRAL = 29, /// FEDFS_ERR_NSDB_LDAP_REFERRAL = 29,
/// FEDFS_ERR_NSDB_LDAP_REFERRAL_VAL = 30, /// FEDFS_ERR_NSDB_LDAP_REFERRAL_VAL = 30,
/// FEDFS_ERR_NSDB_LDAP_REFERRAL_NOTFOLLOWED = 31, /// FEDFS_ERR_NSDB_LDAP_REFERRAL_NOTFOLLOWED = 31,
/// FEDFS_ERR_NSDB_PARAMS_LDAP_REFERRAL = 32, /// FEDFS_ERR_NSDB_PARAMS_LDAP_REFERRAL = 32,
/// FEDFS_ERR_PATH_TYPE_UNSUPP = 33, /// FEDFS_ERR_PATH_TYPE_UNSUPP = 33,
/// FEDFS_ERR_DELAY = 34, /// FEDFS_ERR_DELAY = 34,
/// FEDFS_ERR_NO_CACHE = 35, /// FEDFS_ERR_NO_CACHE = 35,
/// FEDFS_ERR_UNKNOWN_CACHE = 36, /// FEDFS_ERR_UNKNOWN_CACHE = 36,
/// FEDFS_ERR_NO_CACHE_UPDATE = 37 /// FEDFS_ERR_NO_CACHE_UPDATE = 37
/// }; /// };
/// ///
/// typedef opaque utf8string<>; /// typedef opaque utf8string<>;
/// typedef utf8string utf8str_cs; /// typedef utf8string ascii_REQUIRED4;
/// typedef utf8string utf8str_cis; /// typedef utf8string utf8val_REQUIRED4;
/// ///
/// typedef opaque FedFsUuid[16]; /// typedef opaque FedFsUuid[16];
/// ///
/// struct FedFsNsdbName { /// struct FedFsNsdbName {
/// unsigned int port; /// unsigned int port;
/// utf8str_cis hostname; /// utf8val_REQUIRED4 hostname;
/// }; /// };
/// ///
/// typedef utf8str_cs FedFsPathComponent; /// typedef ascii_REQUIRED4 FedFsPathComponent;
/// typedef FedFsPathComponent FedFsPathName<>; /// typedef FedFsPathComponent FedFsPathName<>;
/// ///
/// struct FedFsFsn { /// struct FedFsFsn {
/// FedFsUuid fsnUuid; /// FedFsUuid fsnUuid;
/// FedFsNsdbName nsdbName; /// FedFsNsdbName nsdbName;
/// }; /// };
/// ///
/// enum FedFsFslType { /// enum FedFsFslType {
/// FEDFS_NFS_FSL = 0 /// FEDFS_NFS_FSL = 0
/// /* other types TBD */ /// /* other types TBD */
/// }; /// };
/// ///
/// struct FedFsNfsFsl { /// struct FedFsNfsFsl {
/// FedFsUuid fslUuid; /// FedFsUuid fslUuid;
/// unsigned int port; /// unsigned int port;
/// utf8str_cis hostname; /// utf8val_REQUIRED4 hostname;
/// FedFsPathName path; /// FedFsPathName path;
/// }; /// };
/// ///
/// union FedFsFsl switch(FedFsFslType type) { /// union FedFsFsl switch(FedFsFslType type) {
/// case FEDFS_NFS_FSL: /// case FEDFS_NFS_FSL:
/// FedFsNfsFsl nfsFsl; /// FedFsNfsFsl nfsFsl;
/// }; /// };
/// ///
/// enum FedFsPathType { /// enum FedFsPathType {
/// FEDFS_PATH_SYS = 0, /// FEDFS_PATH_SYS = 0,
skipping to change at page 16, line 34 skipping to change at page 16, line 34
unable to communicate with the FSN-to-FSL cache if it exists. unable to communicate with the FSN-to-FSL cache if it exists.
FEDFS_ERR_NO_CACHE_UPDATE: The fileserver was unable to update its FEDFS_ERR_NO_CACHE_UPDATE: The fileserver was unable to update its
FSN-to-FSL cache. FSN-to-FSL cache.
4. Data Types 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:
FedFsUuid: 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 4 UUID. The UUID should be formatted in
network byte order. network byte order.
FedFsNsdbName: A (hostname, port) pair. FedFsNsdbName: A (hostname, port) pair.
The hostname is a variable length UTF-8 string that represents an The hostname is a variable length UTF-8 string that represents an
NSDB's network location in DNS name notation. It SHOULD be NSDB's network location in DNS name notation. It SHOULD be
prepared using the server4 rules defined in Chapter 12 prepared using the server4 rules defined in Chapter 12
"Internationalization" of [3530bis]. The DNS name MUST be "Internationalization" of [3530bis]. The DNS name MUST be
represented using a fully qualified domain name. A system (i.e., represented using a fully qualified domain name. A system (i.e.,
fileserver or administrative host) SHOULD resolve the fully fileserver or administrative host) SHOULD resolve the fully
qualified domain name to a network address using the system's qualified domain name to a network address using the system's
standard resolution mechanisms. standard resolution mechanisms.
The port is the NSDB transport port for the LDAP interface (see The port value in the FedFsNsdbName indicates the LDAP port on the
[RFC4511]). The value MUST be in the range 0 to 65535. A value NSDB (see [RFC4511]). The value MUST be in the range 0 to 65535.
of 0 indicates that the standard LDAP port number, 389, SHOULD be A value of 0 indicates that the standard LDAP port number, 389,
assumed. SHOULD be assumed.
FSNs are immutable and invariant. The attributes of an FSN, FSNs are immutable and invariant. The attributes of an FSN,
including the fedfsNsdbName, are expected to remain constant. including the fedfsNsdbName, are expected to remain constant.
Therefore, a FedFsNsdbName SHOULD NOT contain a network address, Therefore, a FedFsNsdbName SHOULD NOT contain a network address,
such as an IPv4 or IPv6 address, as this would indefinitely assign such as an IPv4 or IPv6 address, as this would indefinitely assign
the network address. the network address.
FedFsPathComponent: A case sensitive UTF-8 string containing a FedFsPathComponent: A case sensitive UTF-8 string containing a
filesystem path component. It SHOULD be prepared using the filesystem path component. It SHOULD be prepared using the
component4 rules defined in Chapter 12 "Internationalization" of component4 rules defined in Chapter 12 "Internationalization" of
skipping to change at page 17, line 51 skipping to change at page 17, line 51
The secType field indicates the security mechanism that MUST be The secType field indicates the security mechanism that MUST be
used to protect all connections to the NSDB with the connection used to protect all connections to the NSDB with the connection
parameters. parameters.
A value of FEDFS_SEC_NONE indicates that no security mechanism is A value of FEDFS_SEC_NONE indicates that no security mechanism is
necessary. In this case, the secData array will have 0 length. necessary. In this case, the secData array will have 0 length.
A value of FEDFS_SEC_TLS indicates that the StartTLS security A value of FEDFS_SEC_TLS indicates that the StartTLS security
mechanism [RFC4513] MUST be used to protect all connections to the mechanism [RFC4513] MUST be used to protect all connections to the
NSDB. In this case, the secData array will contain an X.509v3 NSDB. In this case, the secData array will contain an X.509v3
certificate in binary DER format [RFC5280]. The certificate root certificate in binary DER format [RFC5280] fulfilling the TLS
SHOULD be used by the fileserver to authenticate the identity of requirement that root keys be distributed independently from the
the NSDB. In particular, this certificate SHOULD be used to TLS protocol. The certificate MUST be used by the fileserver as a
validate the NSDB's TLS certificate list chain (see 7.4.2 of Trust Anchor to validate the NSDB's TLS server certificate list
[RFC5246]). The certificate could be that of a certificate chain (see section 7.4.2 of [RFC5246]) and thus authenticate the
authority or a self-signed certificate. identitiy of the NSDB. The certificate could be that of a
certificate authority or a self-signed certificate.
4.1. FedFsNsdbName Equality 4.1. FedFsNsdbName Equality
Two FedFsNsdbNames are considered equal if both their DNS name and Two FedFsNsdbNames are considered equal if both their DNS name and
port values are the same. As described above, the standard LDAP port port values are the same. As described above, the standard LDAP port
number, 389, SHOULD be assumed if a port number of 0 is specified. number, 389, SHOULD be assumed if a port number of 0 is specified.
Therefore, the FedFsNsdbName "(nsdb.example.com, 0)" is considered Therefore, the FedFsNsdbName "(nsdb.example.com, 0)" is considered
equal to "(nsdb.example.com, 389)" but not equal to equal to "(nsdb.example.com, 389)" but not equal to
"(nsdb.example.com, 1066)" since the port number is different or "(nsdb.example.com, 1066)" since the port number is different or
"(nsdb.foo.example.com, 389)" since the DNS name is different. "(nsdb.foo.example.com, 389)" since the DNS name is different.
skipping to change at page 34, line 19 skipping to change at page 34, line 19
FEDFS_ERR_SVRFAULT FEDFS_ERR_SVRFAULT
FEDFS_ERR_NSDB_PARAMS FEDFS_ERR_NSDB_PARAMS
FEDFS_ERR_NOTSUPP FEDFS_ERR_NOTSUPP
FEDFS_ERR_DELAY FEDFS_ERR_DELAY
6. Security Considerations 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. When RPCSEC_GSS is employed, RPCSEC_GSS data integrity
SHOULD be used.
It is strongly RECOMMENDED that an Access Control Service be employed
to restrict access to a fileserver's FedFS administration
configuration data via the FedFS administrative protocol to prevent
FedFS namespace corruption, and protect NSDB communication
parameters.
For example, when the FedFsNsdbParams secType field value
FEDFS_SEC_TLS is chosen, the payload is used to provision the trust
anchor root certificate for TLS secure communication between the
fileserver and the NSDB. In this case, RPCSEC_GSS with data
integrity SHOULD be employed along with an Access Control Service to
restrict access to domain adminstrators
FEDFS_GET_LIMITED_NSDB_PARAMS's interaction with the NSDB's FEDFS_GET_LIMITED_NSDB_PARAMS's interaction with the NSDB's
connection parameters is discussed in Section 5.10.2. connection parameters is discussed in Section 5.10.2.
7. 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 with This document describes version 1 of the ONC RPC program 100418 with
short name "fedfs_admin". the short name "fedfs_admin", a Description of "FedFS
Administration", and a reference of [RFCTBD10]. Program 100418 will
be removed from the reserved FedFS range and assigned these new
values.
8. References 8. References
8.1. Normative References 8.1. Normative References
[3530bis] Haynes, T. and D. Noveck, "NFS Version 4 Protocol", [3530bis] Haynes, T. and D. Noveck, "NFS Version 4 Protocol",
draft-ietf-nfsv4-rfc3530bis (Work In Progress), 2010. 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.
skipping to change at page 35, line 45 skipping to change at page 36, line 14
[MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS) [MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS)
Protocol Specification", MS-CIFS 2.0, November 2009. Protocol Specification", MS-CIFS 2.0, November 2009.
[MS-SMB] Microsoft Corporation, "Server Message Block (SMB) [MS-SMB] Microsoft Corporation, "Server Message Block (SMB)
Protocol Specification", MS-SMB 17.0, November 2009. Protocol Specification", MS-SMB 17.0, November 2009.
[MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version [MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version
2 Protocol Specification", MS-SMB2 19.0, November 2009. 2 Protocol Specification", MS-SMB2 19.0, November 2009.
[RFC1094] Nowicki, B., "NFS: Network File System Protocol
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.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol", System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010. RFC 5661, January 2010.
[RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 External Data System (NFS) Version 4 Minor Version 1 External Data
Representation Standard (XDR) Description", RFC 5662, Representation Standard (XDR) Description", RFC 5662,
skipping to change at page 36, line 30 skipping to change at page 36, line 44
We would also like to thank Paul Lemahieu and Mario Wurzl for helping We would also like to thank Paul Lemahieu and Mario Wurzl for helping
to author this document. to author this 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, Chuck Lever for suggesting improvements to the FSL pathname format, Chuck Lever for suggesting
improvements to the XDR type definitions and error codes, David improvements to the XDR type definitions and error codes, David
Noveck for his suggestions on internationalization and path encoding Noveck for his suggestions on internationalization and path encoding
rules, and Nicolas Williams for his suggestions. rules, and Nicolas Williams for his suggestions.
Finally, we would like to thank Tom Haynes for his editing of the Finally, we would also like to thank Andy Adamson, Rob Thurlow, Tom
final stages of the draft. Haynes, and Chuck Lever for the editing effort to get this document
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].
Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this
document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the
RFC number of this document]
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
US US
Phone: +1 781-768-5359 Phone: +1 781-768-5359
Email: jlentini@netapp.com Email: jlentini@netapp.com
 End of changes. 22 change blocks. 
35 lines changed or deleted 61 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/