wdiff draft-ietf-nfsv4-requirements-00.txt draft-ietf-nfsv4-requirements-01.txt

Network Working Group Spencer Shepler

Document: draft-ietf-nfsv4-requirements-00.txt draft-ietf-nfsv4-requirements-01.txt

NFS Version 4 Requirements

Status of this Memo

This document is an Internet-Draft. 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."

To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

With the creation of the NFS version 4 working group, a set of
requirements for the next version of NFS must be codified to create a
reasonable context for the new protocol discussions and aide in the
upcoming decisions. This Internet Draft has the purpose of
presenting the requirements for NFS version 4 and will be used as the
leading document for NFSv4 working group.

NFSv4 NFSv4 Requirements September 1998

Table of Contents

1. NFS Version 4 Requirements . . . . . . . . . . . . . . . . . 3
2. Ease of implementation or complexity of protocol . . . . . . 3
2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 3
2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 3
3. Reliable and Available . . . . . . . . . . . . . . . . . . . 4
4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 4
4.1. Throughput and Latency on the Network . . . . . . . . . . 4 5
4.2. Server Work Load or Scalability . . . . . . . . . . . . . 4 5
4.3. Client Caching . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Disconnected Client Operation . . . . . . . . . . . . . . 5 6
5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 5 6
5.1. Platform Specific Behavior . . . . . . . . . . . . . . . . 6
5.2. Additional or Extended Attributes . . . . . . . . . . . . . . . . . . . 6
5.3. Access Control Lists . . . . . . . . . . . . . . . . . . . 6 7
6. RPC Mechanism and Security . . . . . . . . . . . . . . . . . 7 8
6.1. Remote Procedure Call Mechanism . . . . . . . . . . . . . 7 8
6.2. User identification . . . . . . . . . . . . . . . . . . . 7 8
6.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3.1. Authentication . . . . . . . . . . . . . . . . . . . . . 9
6.3.2. Data Integrity . 8
6.4. Security Negotiation . . . . . . . . . . . . . . . . . . . 8
7. Internet Accessibility 10
6.3.3. Data Privacy . . . . . . . . . . . . . . . . . . . . 9
7.1. Transports . 10
6.3.4. Security Mechanisms . . . . . . . . . . . . . . . . . 10
6.3.5. Security Negotiation . . . . . . 9 . . . . . . . . . . . 10
7. Internet Accessibility . . . . . . . . . . . . . . . . . . 10
7.1. Congestion Control and Transport Selection . . . . . . . 11
7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . . 9 11
7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . . 9 11
8. File locking / recovery . . . . . . . . . . . . . . . . . 10 12
9. Internationalization . . . . . . . . . . . . . . . . . . . 11 13
10. Bibliography . . . . . . . . . . . . . . . . . . . . . . 12 14
11. Author's Address . . . . . . . . . . . . . . . . . . . . 14 16

NFSv4 NFSv4 Requirements September 1998

1. NFS Version 4 Requirements

As stated in the charter the first deliverable for the NFS version 4
working group is this requirements document. This document is to
cover the "limitations and deficiencies of NFS version 3". Therefore
the intent of the following sections is to identify the various
feature points of NFS as a distributed file system and discuss its
current functionality and compare to other distributed file systems
and offer reasonable requirements for each of these areas.

2. Ease of implementation or complexity of protocol

One of the strengths of NFS has been the ability to implement a
client or server with comparative relative ease. The eventual size of a basic
implementation is relatively small. One The main reason that for keeping NFS
as simple as possible is that a simple protocol design can be
described in a simple specification that promotes straightforward,
interoperable implementations. All protocols can run into problems
when deployed on real networks, but simple protocols yield problems
that are easier to diagnose and correct.

2.1. Extensibility / layering

With NFS' relative simplicity, the addition or layering of
functionality has been easy to accomplish. The addition of features
like the client automount or autofs, client side disk caching and
high availability servers are some examples. This type of extensibility
is desirable in an environment where problem solutions do not require
protocol revision. This extensibility can also be helpful in the
future where unforeseen problems or opportunities can be solved by
layering functionality on an existing set of tools or protocol.

2.2. Managed Extensions or Minor Versioning

