Current Meeting Report

2.7.10 Network File System Version 4 (nfsv4)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 15-Nov-01
Brent Callaghan <>
Brian Pawlowski <>
Transport Area Director(s):
Scott Bradner <>
Allison Mankin <>
Transport Area Advisor:
Scott Bradner <>
Mailing Lists:
To Subscribe:
Description of Working Group:
The objective of this working group is to advance the state of NFS technology by producing a specification for NFS version 4 which will be submitted as an Internet standards track RFC. The first phase of the working group activity will produce a requirements document describing the limitations and deficiencies of NFS version 3, potential solutions for addressing these, and a cost/benefit analysis of the different solutions. Input for the development of this document will include experiences with other distributed file systems such as DCE/DFS and Coda. Following the publication of this document, the charter of the working group will be reassessed; however, it is anticipated that NFS version 4 will emphasize the following core features:

o Improved access and good performance on the Internet.

The protocol will be designed to perform well where latency is high and bandwidth is low, to adapt to the presence of congestion, to scale to very large numbers of clients per server, and to transit firewalls easily.

o Strong security with negotiation built into the protocol.

The protocol may build on the work of the ONCRPC working group in supporting the RPCSEC_GSS protocol. The permission model needs to scale beyond the current flat integer UID space.

Additionally NFS version 4 will provide a mechanism to allow clients and servers to negotiate security and require clients and servers to support a minimal set of security schemes.

o Better cross-platform interoperability.

The protocol will feature a filesystem model that provides a useful, common set of features that does not unduly favor one filesystem or operating system over another.

o Designed for protocol extensions.

The protocol will be designed to accept standard extensions that do not compromise backward compatibility.

Goals and Milestones:
Done   Issue strawman Internet-Draft for v4
Done   Submit Initial Internet-Draft of requirements document
Done   Submit Final Internet-Draft of requirements document
Done   AD reassesses WG charter
Done   Submit v4 Internet-Draft sufficient to begin prototype implementations
Done   Begin Interoperability testing of prototype implementations
Done   Submit NFS version 4 to IESG for consideration as a Proposed Standard.
Done   Conduct final Interoperability tests
Done   Conduct full Interoperability tests for all NFSv4 features
Jul 01   Submit RPC (RFC 1831), Binding Protocols for RPC (RFC 1833), and RFCSEC_GSS Protocol Specification (RFC 2203) to IESG for advancement to Draft Standard
Aug 01   Submit NFS version 4 to IESG with changes reflecting results of Interoperability tests for recycling as Proposed Standard
Feb 02   Submit NFS version 4 to IESG for consideration as a Draft Standard.
Request For Comments:
RFC2623PSNFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5
RFC2624 NFS Version 4 Design Considerations
RFC3010PSNFS version 4

Current Meeting Report

NFSv4 Working Group Meeting @ 52nd IETF, Salt Lake City

Reported by Brent Callaghan

Co-chair, Brent Callaghan, presented the meeting agenda and introduced Rob Thurlow as first speaker. Rob made a case for file Replication and Migration work to be included in the NFSv4 working group re-charter. He began with a quote from Brian Pawlowski: "NFS version 4 is incomplete without this." Distributed filesystems like AFS and DCE/DFS have provided replication and migration services, but NFS doesn't. He argued that this work is appropriate for the NFSv4 working group because can more easily be designed to serve the needs of NFS version 4, handle some of the details of NFSv4 (e.g. its file attributes) and can be designed to support the NFSv4 consistency and correctness requirements.

Brian Carpenter questioned the interest in this work given the low turnout at the WG meeting. Brian Pawlowski pointed out that the meeting did not represent those on the mailing list, and suggested that Rob solicit mailing list participants to help with replication/migration work. Brian Carpenter asked about support in the NFSv4 protocol to handle a replication/migration event, e.g. what happens to filehandles? Brian Pawlowski responded that this support has already been designed into the protocol.

Document editor, Spencer Shepler, then stood up and gave a quick summary of the October "bakeoff" event, where several implementations of NFS v4 were tested for interoperability. A lot of progress was made with the new open state model and few new protocol issues were raised. New protocol features tested were named attributes and delegation. Also mentioned was an NFSv4 client written in Python that is suitable for use as a client test harness.

Spencer then gave an overview of the 160 items on the list of issues with RFC 3010. The list of updates can be seen at . Most of the issues are minor tweaks to the protocol or its documentation and are well understood. There are some issues on the list that are still being worked:

- Some further clarifications (minor modifications) to the open/locking state model.

- Open upgrade/downgrade paths. Windows file open deny modes conflict with UNIX.

- Special stateid usage by UNIX clients.

- File locking conflict at file open time between Windows and UNIX clients.

- Support of security mechanisms in pseudo filesystems.

- Addition of WINDOWS semantics for file removal on CLOSE. Previous behavior was to rename the file to .nfsxxxx.

- Need to handle recovery of partial state "loss". For instance, loss of state on a single file. Also need to handle removal of state, e.g. stuck client holding open a lock.

- Require clarification on Various delegation scenarios. For instance, if a client mounts the same filesystem twice, will delegations "thrash" ? This is not a protocol issue, but it needs to be documented. We also need to clarify and contrast the return of delegation via CLOSE and DELEGRETURN operations.

- Need additional clarification on the validation of UTF-8 strings.

Scott Bradner suggested that we look at the work of the Internationalized Domain Names group (IDN) in canonicalizing UTF-8 strings for the purpose of comparison. Spencer hopes to have all the changes integrated with the draft spec by the end of January to form a stable base for interoperability testing at Connectathon in March.

Brian Pawlowski reviewed the work items ahead for the working group, starting with completion of revisions to rfc3010 and closing of all open issues, followed by a verification of interoperability (suitable for Draft submission) at Connectathon. NFSv4 is still waiting on advancement of RPC RFC's and GSS-dependent drafts, and a new set of milestones for advancement of the spec. Scott mentioned that the IESG is struggling with the notion of interoperability when applied to an API, such as GSS-API. Scott suggested that a short RFC is needed that describes how the IESG will evaluate API interoperability. Brian indicated that a new draft charter has been submitted to the IESG based on feedback from the Transport Area Directors. An additional issue is whether this group should exploit RDMA work for NFS and RPC. Scott added that the ROI BOF (RDMA over the Internet) was evenly split between forming a working group and having another BOF, but he was confident that a working group would eventually be formed.

The meeting concluded at 5:00pm.

The slides from the meeting can be viewed at:


Open Discussion (well, transmission)