NFSv4 Working Group Meetings @ 43rd IETF Orlando ------------------------------------------------ Reported by Brent Callaghan First Session (Mon Dec 7th 9:00 - 10:00am) Both sessions were attended by 35 people (according to the blue sheet). WG co-chair, Brent Callaghan, welcomed the participants and outlined the agenda for both sessions. He then presented an overview of the NFS version 4 server namespace proposal. NFS version 2 and 3 servers export independent pieces of their namespace and do not allow NFS clients to cross mountpoints on the server. Clients that need to browse the server's namespace must currently obtain a static snapshot of the server's namespace using the EXPORT procedure of the mount protocol and attempt to replicate the exported namespace in mirror image on the client. NFS v4 servers can be made browsable by connecting exported sub-trees of the namespace with a pseudo filesystem and allowing clients to cross server mountpoints. Brian Pawlowski mentioned that client crossing of server mountpoints might be something that a server administrator might need to control. Brent agreed, pointing out that this is an implementation detail. Document editor, Spencer Shepler, followed with an overview of the NFS version 4 Requirements document that he first presented in preliminary draft at the Chicago meeting. The current draft is assumed to be final (last call has expired) and it has been submitted to the IESG for review. Based on this review, a final version of the Requirements document will be issued as an RFC and the Working Group Charter will be amended if necessary. The topics covered in the document are: - Ease of Implementation - Reliable and Available - Scalable Performance - Interoperability - RPC and Security - Internet Accessibility - File Locking - Internationalization The draft submitted to the IESG can be viewed at: http://www.ietf.org/internet-drafts/ draft-ietf-nfsv4-requirements-03.txt Rob Thurlow gave the final presentation of the session on the NFS Version 4 Attributes. The proposed attribute model allows clients to retrieve attributes individually and allows servers to support a subset of the standard set of attributes. A topic of concern is whether some attributes should be declared "mandatory" while others are "recommended". Some mandatory attributes may make some client implementations easier - but may cause problems if some servers cannot support some of the mandatory attributes. Rob also described a set of "extended" attributes that could be assigned text names and opened like files. An OPENATTR operation would make these attribute files accessible. There was some discussion of support for an ACL protocol. Brent pointed out that there are several styles of ACL: POSIX draft, DCE, and Microsoft NT. There seems to be consensus that support for an ACL attribute would be welcomed, but building an interoperable model will be a challenge. At question time, Dan Trufasiu of HCL expressed concern that interoperability would suffer if clients and servers implemented non-overlapping subsets of the attributes. Brent suggested that some stronger language might be necessary in the spec to promote implementation of all attributes. Second Session (Mon Dec 7th 10:15 - 11:15am) WG co-chair, Brian Pawlowski, introduced the second session and proceeded with a presentation on client and server failover issues for NFS version 4. He began with a survey of existing examples of distributed filesystem replication and failover: the Andrew Filesystem (AFS) supports failover to replicas that can be lazy-updated from a single writeable volume and Solaris NFS provides client-side failover for read-only replicas. As requirements for NFS v4, Brian suggested that it should provide better support for read-only replication, and support transparent migration of volumes from one server to another. He proposed that clients should be able to elicit alternative replica locations when mounting a filesystem from a server (to be used if the server crashes) and that the server should support some kind of redirect facility for when volumes are moved. At question time, Mike Eisler suggested that Craig Everhart's proposal for a multi-level filesystem-id might work well to identify relocatable filesets. David Robinson described a new file locking proposal that uses a OPEN/CLOSE operations to support PC clients that need to be able to open or create files and establish file locks atomically. A "state id" returned by the server identifies the client's lock state. The state id is required as an argument to READ and WRITE operations where mandatory locking is enforced. He listed a number of outstanding issues that need to be resolved: the current proposal needs a cleanup, a lease-refresh procedure might be used instead of a zero-length READ, locks to support long-term caching would be useful (like oplocks), and there is concern as to the performance of client polling of blocked locks. Mike Eisler spoke on NFS version 4 security - the final talk of the session. He described existing practice with NFS versions 2 and 3 and the work to standardize RPCSEC_GSS security within the ONCRPC working group. He indicated the security requirements for NFS v4: a mandatory set of security mechanisms, secure negotiation, and strong authentication, data integrity and privacy. He proposed NFS v4 require RPCSEC_GSS security with Kerberos v5 support as one of the required mechanisms. There was no dissent from the participants. He went on to indicate that an Internet-scale, public key scheme is still not defined. SPKM is one possibility. He raised some security issues that need further discussion: will the IESG accept an optional requirement for data integrity and privacy ? How does SSL fit in ? (It won't work over UDP and cannot be negotiated via RPCSEC_GSS). He recommended the "Globus" model for a public key solution (see http://www.globus.org/security ). There being no further questions, Brian Pawlowski concluded the session at 11:05am.