NFSv4 Working Group Meeting @ IETF 46, Washington D.C. 11/10/99 Reported by Brent Callaghan WG co-chair, Brent Callaghan, welcomed the attendees and introduced the first speaker, document editor, Spencer Shepler. Spencer described the state of the v4 specification and enumerated some of the changes in the latest draft. The most significant additions were the delegation mechanism for file caching and Access Control Lists (ACLs) as a new file attribute. In addition, the definitions of the chown_restricted, rdattr_error, owner, and owner_group attributes were updated. The CREATE operation was fixed to allow the creation of symbolic links and special device nodes, and minor changes were made to the OPEN and READDIR operations. The text presenting the requirements for transport and congestion control requirements was improved. The RPC language protocol description was cleaned up. The next protocol draft will have some improvements to the LINK and RENAME operations, a complete section on minor versioning, and LIPKEY security. The next speaker, Mike Eisler, described some minor changes to the LINK and RENAME operations that provide more flexibility in the specification of the target directory filehandle. Dave Noveck suggested that the stateid might be made persistent across a compound op like the filehandle, i.e. set the stateid with a PUTSTATEID operation. Mike responded that the proposal might have merit, but not enough to make it worth revising the spec at this stage. Mike went on to describe his proposal for minor versioning that he had posted previously to the mailing list. He suggested that the changes allowed by a minor version should be subject to some constraints if interoperability is to be preserved. For instance, new attributes can be added, but attributes cannot be deleted. In addition, he proposed the addition of a minor version field to the COMPOUND procedure so that the server knows the minor version that the client assumes, as well as an error that the server can return if the client requests a minor version that the server does not support. Ran Atkinson raised an issue as to whether the complexity of the minor version rules and mechanism made it worth adding to the protocol. Mike responded that minor versioning is a less heavyweight mechanism than a full RPC version change. Minor versioning also implies backward compatibility (which is not an RPC version requirement). Uresh Vahalia suggested that a change of some feature from "mandatory" to "recommended" might break the protocol. Mike said that this should not be a problem if the client and server both agree on the version. Ted Ts'o suggested a scenario where a minor version might be used to drop support for an operation considered "onerous." There seemed to be a consensus that the minor versioning rules should not be finalized until a minor revision is attempted. Mike completed his presentation with an update on LIPKEY security. LIPKEY is a public key mechanism based on the SPKM (rfc2025) and compatible with the RPCSEC_GSS security framework. LIPKEY borrows from SSL/TLS security in using the server's public key to establish a secure connection between client and server over which authentication can be negotiated securely. A public key is not required by the client. Since LIPKEY doesn't face the same key management problems of Kerberos v5, it is more suitable for NFSv4 security on an Internet scale. The next speaker, Dave Noveck, gave a "worry" list of issues that are raised by the spec. The statefulness of v4 means that requests are not independent and some state may be unbounded. It is more important for v4 clients and servers to synchronize their times for lease or delegation expiration. Dave is also concerned that state in the protocol could require unbounded resources. Implementations will need to handle this. Dave concluded by pointing out that giving up on locking requests is not easy - either it must be forbidden or the protocol must specify a cleanup path. WG co-chair, Brian Pawlowski, showed the results of some work to measure NFS throughput over TCP and UDP. Previous results had shown that TCP performance lagged UDP performance. Brian showed that a simple boost in the TCP window size produced throughput results superior to UDP. He concluded that the use of TCP as a preferred transport for NFSv4 would not be a problem. On the performance track, Brian questioned the performance cost of the new file attribute model and the compound operations. Some performance measurements need to be done to quantify the performance cost of these features. Brian enumerated some of the protocol features that must in the spec before the protocol can be declared "complete". The document editor is working to a December deadline for completion of a final draft of the spec for submission to the IESG as a Proposed Standard. He went on to suggest additional testing opportunities for interoperability. Obviously, Connectathon 2000 in March 2000 is a good opportunity, but another interoperability bakeoff will be needed in June or July. The remainder of the time was allocated to open discussion. There was some concern about the ability of a v4 server to detect local access to a file that is OPEN or delegated by a v4 client. Brian suggested that a separate Informational RFC would be a useful document for examining some of these implementation issues in depth - rather than in the v4 spec. A final question queried the value of volatile filehandles since their properties are inferior to persistent filehandles. Spencer replied that volatile filehandles are inferior, but in many cases they are the only way that some filesystems or servers can make data available. Brian also pointed out that recent discussion of changes to the persistent file handle attribute on the WG alias appeared to have addressed the issue. Brian concluded the meeting at 10:50am.