Current Meeting Report
Slides
2.7.10 Network File System Version 4 (nfsv4)
NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It
may now be out-of-date. Last Modified:
27-Feb-02
Chair(s):
Rob Thurlow <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
Network File System Version 4 (nfsv4)
-------------------------------------
Chair(s):
Robert Thurlow <Robert.Thurlow@eng.sun.com>
Brian Pawlowski <beepy@netapp.com>
Document Editor:
Spencer Shepler <shepler@eng.sun.com>
AGENDA: Wednesday March 20th: 13:00pm - 15:00 (2 hours)
Welcome and Introduction (Pawlowski) 5 min
Agenda bash
- BLUE SHEETS
- NOTE WELL
Introduced Rob T, new co-chair, replacing Brent Callaghan.
beepy agenda bashed - no changes.
Schedule and milestones (Pawlowski) 5 min
- Charter
Presented changes to charter and new milestones. Mentioned in passing the ROI BoF that may affect us (we might be a customer for using their output) - slight discussion on that. Covered milestones, mentioned migration/replication is V4 targetted.
Newest item - API advancement - GSSAPI needs to advance, need a way to evaluate. Repl-Mig part of work going forward, completion of work in the environment - Rob Thurlow will spearhead - checkpoint with AD in July. Will also deal with minor revisions. Need to work other specs also.
Connectathon results (Shepler) 5 min
- Linux NFS Version 4 posting
- Kerberized V2/V3 fallout
- Next testing event target July
- Most issues resolved
Shepler talked about Connectathon testing two weeks ago.
Finished Mar 8. Linux, NetApp, Sun, EMC, Hummingbird, python test client, nfsv4shell there, lots accomplished. Nice RPCSEC_GSS testing w/v[234] - 4 platforms! Got RPCSEC_GSS Linux diffs together with a plan to get it into the next development kernel. SPKM/LIPKEY work in good shape for Linux at CITI; another implementer has come to light also, which is cool. No new issues there, focusing on details. Delegation progress good now, some testing done with Sun and Linux. Named attributes good progress also.
Interesting addition to implementers was Peter Astrand's Python-based NFS Version 4 tester. See archives or
http://www.cthon.org/talks02/index.html
Fallout of requirement to security in NFS V4 has resulted in most implementers coming out with GSSAPI and Kerberos. The security is being back ported to NFS Version 2 and 3. Stuff will come out.
UMich (see http://www.citi.umich.edu) has posted a snapshot of their Linux NFS Version 4 work. They have a rough SPKM3/LIPKEY under GSSAPI solution also - and a second group (Ron Hoffman) has emerged working on the SPKM3/LIPKEY implementation. Good news in moving RFCs forward (by providing to independent implementations).
Closure of specification updates (Shepler) 25 min
No new issues emerged from Connectathon. Some clarifications, but no changes. Delegation testing and recovery was played with at Connectathon. Minor changes to help migration/replication. Through implementation issues of named attirbutes.
One week testing proposed for July. Spencer expects one or two new groups with new NFS Version 4 implementations to participate.
Spencer is targetting week of March 25 for submit of new draft. Working group last call to happen in April. Detailed issues list and resolution covering changes to RFC 3010 to simplify review.
Issues are filehandle types, stateids, OPEN upgrade/downgrade. Anything controversial? Violation of protection semantics? Specification wording to explain what server allows (to restrict behaviour). Interpretation of FH types related to repl-mig, delegation ops need a change to include FH as well as stateid, identification of server's file locking type, special stateids. OPEN upgrade/downgrade path probably biggest now.
Working draft and issues list at http://www.nfsv4.org/rfc3010updates.
Migration/replication next steps (Thurlow) 25 min
Rob Thurlow (new co-chair) covered progress on migration/replication. See slides. Con call alerts will be posted to the alias. beepy to talk to rserpool (Maureen) on coordination and notice of con calls. Rob summarized the requirements generated by the WG and off line work. To be transformed into an internet draft for AD review. Described thoughts on protocol. Restartability thought important (vs. journaling). Mark Wittle asked about four areas of focus on the migration/replication.
beepy clarified a question that no admin changes expected if someone decides not to deploy migration/replication in their environment.
Rob responded that NFS V4 core protocol is probably not sufficient to support the back end protocol. The question is: what is the back end protocol? Requirements to drive understanding whether any existing protocol can serve.
Have any bulk data movement options been ruled out? Sort of; proposal will go for new protocol with a particular structure. FTP not there, NFSv4 not quite enough. Control protocol seems like it would be NDMP - will you work with them? Yes, when the NDMP folks are a working group, we can talk to them.
Review of work items (Shepler/Pawlowski) 20 min
- API GSSAPI advancement
- MIB draft
- RPC/XDR/RPCSEC_GSS RFC plans
- ACL
API advancement drafts - Scott Bradner described the rationale of what two API implementations. Related to MIB advancement. Scott further clarified that some may or may not go standards track in the IETF.
http://search.ietf.org/internet-drafts/draft-pawlowski-apitest-00.txt
Shepler talked to RPC advancement - Sun owns.
API advancement draft, in process, working with AD. Had a MIB awhile ago, more than the six month timeout, we will refresh. Other RFCs: XDR a draft standard now. RPC: still need to recast registration to IANA and update RFC info on this, but this is not too bad. SPKM/LIPKEY - we will help, but not own. Might see: ACL mapping work, NFSv4 global namespace. Highest priority has been resubmission of RFC 3010.
Open discussion (Pawlowski) 30 min
Early end.
Wrapup (Pawlowski) 5 min
Priority is RFC 3010 resubmission with updates.
Slides
NFSv4 & Connectathon
Things
NFSv4 Replication and Migration