For those cases where a the NFS protocol is deficient or where a minor
modification is the best solution for a problem, a minor version or a
managed extension of the NFS protocol would could be helpful. With There have been instances with
NFS version 2, there were many minor extensions in 2 and 3 where small straightforward functional additions
would have increased the overall value of the protocol to solve
problems which were unforeseen. However they were done in immensely.
However, the perceived size and burden of using a way that
was not well documented or detection change of support was not possible. A RPC
version number for the introduction of new functionality led to no or
slow change. It is possible that a new NFS protocol should could allow for
the rare instance where protocol extension within the RPC version

NFSv4 NFSv4 Requirements September 1998

number is the most prudent course and an entire RPC revision would be
unnecessary or impractical.

NFSv4 Requirements September 1998

3. Reliable and Available

Current

The areas of an NFS protocol design has lead to quick recovery from server which are most obviously volatile are
new orthogonal procedures, new well-defined file or directory
attributes and client failure. This approach to the design has lended itself
well to potentially new file types. It is possible and highly
desirable that these types of additions can be done without changing
the overall design model of NFS without significant effort or delay.
This is particularly true in adding new procedures.

A strong consideration should be given to a NFS protocol mechanism
for the introduction of this type of new functionality. This is
obviously in contrast to using the standard RPC version mechanism to
provide minor changes. The process of using RPC version numbers to
introduce new functionality brings with it a lot of history which may
not technically prevent its use. However, the historical issues
involved will need to be addressed as part of the NFS protocol work
to increase the chance of current and future success of the protocol.

3. Reliable and Available

Current NFS protocol design has lead to quick recovery from server
and client failure. This approach to the design has lent itself well
to layered technologies like high availability and clustered servers.
Providing a protocol design approach that lends itself to these types
of reliability and availability features is very desirable.

For the next version of NFS, consideration should be given to client
side availability schemes such as client switching between or fail-
over to available server replicas. If possible, the protocol should
allow for or ease the building of such layered solutions.

4. Scalable Performance

In designing and developing an NFS protocol from a performance
viewpoint there are several different points to consider. Each can
play a significant role in perceived and real performance from the
user's perspective. The three main areas of interest are: throughput
and latency on the network, server work load or scalability and
client side caching.

NFSv4 NFSv4 Requirements September 1998

4.1. Throughput and Latency on the Network

NFS currently has characteristics that provide good throughput for
read
the reading and write writing of file data. However, the number of RPCs
required to accomplish some tasks combined with high latency network
environments leads to sluggish response. The protocol should
continue to provide good raw read and write throughput. It should also address throughput while
addressing the issue of network latencies. latency. This issue is discussed
further in the section on Internet Accessibility.

4.2. Server Work Load or Scalability

Current NFS operations are relatively lightweight in that the
processing work for most of the operations is not CPU intensive.
This allows for potential support of a large number of clients. This
attribute can also be helpful in building efficient and scalable SMP
or cluster based servers. While this type of protocol design
(lightweight operations) is desirable, it needs to be balanced
against the previous issue of having the client generate a large
number of RPCs to accomplish a straight forward task.

NFSv4 Requirements September 1998

4.3. Client Caching

In an attempt to speed response time and to reduce network and server
load, NFS clients have always cached directory and file data.
However, this has usually been done as memory cache and in relatively
recent history, local disk caching has been added.

Having the client cache directory and file data is very desirable.
Other distributed file systems have shown that aggressive client side
caching can be very visible to the end user in response time gains.
Client caching is increasingly important for Internet environments
where throughput can be limited and response time can grow
significantly.

The NFS protocol should allow for aggressive caching while balancing
the needs for simplicity and Internet accessibility (i.e. firewalls).
If possible, the caching ability should be layered on the protocol
instead of embedding specific client caching functions in the
protocol itself.

NFSv4 NFSv4 Requirements September 1998

4.4. Disconnected Client Operation

An extension of client caching is the idea or functionality of
disconnected operation at the client. With the ability to cache
directory and file data aggressively, a client could then provide
service to the end user while disconnected from the server or
network.

While very desirable, disconnected operation has the opportunity to
inflict itself on upon the NFS protocol more so than regular in an undesirable way as
compared to traditional client caching. If this area is pursued, the tradeoffs will need to be
weighed carefully in the areas of Given the semantics complexities of
disconnected client operation along with user data synchronization or and subsequent resolution at the
point of reconnection.

