Last Modifield: 05/07/2002
o NFS version 4
Advance the protocol along the standards track, coordinating the development of test suites to provide a high level of implementation quality. The ONC RPC standards that NFSv4 references must also be advanced. This includes work to make NFSv4 and the underlying ONC RPC protocol compatible with IPv6. Specifically, we will advance RFC 3010, RFC 1831, RFC 1833 and RFC 2203 to Draft Standard. The working group will help advance related security RFCs, specifically through the definition of a method to advance APIs.
o Replication and Migration
The original working group defined a mechanism for NFS clients and servers to support replication and migration of data transparently to an application. Left undefined in the initial work was the server back end migration and replication mechanism. The working group will produce a draft submission of a replication/migration protocol that supports NFS Version 4 clients - needed to create and maintain replicated filesystems as well as migrating filesystems from one location to another - and servers for consideration as Proposed Standard.
The working group will produce a draft submission for consideration as Proposed Standard of a management MIBs to provide better management and administration capabilities for NFS and ONC RPC.
o Minor Versions
NFS Version 4 contains within it the capability for minor versioning. Some discussions within the working group suggest addressing additional requirements over the original charter. The WG will work to identify additional requirements for NFSv4 and determine if they are appropriate and worthwhile for a minor version. This work may lead to proposals for additional work items. If it does a specific proposal to add these work items to the charter will be forwarded to the IESG and IAB.
|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|
|MAR 02||Update API advancement draft|
|APR 02||Form core design team to work on NFS V4 migration/replication requirements and protocol|
|APR 02||Submit revised NFS Version 4 specification (revision to RFC 3010) to IESG for consideration as a Proposed Standard|
|MAY 02||ADs to submit API advancement internet draft as informational RFC (needed to advance GSSAPI to Draft Standard to allow advancement of NFS Version 4)|
|MAY 02||Internet draft on NFS V4 migration/replication requirements|
|MAY 02||AD review of NFS V4 migration/replication requirements draft|
|MAY 02||Revision of internet draft on NFS MIB|
|JUN 02||Creation of internet draft on ONC RPC MIB|
|JUN 02||Depending on results of AD review of NFS Version 4 migration/replication requirements document, review scope of task|
|JUL 02||Strawman NFS V4 replication/migration protocol proposal submitted as an ID|
|JUL 02||Continued interoperability testing of NFS Version 4|
|OCT 02||Submit an NFS V4 migration/replication protocol to IESG for consideration as a Proposed Standard|
|OCT 02||Submit ONC RPC and NFS MIBs to IESG for consideration as Proposed Standards|
|NOV 02||Submit related Proposed Standards required by NFS Version 4 for consideration as Draft Standards to IESG - RFCs 1831, 1833, 2203, 2078, 2744, RFC 1964, & 2847|
|NOV 02||Document full Interoperability tests for all NFSv4 features|
|NOV 02||Interoperability tests of NFS V4 migration/replication|
|DEC 02||Submit report on results of interoperability testing|
|FEB 03||Submit revised NFS Version 4 Proposed Standard for consideration as Draft Standard to IESG|
|RFC2623||PS||NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5|
|RFC2624||I||NFS Version 4 Design Considerations|
|RFC3010||PS||NFS version 4|
18 November 2002NFSv4 WG meeting Atlanta The agenda was: Monday November 18: 19:30pm - 22:00 (2.5 hours) Welcome and Introduction (Pawlowski) 5 min Agenda bash etc. - BLUE SHEETS - NOTE WELL - Status of drafts Bakeathon results and issues (Shepler) 10 min Final RFC 3010 resubmission status (Shepler) 10 min Migration/replication (Thurlow) 25 min NFS and ROI work (Pawlowski) 10 min Review of work items (Shepler/Pawlowski) 15 min - API GSSAPI advancement - MIB draft resurrection - RPC/XDR/RPCSEC_GSS RFC plans Open discussion (Pawlowski) 10 m Wrapup (Pawlowski) 5 m Brian Pawlowski started with a welcome to the NFSv4 WG intro and went over the posted agenda and asked for any additional items; none were suggeste d. Spencer Shepler presented results of interoperability testing at the Bakeathon held in October. No protocol problems found. Six implementations. Five implementations had Kerberos implemented. UofM group got base NFS Version 4 kernel including security integrated into the Linux 2.5 development kernel. Testing of recovery proceeded - Connectathon tests done during reboots of the server. See some interesting presentations on NFS Version 4: http://www.nfsconf.com/pres02/index.html Tom Talpey asks why is it not a Bakeoff (go to bakeoff.com to find out). Spencer Shepler then covered the RFC 3010 (NFS Version 4 Protocol Specification) resubmission status. Completed WG Last call, IETF last call, IESG approved gave to RFC Editor. IANA will review in process - they did a pre-review. Next month or so we will here any IANA last requests for cl arifications. Spencer Shepler then covered replication/migration - standing in for for Rob Thurlow. As V4 core protocol wrapped up people seem to be focusing more on the new work. Interested: Sun, IBM, NetApp, UofM. Replication/migration requirements doc required by December - Pawlowski has slipped. Thurlow would like to play with prototype implementations in Connectathon in March. See slides and Thurlow's draft for proposed protocol to test. Bring issues to the WG mail list (nfsv4-wg@sunr oof.eng.sun.com). Shepler thinks the back-end migration/replication protocol will be much simpler than the core V4 protocol. Open issues: security, compression/data reduction. There is interest in low bandwidth links. And - minor version requirements of core protocol in support of migration/replication - Dvae Noveck wondered aloud if we would have to tweak something in the core protocol. Two other big pieces are management and location of replicas. The location of replicas triggered another possible work item from Dave Noveck - that of global name space construction and management. The same facility in V4 as it stands to allow finding file systems that have migrated (or are replicated) oculd be part of the solution for construction of a "global name space" (AFS-lite). Need a problem statement - this needs to be an internet-draft. Describing the global name space stuff and what are the issues it is trying to address. (Would need extension to the charter per the Minor Versions item now there). Brian discussed the idea of adding a work item for the NFSv4 WG of NFS/RDDP related issues or protocol changes. This has been touched on at a prior IETF meeting and on the alias. This type of work fits well within the NFSv4 WG because of its ownership of the RPC and NFSv4 protocols and relates well to the RDDP (remote direct data placement) WG efforts. Brian suggests that a subgroup be formed to focus on this area at first understanding the requirements. Need to also understand the SNIA NFS/RDMA work and will look to Sun for help in understanding that work and how it would transfer or relate to this suggested effort. Brian suggests that this work would fall under minor versioning work and therefore is included in the current charter. However, the AD (Scott Bradner) asked that a proposed WG charter change be made as a first result of this effort. Brian owns an action item to formalize the overall proposal and discuss via the WG, etc. With the goal of eventually moving the NFSv4 protocol to Draft standard, the normative references must also be at Draft standard. This isn't an issue except for the GSSAPI reference because it is an API and not a protocol. Therefore, Brian has a submitted a personal draft that describes how an RFC that describes an API would be moved forward the IETF standards process. At this point, Mike Eisler pointed out that GSSAPI really does represent a network protocol and not an API (even though there are separate RFCs that deal with C and Java language bindings for GSSAPI). Scott Bradner stated that there has been an issue in the past within the IESG about moving the GSSAPI RFC forward. Mike volunteered to assist in clarifying the issues so that the GSSAPI specification can be moved to Draft status. It was noted that the NFSv4 protocol does not rely on the language bindings for GSSAPI. The next topic briefly covered the SNMP MIB resurrection. Again, a sub-group should be formed to resubmit the expired personal draft that existed in the past. Again, Brian owns an action to send email to the WG to start this work. The RPC/XDR/Security RFCs that are normative references must be updates for appropriate IANA sections. It was noted that RFC2203 (RPCSEC_GSS protocol specification) is dependent on the GSSAPI issue notes above. This will be an additional work item. During the open discussion, there were comments about minor revision suggestions. Dave Noveck mentioned that since file delegation support was present in the NFSv4 protocol that it seemed appropriate to consider adding support for the delegation of directories. There seems to be interest and use for such a mechanism. Dave also suggested that it may be useful to enable the client to reestablish a delegation after recall and that this may also be a reasonable minor version item. It was also suggested that providing this type of functionality may enable the ability to support NFSv4 proxy caching. Brian clarified with Scott Bradner if this type of work fell within the current NFSv4 WG charter (since it covers minor version work) and Scott responded in the affirmative. Dave stated that since the necessary changes for this type of delegation should be straightforward that once the requirements are in place that it should be simple to test this type of functionality in a bakeathon environment As mentioned before, Brian would like to pursue moving the NFSv4 protocol from Proposed to Draft. Since this work can be significant, Brian wanted to clarify that this was a reasonable thing for the WG to pursue. (implementation reports, etc.) Tom Talpey asked if Connectathon 2003 will be used as a benchmark for the move of NFSv4 to Draft and the answer was "no". 6 month minimum is required to move from Proposed to Draft and since there are still interesting features that have yet to be implemented that it will be longer than that.