NFSv4 Working Group Meetings @ Connectathon, San Jose 3/9/99 ------------------------------------------------------------ Reported by Brent Callaghan from notes by Spencer Shepler with contributions from Mike Eisler. This meeting of the working group was scheduled at the Connectathon event (www.connectathon.org) instead of the IETF meeting the following week in Minneapolis. Since the event is attended by a strong contingent of NFS engineering talent, we expected to pick up some new participants who are not yet in the habit of attending IETF meetings. Our "blue sheet" attendance was encouraging: a strong turnout of 57. The meeting was held in a meeting room, open to the public, adjacent to the Connectathon floor in downtown San Jose. First Session (2:00 - 3:30pm) WG co-chair, Brian Pawlowski, hosted the first 90 min session. Document editor, Spencer Shepler, acted as scribe. Since many of the attendees were new to the IETF and WG procedures, he showed some slides that described the draft charter and milestones. A show of hands indicated that many were not on the mailing list. Brian copied the WG charter page that contains the mailing list address and distributed it at the next session. Spencer Shepler gave an update on the status of the Requirements document and the draft spec. Following IESG feedback on the draft submitted last December, the requirements document will be renamed "NFSv4 Design Considerations" and will include some additional descriptive text. The document will be re-submitted for last-call before referral back to the IESG. The draft protocol spec has been extended with some major updates that include a server namespace proposal, file locking with OPEN and CLOSE procedures, and support for Unicode strings via UTF-8 wire encoding. Srini Bharadwaj presented a list of features that he would like to see supported in the protocol. He is concerned that the growth in the number of file formats is not supported by the protocol. He would like a file attribute that refers to a downloadable program that can be used by a browser to provide access to the file internals. He would also like the protocol to support a "bulk handling" feature that would allow a client to retrieve multiple files in a single request or to validate their cache consistency. He would also like a search facility that allows a client to search a file for specific content. In the discussion that followed, some expressed the view that the draft attribute model could be extended to describe content via an attribute like MIME type. Srini asked whether the failure semantics of compound ops would be extended to permit multiple failures. Gordon Waidhofer pointed out that the existing spec uses an "&&" semantic that could be expanded to support the "||" and C "," operators. Mike Eisler and Brian objected that this would add much complexity to the protocol. Some suggested that batching could be handled with the existing compound ops or request pipelining. There were many negative comments on the search proposal: whether the feature would be useful to existing APIs or applications. Gordon Waidhofer brought up the issue of protocol control of named attributes. Rob Thurlow advocated management of attribute names be left outside the protocol. The rest of the first session was devoted to open discussion. Brian kicked off by reviewing some of the features in the current draft spec: eliminate mount protocol, incorporate file locking protocol, fast, firewall-friendly binding via incorporation of WebNFS features like multi-component lookup, compound requests, pluggable security via RPCSEC_GSS and protocol extensibility. Already assumed that version 4 will be an evolution of version 3 in its use of transport independent ONCRPC. There was some discussion on the issue of statelessness. NFS has been described as a stateless protocol yet most implementations are not truly stateless since they support state via duplicate request caching and file locking. There was some concern that a stateless requirement would limit NFS version 4. Spencer resolved to remove references to statelessness from the requirements document. Second Session (4:00 - 5:00pm) Brent Callaghan began with a presentation on caching issues. He began with an overview of NFS v2/v3 caching and the use of close-to-open consistency by many implementations vs use of "probablistic" caching of file attributes. He finished with a list of design considerations for NFS v4 caching, emphasizing its use over the Internet: What consistency model ? Is close-to-open good enough ? Should callbacks be used ? What objects should be cachable ? How to support proxy caching ? How difficult to implement ?. Rob Thurlow gave an update on NFS v4 support for file attributes. The model still assumes an extensible model of numbered attributes that can be requested/set with a bitmap but includes support for named attributes via an OPENATTR operation. Should attributes that indicate a capability (like persistent_fh) be mandatory or does lack of support imply false ? Some confusion as to the meaning of "extended attributes". Proposal to change the term to "named attributes". Still no proposal for ACL support is worrisome. Unresolved issues: still no consensus over definition of a mandatory attribute or how interoperability will be achieved if clients and servers implement disjoint attribute subsets. At Brian Pawlowski's request, Mike Eisler gave an impromptu presentation on security issues and sought some consensus on the use of ONC RPC as a basis for NFS v4. There was no objection to that, or the use of RPCSEC_GSS as a security framework. Mike described the IETF policy on strong security for new protocols and added that Kerberos v5 is a strong contender for a mandatory-to-implement security mechanism. There was significant concern expressed that support for Kerberos would be burdensome and some questions about export control issues. Mike replied that Kerberos v5 has wide support in the industry and there are previous cases of export licenses being granted for Kerberos authentication. He mentioned that conforming implementations would be required to support it, but customers cannot be forced to use it if they prefer a weaker alternative. Mike mentioned that he had submitted an Internet Draft for a simple, but secure public key scheme based on SPKM that might be considered for NFS: draft-ietf-cat-lipkey-00.txt. There was also some discussion on the use of other security mechanisms like IPSEC or TLS. IPSEC and TLS do not handle the case of multiple users sharing the same connection. Also, TLS does not run over UDP. Brian Pawlowski offered some thoughts on replication and failover support in NFS v4. He would like support in the protocol to allow automatic location of replicated filesystems and also a mechanism that would allow clients to track a filesystem that is relocated from one server to another. AFS and DCE/DFS support these features, but rely on their own volume location databases with heavy implementation requirements. Solaris NFS supports client-side failover with replica location via automount map. Brian suggested that a simple mechanism built into the protocol could allow clients to query the server for a list of replica locations and also permit the server to redirect the client to a new location for a relocated volume. He concluded that much work was yet to be done to determine requirements and a concrete proposal for meeting them. Brent concluded the meeting at 5:10pm.