Editors Note: This section needs to be discussed and
expanded client
data modification through various playback or clarified if it is found to data selection
mechanisms, disconnected operation should not be a stronger requirement than what is stated in for
the above text.

5. Interoperability

The NFS protocols are available for many different operating
environments. effort. Even though this shows so, the protocol's ability to

NFSv4 Requirements September 1998 NFS protocol should consider the
potential layering of disconnected operation solutions on top of the
NFS protocol (as with other server and client solutions). The
experiences with Coda, disconnected AFS and others should be helpful
in this area.

5. Interoperability

The NFS protocols are available for many different operating
environments. Even though this shows the protocol's ability to
provide distributed file system service in for more than a single
operating system, the design of NFS is certainly Unix centric.
Distributed file systems are usually tied in some way to the original
operating environment for which they were developed. A desired
feature of the The
next NFS protocol is needs to reduce be more inclusively of platform centric or file
system features while retaining reasonable functionality and performance in
the protocol. beyond those of traditional Unix.

5.1. Platform Specific Behavior

Because of its Unix centric design, some of the protocol requirements
have been difficult to implement in some environments. For example,
persistent file handles (unique identifiers of file system objects),
Unix uid/gid mappings, directory modification time, accurate file
sizes.

Editors Note: This list could be expanded or more detail
of the associated problems could be added.
sizes, file/directory locking semantics (SHAREs, PC-style locking).

5.2. Additional or Extended Attributes

NFS does Versions 2 and 3 do not provide for file or directory attributes
beyond those that are found in the traditional Unix environment; for
example the user identifier of the owner identifier/owner of the file, a permission or access
bitmap, time stamps for modification time of the file or directory and

NFSv4 NFSv4 Requirements September 1998

file size to name a few. While the current set of attributes has
usually been sufficient, the file system's ability to manage
additional information associated with a file or directory can be
useful.

Editors Note: Need to add examples of

There are many possibilities for additional attributes in the use or potential
extended attributes.

Editors Note: Discussion next
version of extended attribute support in
other NFS. Some of these include: object creation timestamp,
user identifier of file's creator, timestamp of last backup or
archival bit, version number, file systems needs to be added.

5.3. Access Control Lists

One specific content type (MIME type),
existence of extended attribute can be the Access Control
List (ACL). data management involvement (i.e. DMAPI).

This attribute list is a designation representative of user access to a file
or directory. Many vendors have created ancillary protocols to NFS

NFSv4 Requirements September 1998

to extend the server's ACL mechanism across the network. Even though
the server still interprets the ACL possibilities and has final control over access
to a file system object, the client is able are meant to manipulate
show the ACL via
these need for an additional protocols.

DFS provides the ability to manipulate attribute set. Enumerating the ACLs
'correct' set of their file
servers. CIFS provides this capability as well.

Editors Note: Is the CIFS statement true in attributes is difficult and is one of the reasons
for looking towards minor versioning as a way to provide needed
extensibility. Another way to provide some extensibility is in
providing support for a generalized named attribute mechanism. This
mechanism would allow a client to name, store and retrieve arbitrary
data and have it associated as an attribute of a file or directory.
This type of extended attribute mechanism brings with it a large set
of issues that will need to be addressed in the protocol
specification while keeping the overall goal of simplicity in mind.

There are operating environments that provide named or extended
attribute mechanisms. Digital Unix provides for the storage of
extended attributes with some generalized format. HPFS and NTFS also
provide for named data associated with traditional 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 clear
direction that can be taken from these or other environments.

5.3. Access Control Lists

Access Control Lists (ACL) can be viewed as one specific type of
extended attribute. This attribute is a designation of user access
to a file or directory. Many vendors have created ancillary
protocols to NFS to extend the server's ACL mechanism across the
network. Generally this has been done for homogeneous operating
environments. Even though the server still interprets the ACL and has
final control over access to a file system object, the client is able
to manipulate the ACL via these additional protocols.

Other distributed file systems have also provided ACL support. DFS,
AFS and CIFS to name a few. Based on current capabilities, it seems
to be a requirement that NFS provide this case?
What capability as well but the
major issue is one of compatibility. It may be problematic to create
a workable ACL mechanism that will encompass a reasonable set of

