draft-ietf-nfsv4-federated-fs-admin-02.txt   draft-ietf-nfsv4-federated-fs-admin-03.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: January 11, 2010 D. Ellard Expires: April 29, 2010 D. Ellard
BBN Technologies BBN Technologies
R. Tewari R. Tewari
M. Naik M. Naik
IBM Almaden IBM Almaden
July 10, 2009 October 26, 2009
Administration Protocol for Federated Filesystems Administration Protocol for Federated Filesystems
draft-ietf-nfsv4-federated-fs-admin-02 draft-ietf-nfsv4-federated-fs-admin-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 11, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
skipping to change at page 2, line 23 skipping to change at page 3, line 7
physically hosted on and exported by the constituent fileservers. physically hosted on and exported by the constituent fileservers.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Error Definitions . . . . . . . . . . . . . . . . . . . . . . 3 2. Error Definitions . . . . . . . . . . . . . . . . . . . . . . 4
3. Administrator-Initiated Operations . . . . . . . . . . . . . . 5 3. Administrator-Initiated Operations . . . . . . . . . . . . . . 6
3.1. Basic Definition . . . . . . . . . . . . . . . . . . . . . 5 3.1. Basic Definition . . . . . . . . . . . . . . . . . . . . . 6
3.2. Required Procedures . . . . . . . . . . . . . . . . . . . 7 3.2. Required Procedures . . . . . . . . . . . . . . . . . . . 8
3.2.1. FEDFS_CREATE_JUNCTION . . . . . . . . . . . . . . . . 8 3.2.1. FEDFS_CREATE_JUNCTION . . . . . . . . . . . . . . . . 9
3.2.2. FEDFS_DELETE_JUNCTION . . . . . . . . . . . . . . . . 9 3.2.2. FEDFS_DELETE_JUNCTION . . . . . . . . . . . . . . . . 10
3.2.3. FEDFS_LOOKUP_FSN . . . . . . . . . . . . . . . . . . . 10 3.2.3. FEDFS_LOOKUP_FSN . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informational References . . . . . . . . . . . . . . . . . 14 7.2. Informational References . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
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 41 skipping to change at page 6, line 41
<CODE BEGINS> <CODE BEGINS>
sh extract.sh < spec.txt > admin1.xdr sh extract.sh < spec.txt > admin1.xdr
<CODE ENDS> <CODE ENDS>
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 "///".
<CODE BEGIN> <CODE BEGINS>
/// enum FedFsStatus { /// enum FedFsStatus {
/// FEDFS_OK = 0, /// FEDFS_OK = 0,
/// FEDFS_ERR_ACCESS = 1, /// FEDFS_ERR_ACCESS = 1,
/// FEDFS_ERR_BADCHAR = 2, /// FEDFS_ERR_BADCHAR = 2,
/// FEDFS_ERR_BADXDR = 3, /// FEDFS_ERR_BADXDR = 3,
/// FEDFS_ERR_EXIST = 4, /// FEDFS_ERR_EXIST = 4,
/// FEDFS_ERR_INVAL = 5, /// FEDFS_ERR_INVAL = 5,
/// FEDFS_ERR_IO = 6, /// FEDFS_ERR_IO = 6,
/// FEDFS_ERR_NOSPC = 7, /// FEDFS_ERR_NOSPC = 7,
skipping to change at page 6, line 18 skipping to change at page 7, line 18
/// FEDFS_ERR_NOTEMPTY = 9, /// FEDFS_ERR_NOTEMPTY = 9,
/// FEDFS_ERR_NOTJUNCT = 10, /// FEDFS_ERR_NOTJUNCT = 10,
/// FEDFS_ERR_NOTLOCAL = 11, /// FEDFS_ERR_NOTLOCAL = 11,
/// FEDFS_ERR_PERM = 12, /// FEDFS_ERR_PERM = 12,
/// FEDFS_ERR_ROFS = 13, /// FEDFS_ERR_ROFS = 13,
/// FEDFS_ERR_SVRFAULT = 14 /// FEDFS_ERR_SVRFAULT = 14
/// }; /// };
/// ///
/// typedef opaque FedFsFsnUuid<16>; /// typedef opaque FedFsFsnUuid<16>;
/// typedef opaque FedFsNsdbName<>; /// typedef opaque FedFsNsdbName<>;
/// typedef opaque FedFsPathName<>; /// typedef opaque FedFsPathComponent<>;
/// typedef FedFsPathComponent FedFsPathName<>;
/// typedef opaque FedFsNsdbContainerEntry<>;
/// ///
/// struct FedFsFsn { /// struct FedFsFsn {
/// FedFsFsnUuid fsnUuid; /// FedFsFsnUuid fsnUuid;
/// FedFsNsdbName nsdbName; /// FedFsNsdbName nsdbName;
/// FedFsNsdbContainerEntry nce;
/// }; /// };
/// ///
/// struct FedFsCreateJunctionArgs { /// struct FedFsCreateJunctionArgs {
/// FedFsPathName path; /// FedFsPathName path;
/// FedFsFsn fsn; /// FedFsFsn fsn;
/// }; /// };
/// ///
/// union FedFsLookupFsnRes switch (FedFsStatus status) { /// union FedFsLookupFsnRes switch (FedFsStatus status) {
/// case FEDFS_OK: /// case FEDFS_OK:
/// FedFsFsn fsn; /// FedFsFsn fsn;
skipping to change at page 6, line 49 skipping to change at page 8, line 5
/// void FEDFS_NULL(void) = 0; /// void FEDFS_NULL(void) = 0;
/// FedFsStatus FEDFS_CREATE_JUNCTION( /// FedFsStatus FEDFS_CREATE_JUNCTION(
/// FedFsCreateJunctionArgs args) = 1; /// FedFsCreateJunctionArgs args) = 1;
/// FedFsStatus FEDFS_DELETE_JUNCTION( /// FedFsStatus FEDFS_DELETE_JUNCTION(
/// FedFsPathName path) = 2; /// FedFsPathName path) = 2;
/// FedFsLookupFsnRes FEDFS_LOOKUP_FSN( /// FedFsLookupFsnRes FEDFS_LOOKUP_FSN(
/// FedFsPathName path) = 3; /// FedFsPathName path) = 3;
/// } = 1; /// } = 1;
/// } = 100418; /// } = 100418;
<CODE END> <CODE ENDS>
The basic data types defined above MUST be formatted as follows: The basic data types defined above MUST be formatted as follows:
FedFsFsnUuid: A universally unique identifier (UUID) as described in FedFsFsnUuid: A universally unique identifier (UUID) as described in
[RFC4122] as a version 1 UUID. The UUID should be formatted in [RFC4122] as a version 1 UUID. The UUID should be formatted in
network byte order. network byte order.
FedFsNsdbName: A variable length UTF-8 string that represents an FedFsNsdbName: A variable length UTF-8 string that represents an
NSDB's network location in either IPv4, IPv6, or DNS host name NSDB's network location in either IPv4, IPv6, or DNS host name
notation. notation. The format is the same as that specified for an
fs_location4's server array elements in section 11.9 of [NFSv4.1].
FedFsPathName: A variable UTF-8 string that represents a file system FedFsPathName: A variable length array of FedFsPathComponent values
path. representing a filesystem path. The path's first component is
stored at the first position of the array, the second component is
stored at the second position of the array, and so on. Each
FedFsPathComponent is a case sensitive UTF-8 string containing a
component of the filesystem path.
FedFsNsdbContainerEntry: A case sensitive UTF-8 string containing
the distinguished name of the NSDB Container Entry (NCE). A
string of up to 128 characters MUST be supported. A string
greater than 128 characters MAY be supported.
3.2. Required Procedures 3.2. Required Procedures
Fileservers that participate as "internal" nodes in the federated Fileservers that participate as "internal" nodes in the federated
namespace MUST provide these procedures: namespace MUST provide these procedures:
FEDFS_NULL The null RPC, which is included, by convention, in every FEDFS_NULL The null RPC, which is included, by convention, in every
ONC RPC protocol. ONC RPC protocol.
FEDFS_CREATE_JUNCTION Create a new junction from some location on FEDFS_CREATE_JUNCTION Create a new junction from some location on
skipping to change at page 8, line 10 skipping to change at page 9, line 24
be reflected consistently across the set of replicas in such a manner be reflected consistently across the set of replicas in such a manner
that the replicas will converge to a consistent state within a that the replicas will converge to a consistent state within a
bounded number of successful message exchanges between the servers bounded number of successful message exchanges between the servers
hosting the replicas. hosting the replicas.
3.2.1. FEDFS_CREATE_JUNCTION 3.2.1. FEDFS_CREATE_JUNCTION
This operation creates a junction from a server-relative path to a This operation creates a junction from a server-relative path to a
(potentially) remote fileset named by the given FSN. (potentially) remote fileset named by the given FSN.
The junction directory on the server is named by a pathname in the The junction directory on the server is identified by a pathname in
form of a UTF-8 string that has a well-defined interpretation by the the form of an array of one or more UTF-8 path component strings. It
server). It is not required that this path be accessible in any is not required that this path be accessible in any other manner
other manner (e.g., to a client). This path does not appear in the (e.g., to a client). This path does not appear in the federated
federated namespace, except by coincidence; there is no requirement namespace, except by coincidence; there is no requirement that the
that the global namespace parallel the server namespace, nor is it global namespace parallel the server namespace, nor is it required
required that this path be relative to the server pseudo-root. It that this path be relative to the server pseudo-root. It does not
does not need to be a path that is accessible via NFS (although the need to be a path that is accessible via NFS (although the junction
junction will be of limited utility if the directory specified by the will be of limited utility if the directory specified by the path is
path is not also accessible via NFS). not also accessible via NFS).
If the fileset is read-only, then this operation SHOULD indicate this If the fileset is read-only, then this operation SHOULD indicate this
with a status of FEDFS_ERR_ROFS. with a status of FEDFS_ERR_ROFS.
If the path contains an invalid UTF-8 character, then status If the path contains an invalid UTF-8 character, then status
FEDFS_ERR_BADCHAR must be returned. FEDFS_ERR_BADCHAR must be returned.
The path is REQUIRED to exist and be completely local to the server. The path is REQUIRED to exist and be completely local to the server.
It MUST NOT contain a junction. If the last component of the path is It MUST NOT contain a junction. If the last component of the path is
a junction (i.e., this operation is attempting to create a junction a junction (i.e., this operation is attempting to create a junction
skipping to change at page 9, line 26 skipping to change at page 10, line 41
Note that this operation does not create a fileset at the location Note that this operation does not create a fileset at the location
targeted by the junction. If the target fileset does not exist, the targeted by the junction. If the target fileset does not exist, the
junction will still be created. An NFS client will discover the junction will still be created. An NFS client will discover the
missing fileset when it traverses the junction. missing fileset when it traverses the junction.
3.2.2. FEDFS_DELETE_JUNCTION 3.2.2. FEDFS_DELETE_JUNCTION
This operation removes a junction specified by a server-relative This operation removes a junction specified by a server-relative
path. path.
As with FEDFS_CREATE_JUNCTION, the junction on the server is named by As with FEDFS_CREATE_JUNCTION, the junction on the server is
a pathname in the form of a UTF-8 string that has a well-defined identified by a pathname in the form of an array of one or more UTF-8
interpretation by the server. It is not required that this path be path component strings. It is not required that this path be
accessible in any other manner (e.g., to a client). This path does accessible in any other manner (e.g., to a client). This path does
not appear in the federated namespace, except by coincidence; there not appear in the federated namespace, except by coincidence; there
is no requirement that the global namespace reflect the server is no requirement that the global namespace reflect the server
namespace, nor is it required that this path be relative to the namespace, nor is it required that this path be relative to the
server pseudo-root. It does not need to be a path that is accessible server pseudo-root. It does not need to be a path that is accessible
via NFS. via NFS.
If the fileset is read-only, then this operation SHOULD indicate this If the fileset is read-only, then this operation SHOULD indicate this
with a status of FEDFS_ERR_ROFS. with a status of FEDFS_ERR_ROFS.
skipping to change at page 10, line 37 skipping to change at page 11, line 52
3.2.3. FEDFS_LOOKUP_FSN 3.2.3. FEDFS_LOOKUP_FSN
This operation queries a server to determine whether a given path This operation queries a server to determine whether a given path
ends in a junction, and if so, the FSN to which the junction refers. ends in a junction, and if so, the FSN to which the junction refers.
Ordinary NFSv4 operations do not provide any general mechanism to Ordinary NFSv4 operations do not provide any general mechanism to
determine whether an object is a junction -- there is no encoding determine whether an object is a junction -- there is no encoding
specified by the NFSv4 protocol that can represent this information. specified by the NFSv4 protocol that can represent this information.
As with FEDFS_CREATE_JUNCTION, the pathname must be in the form of a As with FEDFS_CREATE_JUNCTION, the pathname must be in the form of an
UTF-8 string that has a well-defined interpretation by the server. array of one or more UTF-8 path component strings. It is not
It is not required that this path be accessible in any other manner required that this path be accessible in any other manner (e.g., to a
(e.g., to a client). This path does not appear in the federated client). This path does not appear in the federated namespace,
namespace, except by coincidence; there is no requirement that the except by coincidence; there is no requirement that the global
global namespace reflect the server namespace, nor is it required namespace reflect the server namespace, nor is it required that this
that this path be relative to the server pseudo-root. It does not path be relative to the server pseudo-root. It does not need to be a
need to be a path that is accessible via NFS. path that is accessible via NFS.
If the path contains an invalid UTF-8 character, then status If the path contains an invalid UTF-8 character, then status
FEDFS_ERR_BADCHAR must be returned. FEDFS_ERR_BADCHAR must be returned.
The path used to lookup a junction might not be the same path that The path used to lookup a junction might not be the same path that
was used to create the junction. If the namespace on the server has was used to create the junction. If the namespace on the server has
changed, then a junction may now appear at a different path than changed, then a junction may now appear at a different path than
where it was created. If there is more than one valid path to the where it was created. If there is more than one valid path to the
junction, any of them may be used. junction, any of them may be used.
skipping to change at page 13, line 8 skipping to change at page 14, line 21
same. same.
Junction: A filesystem object used to link a directory name in the Junction: A filesystem object used to link a directory name in the
current fileset with an object within another fileset. The current fileset with an object within another fileset. The
server-side "link" from a leaf node in one fileset to the root of server-side "link" from a leaf node in one fileset to the root of
another fileset. another fileset.
Namespace: A filename/directory tree that a sufficiently-authorized Namespace: A filename/directory tree that a sufficiently-authorized
client can observe. client can observe.
NSDB (Namespace Database Service): A service that maps FSNs to FSLs. NSDB (Namespace Database) Service: A service that maps FSNs to FSLs.
The NSDB may also be used to store other information, such as The NSDB may also be used to store other information, such as
annotations for these mappings and their components. annotations for these mappings and their components.
NSDB Node: The name or location of a server that implements part of NSDB Node: The name or location of a server that implements part of
the NSDB service and is responsible for keeping track of the FSLs the NSDB service and is responsible for keeping track of the FSLs
(and related info) that implement a given partition of the FSNs. (and related info) that implement a given partition of the FSNs.
Referral: A server response to a client access that directs the Referral: A server response to a client access that directs the
client to evaluate the current object as a reference to an object client to evaluate the current object as a reference to an object
at a different location (specified by an FSL) in another fileset, at a different location (specified by an FSL) in another fileset,
skipping to change at page 13, line 30 skipping to change at page 14, line 43
the access to the object at the new location. 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 simultaneously We do not assume that updates to each replica occur
If a replica is offline or unreachable, the other replicas may be simultaneously. If a replica is offline or unreachable, the other
updated. replicas may be updated.
Server Collection: A set of fileservers administered as a unit. A Server Collection: A set of fileservers administered as a unit. A
server collection may be administered with vendor-specific server collection may be administered with vendor-specific
software. software.
The namespace provided by a server collection could be part of the The namespace provided by a server collection could be part of the
federated namespace. federated namespace.
Singleton Server: A server collection containing only one server; a Singleton Server: A server collection containing only one server; a
stand-alone fileserver. stand-alone fileserver.
skipping to change at page 14, line 25 skipping to change at page 15, line 38
[RFC4506] Eisler, M., "XDR: External Data Representation Standard", [RFC4506] Eisler, M., "XDR: External Data Representation Standard",
STD 67, RFC 4506, May 2006. STD 67, RFC 4506, May 2006.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, May 2009. Specification Version 2", RFC 5531, May 2009.
7.2. Informational References 7.2. Informational References
[FEDFS-NSDB] [FEDFS-NSDB]
J. Lentini, et al., "NSDB Protocol for Federated Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Filesystems (Work In Progress)", Naik, "NSDB Protocol for Federated Filesystems",
draft-ietf-nfsv4-federated-fs-admin , 2009. draft-ietf-nfsv4-federated-fs-protocol (Work In Progress),
2009.
[FEDFS-REQTS] [FEDFS-REQTS]
J. Lentini, et al., "Requirements for Federated File Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Systems (Work In Progress)", Naik, "Requirements for Federated File Systems",
draft-ietf-nfsv4-federated-fs-reqts , 2008. draft-ietf-nfsv4-federated-fs-reqts (Work In Progress),
2009.
[NFSv4.1] S. Shepler, et al., "NFS Version 4 Minor Version 1 (Work [NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4
In Progress)", draft-ietf-nfsv4-minorversion1 , 2008. Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work
in progress), December 2008.
[NFSv4.1-XDR]
Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4
Minor Version 1 XDR Description",
draft-ietf-nfsv4-minorversion1-dot-x-12 (work in
progress), December 2008.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
Appendix A. Acknowledgments Appendix A. Acknowledgments
We would like to thank Paul Lemahieu of EMC, Robert Thurlow of Sun We would like to thank Paul Lemahieu of EMC, Robert Thurlow of Sun
Microsystems, and Mario Wurzl of EMC for helping to author this Microsystems, and Mario Wurzl of EMC for helping to author this
document. document.
We would also like to thank Trond Myklebust for suggesting
improvements to the FSL pathname format.
The extract.sh shell script and formatting conventions were first
described by the authors of the NFSv4.1 XDR specification
[NFSv4.1-XDR].
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. 
61 lines changed or deleted 99 lines changed or added

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