draft-ietf-nfsv4-designconsider-02.txt   rfc2624.txt 
Network Working Group Spencer Shepler
Document: draft-ietf-nfsv4-designconsider-02.txt Network Working Group S. Shepler
Request for Comments: 2624 Sun Microsystems, Inc.
Category: Informational June 1999
NFS Version 4 Design Considerations NFS Version 4 Design Considerations
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (1999). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
The main task of the NFS version 4 working group is to create a The main task of the NFS version 4 working group is to create a
protocol definition for a distributed file system that focuses on the protocol definition for a distributed file system that focuses on the
following items: improved access and good performance on the following items: improved access and good performance on the
Internet, strong security with negotiation built into the protocol, Internet, strong security with negotiation built into the protocol,
better cross-platform interoperability, and designed for protocol better cross-platform interoperability, and designed for protocol
extensions. NFS version 4 will owe its general design to the extensions. NFS version 4 will owe its general design to the
previous versions of NFS. It is expected, however, that many previous versions of NFS. It is expected, however, that many
skipping to change at page 2, line 9 skipping to change at page 1, line 40
areas that NFS version 2 and 3 have not. areas that NFS version 2 and 3 have not.
This design considerations document is meant to present more detail This design considerations document is meant to present more detail
than the working group charter. Specifically, it presents the areas than the working group charter. Specifically, it presents the areas
that the working group will investigate and consider while developing that the working group will investigate and consider while developing
a protocol specification for NFS version 4. Based on this a protocol specification for NFS version 4. Based on this
investigation the working group will decide the features of the new investigation the working group will decide the features of the new
protocol based on the cost and benefits within the specific feature protocol based on the cost and benefits within the specific feature
areas. areas.
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved.
Key Words Key Words
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 RFC 2119. document are to be interpreted as described in RFC 2119.
Table of Contents Table of Contents
1. NFS Version 4 Design Considerations . . . . . . . . . . . . . 4 1. NFS Version 4 Design Considerations . . . . . . . . . . . . . 2
2. Ease of Implementation or Complexity of Protocol . . . . . . 4 2. Ease of Implementation or Complexity of Protocol . . . . . . 3
2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 4 2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 3
2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 4 2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 3
2.3. Relationship with Older Versions of NFS . . . . . . . . . . 6 2.3. Relationship with Older Versions of NFS . . . . . . . . . . 4
3. Reliable and Available . . . . . . . . . . . . . . . . . . . 6 3. Reliable and Available . . . . . . . . . . . . . . . . . . . 5
4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 7 4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 5
4.1. Throughput and Latency via the Network . . . . . . . . . . 7 4.1. Throughput and Latency via the Network . . . . . . . . . . 6
4.2. Client Caching . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Client Caching . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Disconnected Client Operation . . . . . . . . . . . . . . . 9 4.3. Disconnected Client Operation . . . . . . . . . . . . . . . 7
5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 9 5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Platform Specific Behavior . . . . . . . . . . . . . . . . 9 5.1. Platform Specific Behavior . . . . . . . . . . . . . . . . 8
5.2. Additional or Extended Attributes . . . . . . . . . . . . . 9 5.2. Additional or Extended Attributes . . . . . . . . . . . . . 8
5.3. Access Control Lists . . . . . . . . . . . . . . . . . . 10 5.3. Access Control Lists . . . . . . . . . . . . . . . . . . 9
6. RPC Mechanism and Security . . . . . . . . . . . . . . . . 11 6. RPC Mechanism and Security . . . . . . . . . . . . . . . . 10
6.1. User identification . . . . . . . . . . . . . . . . . . . 12 6.1. User identification . . . . . . . . . . . . . . . . . . . 10
6.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Transport Independence . . . . . . . . . . . . . . . . 13 6.2.1. Transport Independence . . . . . . . . . . . . . . . . 11
6.2.2. Authentication . . . . . . . . . . . . . . . . . . . . 13 6.2.2. Authentication . . . . . . . . . . . . . . . . . . . . 11
6.2.3. Data Integrity . . . . . . . . . . . . . . . . . . . . 13 6.2.3. Data Integrity . . . . . . . . . . . . . . . . . . . . 11
6.2.4. Data Privacy . . . . . . . . . . . . . . . . . . . . . 13 6.2.4. Data Privacy . . . . . . . . . . . . . . . . . . . . . 12
6.2.5. Security Negotiation . . . . . . . . . . . . . . . . . 14 6.2.5. Security Negotiation . . . . . . . . . . . . . . . . . 12
6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Internet Accessibility . . . . . . . . . . . . . . . . . . 15 7. Internet Accessibility . . . . . . . . . . . . . . . . . . 13
7.1. Congestion Control and Transport Selection . . . . . . . 15 7.1. Congestion Control and Transport Selection . . . . . . . 13
7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . . 16 7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . . 14
7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . . 16 7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . . 14
8. File locking / recovery . . . . . . . . . . . . . . . . . . 17 8. File locking / recovery . . . . . . . . . . . . . . . . . . 15
9. Internationalization . . . . . . . . . . . . . . . . . . . 18 9. Internationalization . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . 17
10.1. Denial of Service . . . . . . . . . . . . . . . . . . . 19 10.1. Denial of Service . . . . . . . . . . . . . . . . . . . 17
11. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 20 11. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 25 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 21
13. Author's Address . . . . . . . . . . . . . . . . . . . . . 25 13. Author's Address . . . . . . . . . . . . . . . . . . . . . 21
14. Full Copyright Statement . . . . . . . . . . . . . . . . . 26 14. Full Copyright Statement . . . . . . . . . . . . . . . . . 22
1. NFS Version 4 Design Considerations 1. NFS Version 4 Design Considerations
As stated in the charter, the first deliverable for the NFS version 4 As stated in the charter, the first deliverable for the NFS version 4
working group is this design considerations document. This document working group is this design considerations document. This document
is to cover the "limitations and deficiencies of NFS version 3". is to cover the "limitations and deficiencies of NFS version 3".
This document will also be used as a mechanism to focus discussion This document will also be used as a mechanism to focus discussion
and avenues of investigation as the definition of NFS version 4 and avenues of investigation as the definition of NFS version 4
progresses. Therefore, the contents of this document cover the progresses. Therefore, the contents of this document cover the
general functional/feature areas that are anticipated for NFS version general functional/feature areas that are anticipated for NFS version
skipping to change at page 10, line 41 skipping to change at page 9, line 8
file properties such as setting a size attribute to 0 and having file properties such as setting a size attribute to 0 and having
associated file data deleted. associated file data deleted.
As these brief examples show, this type of extended attribute As these brief examples show, this type of extended attribute
mechanism brings with it a large set of issues that will need to be mechanism brings with it a large set of issues that will need to be
addressed in the protocol specification while keeping the overall addressed in the protocol specification while keeping the overall
goal of simplicity in mind. goal of simplicity in mind.
There are operating environments that provide named or extended There are operating environments that provide named or extended
attribute mechanisms. Digital Unix provides for the storage of attribute mechanisms. Digital Unix provides for the storage of
extended attributes with some generalized format. HPFS[HPFS] and extended attributes with some generalized format. HPFS [HPFS] and
NTFS [Nagar] also provide for named data associated with traditional NTFS [Nagar] also provide for named data associated with traditional
files. SGI's local file system, XFS, also provides for this type of files. SGI's local file system, XFS, also provides for this type of
name/value extended attributes. However, there does not seem to be a name/value extended attributes. However, there does not seem to be a
clear direction that can be taken from these or other environments. clear direction that can be taken from these or other environments.
5.3. Access Control Lists 5.3. Access Control Lists
Access Control Lists (ACL) can be viewed as one specific type of Access Control Lists (ACL) can be viewed as one specific type of
extended attribute. This attribute is a designation of user access extended attribute. This attribute is a designation of user access
to a file or directory. Many vendors have created ancillary to a file or directory. Many vendors have created ancillary
skipping to change at page 16, line 12 skipping to change at page 14, line 12
transport mechanism, then the congestion controls issues will need transport mechanism, then the congestion controls issues will need
resolution to make its use suitable. resolution to make its use suitable.
7.2. Firewalls and Proxy Servers 7.2. Firewalls and Proxy Servers
NFS's protocol design should allow its use via Internet firewalls. NFS's protocol design should allow its use via Internet firewalls.
The protocol should also allow for the use of file system proxy/cache The protocol should also allow for the use of file system proxy/cache
servers. Proxy servers can be very useful for scalability and other servers. Proxy servers can be very useful for scalability and other
reasons. The NFS protocol needs to address the need of proxy servers reasons. The NFS protocol needs to address the need of proxy servers
in a way that will deal with the issues of security, access control, in a way that will deal with the issues of security, access control,
and content control. It is possible that these issues can be content control, and cache content validation. It is possible that
addressed by documenting the related issues of proxy server usage. these issues can be addressed by documenting the related issues of
However, it is likely that the NFS protocol will need to support proxy server usage. However, it is likely that the NFS protocol will
proxy servers directly through the NFS protocol. need to support proxy servers directly through the NFS protocol.
The protocol could allow a request to be sent to a proxy that The protocol could allow a request to be sent to a proxy that
contains the name of the target NFS server to which the request might contains the name of the target NFS server to which the request might
be forwarded, or from which a response might be cached. In any case, be forwarded, or from which a response might be cached. In any case,
the NFS proxy server should be considered during protocol the NFS proxy server should be considered during protocol
development. development.
The problems encountered in making the NFS protocol work through The problems encountered in making the NFS protocol work through
firewalls are described in detail in [RFC2054] and [RFC2055]. firewalls are described in detail in [RFC2054] and [RFC2055].
skipping to change at page 20, line 9 skipping to change at page 18, line 9
implementations or malicious agents is always a concern. With the implementations or malicious agents is always a concern. With the
target of providing NFS version 4 for Internet use, it is all the target of providing NFS version 4 for Internet use, it is all the
more important that all aspects of the NFS version 4 protocol be more important that all aspects of the NFS version 4 protocol be
reviewed for potential denial of service scenarios. When found these reviewed for potential denial of service scenarios. When found these
potential problems should be mitigated as much as possible. potential problems should be mitigated as much as possible.
11. Bibliography 11. Bibliography
[RFC1094] [RFC1094]
Sun Microsystems, Inc., "NFS: Network File System Protocol Sun Microsystems, Inc., "NFS: Network File System Protocol
Specification", RFC1094, March 1989. Specification", RFC 1094, March 1989.
http://www.ietf.org/rfc/rfc1094.txt http://www.ietf.org/rfc/rfc1094.txt
[RFC1510] [RFC1510]
Kohl, J., Neuman, C., "The Kerberos Network Authentication Service Kohl, J. and C. Neuman, "The Kerberos Network Authentication
(V5)", RFC1510, Digital Equipment Corporation, ISI, September 1993. Service (V5)", RFC 1510, September 1993.
http://www.ietf.org/rfc/rfc1510.txt http://www.ietf.org/rfc/rfc1510.txt
[RFC1813] [RFC1813]
Callaghan, B., Pawlowski, B., Staubach, P., "NFS Version 3 Protocol Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version 3
Specification", RFC1813, Sun Microsystems, Inc., June 1995. Protocol Specification", RFC 1813, June 1995.
http://www.ietf.org/rfc/rfc1813.txt http://www.ietf.org/rfc/rfc1813.txt
[RFC1831] [RFC1831]
Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification
Version 2", RFC1831, Sun Microsystems, Inc., August 1995. Version 2", RFC 1831, August 1995.
http://www.ietf.org/rfc/rfc1831.txt http://www.ietf.org/rfc/rfc1831.txt
[RFC1832] [RFC1832]
Srinivasan, R., "XDR: External Data Representation Standard", Srinivasan, R., "XDR: External Data Representation Standard",
RFC1832, Sun Microsystems, Inc., August 1995. RFC 1832, August 1995.
http://www.ietf.org/rfc/rfc1832.txt http://www.ietf.org/rfc/rfc1832.txt
[RFC1833] [RFC1833]
Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC1833, Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC
Sun Microsystems, Inc., August 1995. 1833, August 1995.
http://www.ietf.org/rfc/rfc1833.txt http://www.ietf.org/rfc/rfc1833.txt
[RFC2025] [RFC2025]
Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC2025, Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
Bell-Northern Research, October 1996. RFC 2025, October 1996.
http://www.ietf.org/rfc/rfc2025.txt http://www.ietf.org/rfc/rfc2025.txt
[RFC2054] [RFC2054]
Callaghan, B., "WebNFS Client Specification", RFC2054, Sun Callaghan, B., "WebNFS Client Specification", RFC 2054, October
Microsystems, Inc., October 1996 1996.
http://www.ietf.org/rfc/rfc2054.txt http://www.ietf.org/rfc/rfc2054.txt
[RFC2055] [RFC2055]
Callaghan, B., "WebNFS Server Specification", RFC2054, Sun Callaghan, B., "WebNFS Server Specification", RFC 2055, October
Microsystems, Inc., October 1996 1996.
http://www.ietf.org/rfc/rfc2055.txt http://www.ietf.org/rfc/rfc2055.txt
[RFC2078] [RFC2078]
Linn, J., "Generic Security Service Application Program Interface, Linn, J., "Generic Security Service Application Program Interface,
Version 2", RFC2078, OpenVision Technologies, January 1997. Version 2", RFC 2078, January 1997.
http://www.ietf.org/rfc/rfc2078.txt http://www.ietf.org/rfc/rfc2078.txt
[RFC2152] [RFC2152]
Goldsmith, D., "UTF-7 A Mail-Safe Transformation Format of Unicode", Goldsmith, D., "UTF-7 A Mail-Safe Transformation Format of Unicode",
RFC2152, Apple Computer, Inc., May 1997 RFC 2152, May 1997.
http://www.ietf.org/rfc/rfc2152.txt http://www.ietf.org/rfc/rfc2152.txt
[RFC2203] [RFC2203]
Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification", Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
RFC2203, Sun Microsystems, Inc., August 1995. Specification", RFC 2203, August 1995.
http://www.ietf.org/rfc/rfc2203.txt http://www.ietf.org/rfc/rfc2203.txt
[RFC2222] [RFC2222]
Myers, J., "Simple Authentication and Security Layer (SASL)", Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC2222, Netscape Communications, October 1997. RFC 2222, October 1997.
http://www.ietf.org/rfc/rfc2222.txt http://www.ietf.org/rfc/rfc2222.txt
[RFC2279] [RFC2279]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC2279, Yergeau, F., "UTF-8, a transformation format of ISO 10646",
Alis Technologies, January 1998. RFC 2279, January 1998.
http://www.ietf.org/rfc/rfc2279.txt http://www.ietf.org/rfc/rfc2279.txt
[RFC2246] [RFC2246]
Dierks, T., Allen, C. "The TLS Protocols Version 1.0", RFC 2246, Dierks, T. and C. Allen, "The TLS Protocols Version 1.0", RFC 2246,
Certicom, January 1999. Certicom, January 1999.
http://www.ietf.org/rfc/rfc2246.txt http://www.ietf.org/rfc/rfc2246.txt
[RFC2401] [RFC2401]
Kent, S., Atkinson, R., "Security Architecture for the Internet Kent, S. and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC2401, BBN Corp., @Home Network, November 1998. Protocol", RFC 2401, November 1998.
http://www.ietf.org/rfc/rfc2401.txt http://www.ietf.org/rfc/rfc2401.txt
[DCEACL] [DCEACL]
The Open Group, Open Group Technical Standard, "DCE 1.1: The Open Group, Open Group Technical Standard, "DCE 1.1:
Authentication and Security Services," Document Number C311, August Authentication and Security Services," Document Number C311, August
1997. Provides a discussion of DEC ACL structure and semantics. 1997. Provides a discussion of DEC ACL structure and semantics.
[HPFS] [HPFS]
Les Bell and Associates Pty Ltd, "The HPFS FAQ," Les Bell and Associates Pty Ltd, "The HPFS FAQ,"
http://www.lesbell.com.au/hpfsfaq.html http://www.lesbell.com.au/hpfsfaq.html
skipping to change at page 22, line 39 skipping to change at page 20, line 11
Huston, L.B., Honeyman, P., "Disconnected Operation for AFS," June Huston, L.B., Honeyman, P., "Disconnected Operation for AFS," June
1993. Proc. USENIX Symp. on Mobile and Location-Independent 1993. Proc. USENIX Symp. on Mobile and Location-Independent
Computing, Cambridge, August 1993. Computing, Cambridge, August 1993.
[Kistler] [Kistler]
Kistler, James J., Satyanarayanan, M., "Disconnected Operations in Kistler, James J., Satyanarayanan, M., "Disconnected Operations in
the Coda File System," ACM Trans. on Computer Systems, vol. 10, no. the Coda File System," ACM Trans. on Computer Systems, vol. 10, no.
1, pp. 3-25, Feb. 1992. 1, pp. 3-25, Feb. 1992.
[Mummert] [Mummert]
Mummert, L. B., Ebling, M. R., Satyanarayanan, M., "Exploiting Weak Mummert, L. B., Ebling, M. R., Satyanarayanan, M., "Exploiting Weak
Connectivity for Mobile File Access," Proc. of the 15th ACM Symp. on Connectivity for Mobile File Access," Proc. of the 15th ACM Symp.
Operating Systems Principles Dec. 1995. on Operating Systems Principles Dec. 1995.
[Nagar] [Nagar]
Nagar, R., "Windows NT File System Internals," ISBN 1565922492, Nagar, R., "Windows NT File System Internals," ISBN 1565922492,
O`Reilly & Associates, Inc. O`Reilly & Associates, Inc.
[Sandberg] [Sandberg]
Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon, "Design Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon, "Design
and Implementation of the Sun Network Filesystem," USENIX Conference and Implementation of the Sun Network Filesystem," USENIX
Proceedings, USENIX Association, Berkeley, CA, Summer 1985. The Conference Proceedings, USENIX Association, Berkeley, CA, Summer
basic paper describing the SunOS implementation of the NFS version 2 1985. The basic paper describing the SunOS implementation of the
protocol, and discusses the goals, protocol specification and trade- NFS version 2 protocol, and discusses the goals, protocol
offs. specification and trade-offs.
[Satyanarayanan1] [Satyanarayanan1]
Satyanarayanan, M., "Fundamental Challenges in Mobile Computing," Satyanarayanan, M., "Fundamental Challenges in Mobile Computing,"
Proc. of the ACM Principles of Distributed Computing, 1995. Proc. of the ACM Principles of Distributed Computing, 1995.
[Satyanarayanan2] [Satyanarayanan2]
Satyanarayanan, M., Kistler, J. J., Mummert L. B., Ebling M. R., Satyanarayanan, M., Kistler, J. J., Mummert L. B., Ebling M. R.,
Kumar, P. , Lu, Q., "Experience with disconnected operation in Kumar, P. , Lu, Q., "Experience with disconnected operation in
mobile computing environment," Proc. of the USENIX Symp. on Mobile mobile computing environment," Proc. of the USENIX Symp. on Mobile
and Location-Independent Computing, Jun. 1993. and Location-Independent Computing, Jun. 1993.
[Unicode1] [Unicode1]
"Unicode Technical Report #8 - The Unicode Standard, Version 2.1", "Unicode Technical Report #8 - The Unicode Standard, Version 2.1",
Unicode, Inc., The Unicode Consortium, P.O. Box 700519, San Jose, CA Unicode, Inc., The Unicode Consortium, P.O. Box 700519, San Jose,
95710-0519 USA, September 1998 CA 95710-0519 USA, September 1998
http://www.unicode.org/unicode/reports/tr8.html http://www.unicode.org/unicode/reports/tr8.html
[Unicode2] [Unicode2]
"Unsupported Scripts" Unicode, Inc., The Unicode Consortium, P.O. Box "Unsupported Scripts" Unicode, Inc., The Unicode Consortium, P.O.
700519, San Jose, CA 95710-0519 USA, October 1998 Box 700519, San Jose, CA 95710-0519 USA, October 1998
http://www.unicode.org/unicode/standard/unsupported.html http://www.unicode.org/unicode/standard/unsupported.html
[XDSM] [XDSM]
The Open Group, Open Group Technical Standard, "Systems Management: The Open Group, Open Group Technical Standard, "Systems Management:
Data Storage Management (XDSM) API," ISBN 1-85912-190-X, January Data Storage Management (XDSM) API," ISBN 1-85912-190-X, January
1997. 1997.
[XNFS] [XNFS]
The Open Group, Protocols for Interworking: XNFS, Version 3W, The The Open Group, Protocols for Interworking: XNFS, Version 3W, The
Open Group, 1010 El Camino Real Suite 380, Menlo Park, CA 94025, ISBN Open Group, 1010 El Camino Real Suite 380, Menlo Park, CA 94025,
1-85912-184-5, February 1998. ISBN 1-85912-184-5, February 1998.
HTML version available: http://www.opengroup.org HTML version available: http://www.opengroup.org
12. Acknowledgments 12. Acknowledgments
o Brent Callaghan for content contributions. o Brent Callaghan for content contributions.
13. Author's Address 13. Author's Address
Address comments related to this memorandum to: Address comments related to this memorandum to:
spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com
Spencer Shepler Spencer Shepler
Sun Microsystems, Inc. Sun Microsystems, Inc.
7808 Moonflower Drive 7808 Moonflower Drive
Austin, Texas 78750 Austin, Texas 78750
Phone: (512) 349-9376 Phone: (512) 349-9376
E-mail: spencer.shepler@eng.sun.com EMail: spencer.shepler@eng.sun.com
14. Full Copyright Statement 14. Full Copyright Statement
"Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 35 change blocks. 
126 lines changed or deleted 94 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/