NFSv4 NFSv4 Requirements September 1998

functionality for all operating environments.

The three major reasons behind providing ACL support are existing
distributed file system support, file servers not providing native
environment for user management of ACLs and perception of ACL support
as part of security requirement. Even with the complicated nature of
ACL support it is still worthwhile to work towards a solution that
can at least provide basic functionality for the mechanisms? user.

6. RPC Mechanism and Security

NFS relies on the underlying security mechanisms provided by the
ONCRPC protocol. Until the introduction of the ONCRPC RPCSEC_GSS
security flavor, NFS security was generally limited to none
(AUTH_SYS) or DES (AUTH_DH). The AUTH_DH security flavor was not
successful in providing readily available security for NFS because of
a lack of implementation and deployment. Also the 192 bit public
keys modulos used for the AUTH_DH security flavor quickly became too
small for reasonable security.

6.1. Remote Procedure Call Mechanism

The ONCRPC protocol provides the basic NFS foundation for the
following reasons:

o Open protocol definition managed by IETF

o Transport independent (UDP (i.e. UDP and TCP supported -- and others????) supported)

o Simple data representation and procedure encoding models

o Various security mechanisms available through use of RPCSEC_GSS

6.2. User identification

NFS has been limited to the use of the Unix centric user
identification mechanism of numeric user id based on the available
file system attributes and the use of the ONCRPC. However, for NFS

NFSv4 Requirements September 1998
to move beyond the limits of large work groups, user identification
should be string based and the definition of the user identifier
should allow for integration into an external naming service or
services.

NFSv4 NFSv4 Requirements September 1998

Internet scaling should also be considered for this as well. The
identification mechanism should take into account multiple naming
domains and other extremes that can be presented by use outside of
the work group.

Editors Note: Should identify what other distributed file
systems do for

If NFS is to move among various naming and if these approaches can help
solve security services, it may
be necessary to stay with a string based identification. This would
allow for servers and clients to translate between the issues above external
string representation to a local or are themselves limited. internal numeric (or other
identifier) which matches internal implementation needs.

DFS uses a string based naming scheme but translates the name to a
UUID (16 byte identifier) that is used for internal protocol
representations. The DCE/DFS string name is a combination of cell
(administrative domain) and user name. As mentioned, NFS clients and
servers map a Unix user name to a 32 bit user identifier that is then
used for ONCRPC and NFS protocol fields requiring the user
identifier.

6.3. Authentication Security

As a result of a lack of implementation and deployment and relatively
weak protection, authentication has been a major issue for ONCRPC and
hence NFS. With the introduction of the RPCSEC_GSS security flavor,
ONCRPC can provide for reasonable authentication along with integrity
and privacy, if desired. The RPCSEC_GSS framework will allow the use
of both public and private key mechanisms. Therefore, NFS as a user
of ONCRPC should state its specific requirements for each of these
areas.

In comparison, AFS and DFS provide strong authentication mechanisms.
CIFS does provide authentication at initial server contact but does
not continue this authentication during subsequent interaction.

6.3.1. Authentication

Strong authentication is a requirement for NFS and the logical
solution for this is in the use of ONCRPC the use of ONCRPC and RPCSEC_GSS. This
solution will allow for both private and public key mechanisms to be
employed if required. This flexibility will allow for security
usability in varying environments.

NFSv4 NFSv4 Requirements September 1998

6.3.2. Data Integrity

Since file and directory data is the essence of distributed file
service, the NFS protocol should provide to the users of the file
service a reasonable level of data integrity. The RPCSEC_GSS
mechanism provides a framework for data integrity and the security
mechanisms chosen for NFS should be implemented to provide data
integrity.

6.3.3. Data Privacy

Data privacy, while desirable, is not as important in all
environments as authentication and RPCSEC_GSS.

Editors Note: Beyond authentication, integrity. Data privacy should be
an available option within NFS make but not a requirement.

6.3.4. Security Mechanisms

With the use of the integrity RPCSEC_GSS framework, both public and privacy features of RPCSEC_GSS? This
could prove useful in the broader Internet environment.

Editors Note: What security private
mechanisms can and should be specified
or required provided by NFS? For NFS. The choice from both
public and private key mechanisms will allow for the appropriate
choice being made by the user based on factors within their
environment.

