NFSv4 Working Group Meeting @ 49th IETF, San Diego -------------------------------------------------- Reported by Brent Callaghan After welcoming the participants and presenting the meeting agenda, Brent Callaghan gave a short presentation on the closing of the ONCRPC working group. This working group was originally formed to move the Informational RFCs that described the "Sun" RPC protocols (XDR RFC 1014 and RPC protocol version 2 RFC 1057) onto the Standards Track. The process involved clarifications and updates to the documents to bring them up to standards track quality, without any changes to the protocols themselves. These eventually became RFC 1832 (XDR), RFC 1831 (RPC) and RFC 1833 (Binding protocol) was added to include the previously undocumented Portmap/Rpcbind protocol. Also added was the RPCSEC_GSS standard in RFC 2203. Since NFSv4 depends on and references RFCs 1831, 1832, and 2203, it cannot advance along the standards track without these protocols. Hence, the IESG will transfer responsibility for these documents to the NFSv4 working group. Currently, all are at Proposed Standard except for RFC 1832 (XDR) which is at Draft. Document editor, Spencer Shepler, then took the mike and gave an update on the NFSv4 specification and the NFS Implementation RFC. Little progress has been made on the Implementation RFC since the last meeting, but Spencer is taking input for the first draft which is expected around March 1st. At the last NFSv4 bakeoff event in October, some problems were found in the current specification that will need some changes to the document. He took several slides to briefly enumerate some of the issues that were brought up. Some of the changes will be clarifications in the text, though 2 or 3 others will require a change to the protocol. Spencer expects to have an amended spec ready for submission March 1st. This new draft will be assigned a new RFC number that obsoletes the current one (RFC 3010). Co-chair, Brian Pawlowski, asked Allison Mankin to explain the procedure for updating the current Proposed Standard. Allison mentioned that IESG might measure the 6 month minimum time to submit a Draft standard relative to the publication of the first Proposed draft if the changes in a subsequent draft are minor. Brian gave a presentation on the Replication and Migration work now before the working group. This work item was first discussed at length at the Pittsburgh meeting. Brian presented some material that consolidated some of the thoughts at that meeting. He gave a definition of the work and an overview of some previous replication work in filesystems like AFS and DCE/DFS as well as replica maintenance protocols like rsync and rdist. He listed several requirements. Client failover between replicas must be transparent to applications. Resolution of replica differences must be conservative of bandwidth, restartable and minimize lack of access to clients. The protocol must open no new security holes and be scalable from small filesystems to huge ones. Since replicas may be hosted on servers and filesystems with different capabilities, there must be provision for negotiating support of filesystem features and attributes between replicas. In response to a question about existing methods of replication via block-level mirrors, Brian added a requirement that that replication be supported independently of filesystem type and block layout. Since replication and migration is outside the working group charter, Brian agreed that a revised charter needs to be submitted and approved by the IESG. The final segment of the meeting was opened up to general NFS version 4 issues. Brian kicked off the discussion with several: Compatibility with NFS versions 2 and 3 must be assured with lease handling compatible with those clients. Interactions of client transfer sizes and workloads should be studied so that implementations can be optimally tuned. Some utilities may need to be defined for state management, for instance, a utility that provides locking statistics or that provides a way to terminate a "stuck" client that is tying up file locks. A standard SNMP MIB that supports vendor independent management of NFS servers should be investigated. Finally, the SPEC SFS benchmark must eventually be extended to measure NFS version 4 performance.