Network File System (NFS) Version 4 Protocol
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, nfsv4 mailing list <firstname.lastname@example.org>, nfsv4 chair <email@example.com> Subject: Protocol Action: 'Network File System (NFS) Version 4 Protocol' to Proposed Standard (draft-ietf-nfsv4-rfc3530bis-35.txt) The IESG has approved the following document: - 'Network File System (NFS) Version 4 Protocol' (draft-ietf-nfsv4-rfc3530bis-35.txt) as Proposed Standard This document is the product of the Network File System Version 4 Working Group. The IESG contact persons are Martin Stiemerling and Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530bis/
Technical Summary The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document, together with the companion XDR description document, RFCNFSv4XDR, replaces RFC 3530 as the definition of the NFS version 4 protocol. This document includes updates that address: reported errata, clarifications related to implementation experience, and expanded text included from other sources. Working Group Summary These documents have been very non-controversial given the nature of the included errata and the fact that most of the document updates were drawn from the NFSv4.1 definition. Document Quality The quality of this document is very high. There are multiple implementations of the mandatory features of the protocol and at least one implementation covering most (if not all) optional features. The reason for doing the update was to raise the overall quality through expanded explanatory text and correcting ambiguities. Personnel Document Shepherd is Spencer Shepler (firstname.lastname@example.org). Responsible Area Director is Martin Stiemerling (email@example.com) RFC Editor Note Please publish draft-ietf-nfsv4-rfc3530bis-dot-x-24 and this draft (draft-ietf-nfsv4-rfc3530bis-35) together with subsequent RFC numbers.