Potential choices for the private key, key mechanism would be Kerberos V5 can be
used. Are there other obvious suggestions? For
and for the public
key, key choice, SPKM [RFC2025] can be used. Are there other
suggestions for public key?

6.4. is available.

6.3.5. Security Negotiation

Along with

With both private and public key mechanisms available to the authentication requirements, end
user, the NFS server and client will need a method for client and
server to automatically negotiate an agreeable security mechanism
needs to be in place.
appropriate usage based on availability and policy. This will ease administration overhead negotiation
should account for authentication, integrity, and

NFSv4 Requirements September 1998

interoperability difficulties. privacy so that
administrators and users can employ the appropriate security policies
for their environments.

7. Internet Accessibility

Being a product of an IETF working group, the NFS protocol should not
only be built upon IETF technologies where possible but should also

NFSv4 NFSv4 Requirements September 1998

work well within the broader Internet environment.

7.1. Transports

ONCRPC Congestion Control and Transport Selection

As with any network protocol, congestion control is available a major issue and
the transport mechanisms that are chosen for NFS should take this
into account. Traditionally implementations of NFS have been
deployed using both UDP and TCP transports. NFS as a user
of ONCRPC has not placed any requirements on TCP. With the use of either UDP or
TCP. Today's NFS UDP, most
implementations generally support both transports.

At provide a minimum, NFS should require the support rudimentary attempt of both UDP and TCP at
the client and server. An alternative would be to require TCP only
for both client congestion control
with simple back-off algorithms and server.

However, it can round trip timers. While this
may be argued that some new sufficient in today's NFS deployments, as an Internet protocol
NFS will need to ensure sufficient congestion control or management.

With congestion control in mind, NFS protocol features could
rely on the must use of TCP and as a transport (via
ONCRPC). The UDP transport provides its connection state. own advantages in certain
circumstances. In today's NFS implementations, UDP has been shown to
produce greater throughput as compared to similarly configured
systems that use TCP. If this type of
transport dependency were built into NFS, UDP would is to be lost for some
environments supplied as an NFS transport
mechanism, then the low overhead and potentially better performing
alternative. issues of congestion control must be dealt with.

7.2. Firewalls and Proxy Servers

NFS's protocol design should allow its use via Internet firewalls.
The protocol should also allow for the use of file system proxy proxy/cache
servers. Proxy servers if possible (especially can be very useful for caching).

Editors Note: What potential issues exist scalability and other
reasons. The NFS protocol needs to address the need of proxy servers
in a way that will deal with the
combination issues of aggressive client caching security, access control,
and proxy caching?

Editors Note: Also what are content control. It is possible that these issues can be
addressed by documenting the security implications related issues of proxy server usage.
However, it is likely that the NFS protocol will need to support
proxy servers directly through the NFS protocol. In any case, the
NFS servers? proxy server should be considered during protocol development.

7.3. Multiple RPCs and Latency

As an application at the NFS client performs simple file system

NFSv4 Requirements September 1998
operations, multiple NFS operations or RPCs may be executed to
accomplish the work for the application. While the NFS version 3
protocol addressed some of this by returning file and directory
attributes for most procedures hence reducing follow up GETATTR
requests, there is still room for improvement. Reducing the number
of RPCs can lead to a reduction of processing overhead on the server
(transport and security processing) along with reducing the time

NFSv4 NFSv4 Requirements September 1998

spent at the client waiting for the server's individual responses.
This issue is more prominent in environments with higher larger degrees of
latency.

One approach to resolving this issue is by allowing

The CIFS file access protocol supports 'batched requests' that allow
multiple
individual operations requests to be combined batched and therefore reducing the number of
round trip messages between client and server.

This same approach can be used by NFS to allow the grouping of
multiple procedure calls together in a single RPC. This traditional RPC request. Not
only would reduce this allow for the reduction in protocol imposed latency
but would reduce transport and security processing overhead while
allowing for the use of simple protocol operations and could
allow a client to accomplish more complete tasks.

Note that CIFS provides a similar mechanism with its chaining. more complex tasks by combining
procedures.

8. File locking / recovery

NFS has provided Unix file locking and DOS SHARE capability with the
use of an ancillary protocol (Network Lock Manager / NLM). The NLM
protocol provides for file locking and recovery of those locks in the
event of client or server failure. NLM requires that the server make
call backs to the client for certain scenarios and therefore is not
necessarily well suited for Internet firewall traversal.

