2.8.10 Network File System Version 4 (nfsv4)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

Chair(s):

Brent Callaghan <brent@eng.sun.com>
Brian Pawlowski <beepy@netapp.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>

Transport Area Advisor:

Allison Mankin <mankin@east.isi.edu>

Mailing Lists:

General Discussion:nfsv4-wg@sunroof.eng.sun.com
To Subscribe: nfsv4-wg-request@sunroof.eng.sun.com
Archive: http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive

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

Oct 99

  

Begin Interoperability testing of prototype implementations

Done

  

Submit NFS version 4 to IESG for consideration as a Proposed Standard.

Done

  

Conduct final Interoperability tests

Mar 01

  

Conduct full Interoperability tests for all NFSv4 features

Apr 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

Apr 01

  

Submit NFS version 4 to IESG with changes reflecting results of Interoperability tests for recycling as Proposed Standard

Nov 01

  

Submit NFS version 4 to IESG for consideration as a Draft Standard.

Internet-Drafts:
Request For Comments:

RFC

Status

Title

RFC2623

PS

NFS 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

RFC3010

PS

NFS version 4

Current Meeting Report

NFSv4 Working Group Meeting @ 50th IETF, Minneapolis
----------------------------------------------------

Reported by Brent Callaghan

After welcoming the participants and presenting the meeting agenda, Brent Callaghan gave a short presentation on the status of the RPC standards it inherited from the ONCRPC working group. Currently, RFC 1832 (XDR) is at Draft and RFC's 1831 (RPC), 1833 (Binding) and 2203 (RPCSEC_GSS) are all at Proposed. It seems there are no issues that prevent XDR from being advanced to Internet Standard. RFC's 1831 and 1832 require the addition of an "IANA Considerations" (RFC 2434) section for administration of the program number space. RFC 2203 (RPCSEC_GSS) has demonstrated interoperability but cannot advance until the GSS-API RFC's are advanced. Area Director, Allison Mankin, said she would try to expedite the movement of those RFCs.

Document editor, Spencer Shepler, is preparing to make updates to the NFSv4 protocol spec, RFC 3010. The updates comprise semantic clarifications and minor RPC changes that arose from testing at the October bakeoff and Connectathon 2001. He presented a list of the changes under consideration and asked for a list cutoff of May 1st.

Clarifications:
Response count for COMPOUND
Lease and deadlocks
CREATE/MKDIR/OPEN errors
Issues with locking length of all ones
Byte ranges with 32-bit systems
Delegation recall at RENAME
Initial sequence id
Overlapping and other weird byte ranges
SETATTR response attribute mask
OPEN upgrade and share conflicts
Stateid returned on CLOSE
Only one outstanding sequid-containing request at a time
Unlimited-length opaques
Get a seqid using OPEN
RPC description changes
Multi-component pathname issues
Server references delegations by FH, not stateid
Remove tag from compound request/response
OPEN and CREATE returning bitmap of attributes
Other issues
Attributes needed on create
NT server issues with OPEN upgrade
Lease/stateid/sequence-id

Issues that arise from these updates will be tackled one at a time on the mailing list. Work on the "NFSv4 Implementation" Internet-Draft is pending completion of the updates to RFC 3010. Sandeep Joshi asked about the error returned to an application when a lock is lost, e.g. if the lease expires. David Robinson mentioned that some UNIX systems have a SIGLOST signal. Allison asked whether the I18N section of the spec would be reviewed. Spencer said he'd look into it.

Venkat Rangan discussed his proposal for an NFSv4 MIB. The current draft (draft-rangan-nfsv4-mib-00.txt) provides some counters for NFSv4 protocol operations and errors. It describes three objects: the server, filesystems and locks. Feedback from the mailing list indicated an interest in extending the MIB to cover NFS versions 2 and 3 for both client and server. It was suggested that the RPC layer would be best handled as a separate MIB. There was also interest in determining protocol transaction time and usage history. Venkat will include a new object model in the next draft as well as conformance statements.

Mark Wittle expanded on a proposal for minor version features that he posted to the mailing list earlier in the week. He said the context for these proposals was the "in room" network, where NFS is the primary means for application servers to access storage. He would like to see some of the features available to "local" filesystems be accessible through NFS. These include atomic appends to a file, List I/O, Madvise-like hints for Cache Control and Persistent Locks. He suggested that "exactly once" semantics would simplify the protocol. Although app developers currently use lock files, h recommended explicit support in the protocol for persistent locks. On caching control, he indicated that many operating systems already support caching assertions.

Brian Pawlowski then took the floor to explain his proposal to re-charter the working group. The major work item of the original charter, development of the v4 protocol, is now winding down. The working group is encountering follow-on activities that require the re-charter: minor version proposals, MIB work, and replication and migration support. Brian conducted a loose poll on these items. There was much enthusiasm for an NFS MIB, but lukewarm support for minor version features. Ran Atkinson voiced concern at the level of complexity in NFSv4 and the additional complexity of minor versions. He is worried about the "micro-optimizations" proposed for the minor version, what bugs they will introduce and how well the extensions will work over a wide-area network. He suggested that some of the minor version proposals would be more appropriate for a separate protocol that deals with distributed databases. On Replication and Migration, Brent proposed that it work for NFS versions 2 and 3 as well. Another suggestion from the floor was that the NDMP protocol might provide provide a framework for Replication and Migration. Brian said he'd consider it.

The meeting concluded at 5:10pm.

The slides from the meeting can be viewed at:

http://playground.sun.com/pub/nfsv4/presentations/ietf50

Slides

Agenda
NFSv4 RFC Status
NFS MIB
Recharter