Current Meeting Report
Slides
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
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@isi.edu>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion:nfsv4-wg@sunroof.eng.sun.com
To Subscribe: majordomo@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 |
| 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. |
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 @ 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 http://www.nfsv4.org/rfc3010updates . 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:
http://playground.sun.com/pub/nfsv4/presentations/ietf52
Slides
Agenda
rfc3010bis
Open Discussion (well, transmission)