Desirable features of file locking support are:

o Integration with the NFS protocol

o Interoperability between operating environments (i.e.
traditional NFS, CIFS, DFS, Novell environments)

o Scalable solutions - thousands of clients

o Internet capable (firewall traversal, latency sensitive)

o Timely recovery in the event of client/server failure

Editors Note: Do these items need further definition? or cluster
fail-over.

DFS offers file locking but does not provide DOS SHARE
capability. DFS' relies on the server calling back to the
client for the file

NFSv4 Requirements September 1998 locking functionality.

CIFS supports file locking and DOS SHARE support.

NFSv4 NFSv4 Requirements September 1998

9. Internationalization

The current NFS protocols are limited in their support of anything
more than 7-bit ASCII strings. It is imperative that NFS support a
range of character sets. This can be provided by requiring support
for Unicode with a UTF-8 wire encoding. Therefore, all strings
defined as part of the NFS protocol will need to be defined as UTF-8
and the appropriate XDR encoding used.

NFSv4 NFSv4 Requirements September 1998

10. Bibliography

[RFC1094]
Sun Microsystems, Inc., "NFS: Network File System Protocol
Specification", RFC1094, March 1989.

ftp://ftp.isi.edu/in-notes/rfc1094.txt

[RFC1813]
Callaghan, B., Pawlowski, B., Staubach, P., "NFS Version 3 Protocol
Specification", RFC1813, Sun Microsystems, Inc., June 1995.

ftp://ftp.isi.edu/in-notes/rfc1813.txt

[RFC1831]
Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification
Version 2", RFC1831, Sun Microsystems, Inc., August 1995.

ftp://ftp.isi.edu/in-notes/rfc1831.txt

[RFC1832]
Srinivasan, R., "XDR: External Data Representation Standard",
RFC1832, Sun Microsystems, Inc., August 1995.

ftp://ftp.isi.edu/in-notes/rfc1832.txt

[RFC1833]
Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC1833,
Sun Microsystems, Inc., August 1995.

ftp://ftp.isi.edu/in-notes/rfc1833.txt

[RFC2025]
Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC2025,
Bell-Northern Research, October 1996.

ftp://ftp.isi.edu/in-notes/rfc2025.txt

[RFC2078]
Linn, J., "Generic Security Service Application Program Interface,
Version 2", RFC2078, OpenVision Technologies, January 1997.

NFSv4 NFSv4 Requirements September 1998

ftp://ftp.isi.edu/in-notes/rfc2078.txt

[RFC2203]
Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification"
RFC2203, Sun Microsystems, Inc., August 1995.

ftp://ftp.isi.edu/in-notes/rfc2203.txt

[Sandberg]
Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon, "Design
and Implementation of the Sun Network Filesystem," USENIX Conference
Proceedings, USENIX Association, Berkeley, CA, Summer 1985. The
basic paper describing the SunOS implementation of the NFS version 2
protocol, and discusses the goals, protocol specification and trade-
offs.

[X/OpenNFS]
X/Open Company, Ltd., X/Open CAE Specification: Protocols for X/Open
Internetworking: XNFS, X/Open Company, Ltd., Apex Plaza, Forbury
Road, Reading Berkshire, RG1 1AX, United Kingdom, 1991. This is an
indispensable reference for NFS version 2 protocol and accompanying
protocols, including the Lock Manager and the Portmapper.

[X/OpenPCNFS]
X/Open Company, Ltd., X/Open CAE Specification: Protocols for X/Open
Internetworking: (PC)NFS, Developer's Specification, X/Open Company,
Ltd., Apex Plaza, Forbury Road, Reading Berkshire, RG1 1AX, United
Kingdom, 1991. This is an indispensable reference for NFS version 2
protocol and accompanying protocols, including the Lock Manager and
the Portmapper.

NFSv4 NFSv4 Requirements September 1998

11. Author's Address

Address comments related to this memorandum to:

spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com

Spencer Shepler
Sun Microsystems, Inc.
7808 Moonflower Drive
Austin, Texas 78750

Phone: (512) 349-9376
E-mail: spencer.shepler@eng.sun.com