18 November 2002 NFSv4 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 suggested. 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 clarifications. 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@sunroof.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.