NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Brent Callaghan <brent@eng.sun.com>
Brian Pawlowski <beepy@netapp.com>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Allison Mankin <mankin@isi.edu>
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
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.
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. |
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 |
NFSv4 Working Group Meeting @ 51st IETF, London
-----------------------------------------------
Reported by Brent Callaghan
After welcoming the participants and presenting the meeting agenda, Brent Callaghan gave an update on the status of the RPC standards that NFSv4 depends upon. Currently, RFC 1832 (XDR) is at Draft and RFC's 1831 (RPC), 1833 (Binding) and 2203 (RPCSEC_GSS) are all at Proposed. RFC 1831 is pending the addition of an "IANA Considerations" (RFC 2434) section for administration of the program number space. RFC 2203 (RPCSEC_GSS) still awaits movement of the GSS-API standard (RFC 2743) to Draft.
Document editor, Spencer Shepler, described the "bakeoff" at the University of Michigan/CITI as a success. The protocol was tested between 5 implementations and no major issues were found. He then went on to describe some updates to the protocol state model, beginning with an pictorial explanation of the NFSv4 state hierarchy and its relationship to various threading models (see slides). The state hierarchy begins with the clientID which is established by the client with a SETCLIENTID call and confirmed by the server. Associated with the clientID is a lockowner, which corresponds to the PID on a POSIX client. The server has a stateid which changes after any change in status of file locking or file open. File delegation has its own delegation-stateid.
One problem with the file open state has come to light as the result of implementation experience. When a UNIX process forks, the parent and child processes share a file descriptor to the open file. This condition is not accurately reflected by the file open state on the server. A proposed solution is to add another level of indirection via an entity called a "openowner" that can represent multiple processes on a client. Spencer plans to incorporate the openowner into the pending updates to the spec if the WG approves. From feedback at the bakeoff, the implementors support this proposal.
Brian Pawlowski summarized the proposal for working group re-charter to include on-going NFSv4 work for test suite development, a management MIB, and a Replication and Migration protocol. Brian agreed to submit the Re-charter text to the Area Directors who will have the IESG consider it.
Brian summarized the aims of the replication and migration work: Transparent, client failover for read-only replicas, good performance across low bandwidth links, and security as good as v4. He will work with Rob Thurlow to draft a requirements document and publish it as an individual submission Internet-Draft pending re-chartering the work group and since the requirements described in this document may not be specific to NFSv4, it will be circulated to other groups for comment.
The meeting concluded at 5:00pm.
-------------------------------
The slides from the meeting can be viewed at:
http://playground.sun.com/pub/nfsv4/presentations/ietf51
------------------------