NFSv4 Working Group Meeting @ IETF 47, Adelaide ----------------------------------------------- Reported by Brent Callaghan The NFSv4 working group met in two sessions. The first on Monday evening for 2 1/2 hours and the second on Tuesday night for 1 hour. The meetings were attended by 20 people. WG co-chair, Brent Callaghan, welcomed the attendees and introduced the first speaker, document editor, Spencer Shepler. Spencer gave a quick summary of the changes that went into draft 06. He added some new compound operations: OPEN_CONFIRM, SETCLIENTID_CONFIRM, and OPEN_DOWNGRADE, and clarified the text of the RENEW operation. The document is currently pending IESG review and more minor updates are expected following this review. Spencer then went on to describe some of the contents of an Implementation Choices RFC. The intent of this RFC is to describe implementation detail specific to operating systems such as UNIX. This level of detail would be innapropriate in the protocol spec. Spencer suggested the following items be included: - Suggestions for persistent and volatile filehandle content. - How to support Internationalized text strings on filesystems that support single-byte encodings. - Discussions of client and server state management. - Options for converting between owner/group identities and protocol string representation. - Issues with allowing local access to an exported filesystem on a server (having NFS detect access to delegated files). - Managing missing attributes, solutions for file migration and replication. - Translating Access Control Lists from one representation to another. - Mapping locking and lease semantics across heterogeneous servers. Brent summarized the results of the NFS v4 testing at Connectathon. As with the previous bakeoff in October, there were six servers and 4 clients from 5 vendors. The Solaris snoop sniffer with extensions to handle NFSv4 decodes was used as well as a new Tcl-based testing client. In addition to testing some of the simpler ops (putrootfh, getfh, lookup, getattr) there was some testing of more complex v4 ops (open, create, rpcsec_gss security). Bev Crair of Sun announced the availability of TI-RPC source from Sun under the new Sun Industry Standards Source License (SISSL) - downloadable from http://soldc.sun.com . This source contains an implementation of the GSS-API (rfc2078) and RPCSEC_GSS (rfc2203) along with updated RPC and XDR source code. Sun also makes binaries of its NFS v4 prototypes available under an evaluation license (contact dana.barsan@eng.sun.com). The NFSv4 Tcl testing client, nfsv4shell, will be made available in source form mid-April. Sun also continues to license its ONC+ source to ONC+ licensees. The ONC+ license may provide early access to NFS v4 product source. Co-chair, Brian Pawlowski lead an interactive discussion through the remainder of the session and the 1 hour session on Tuesday night. Costas Sapuntzakis asked whether there was still interest in adding protocol support for hardware decode of NFSv4 requests. In a previous post to the list he suggested the addition of byte counts fields that would allow ops containing large chunks of data to be located quickly with a minimum of protocol parsing. The consensus seemed to favor leaving the protocol alone - with a contention that smart enough hardware could parse without the additional fields. Neil Brown asked how key exchange would be handled by LIPKEY in the reverse direction when the server makes a callback (section 3.4 in the spec). Mike Eisler suggested that the server might return a public key to the client (Mike subsequently followed up with an additional proposal on the list). There was some discussion on the properties of the changeid attribute: whether it should increase or decrease. Consensus seemed to be that the value should increase (acknowledging wraparound for overflow). Brian wound up the discussion by soliciting proposals for further work that the WG could undertake: - Proxying support The protocol is not currently proxyable. - Implementation Choices document As described in Spencer's presentation. - Migration/replication protocols The NFSv4 protocol does not describe protocols for back-end migration of file data or replica management. - Global naming There is no global namespace described for NFSv4. Possibilities include automounter-style naming (/net/server), NFS URLs, or AFS-style global namespaces. - Hardware acceleration Opportunities for accelerating protocol processing with hardware. - Minor versioning Development of a minor version of the protocol that includes some of the above features. ------------------------ The slides from the meeting can be viewed at: http://playground.sun.com/pub/nfsv4/presentations/ietf47 ------------------------