Editor's note: These minutes have not been edited. NFS V4 BOF Minutes San Jose IETF, December 1996, As reported by Brent Callaghan (Sun) with assistance from Jon Dreyer (Sun). Brent Callaghan welcomed the participants by describing the motivation for doing an NFS protocol revision within the context of IETF and followed with an introduction to NFS: its design principles, its history, the design motivations and process for version 3, and presented WebNFS as a motivation for further work on the NFS protocol in version 4. He then introduced Mike Eisler (Sun) who covered the wish-list items for version 4 and solicited feedback from the BOF participants. In summary, the wish-list items are: - Internationalisation - Facilitate operation on the Internet - Improved security semantics - Integrated Locking - Embrace non-Unix systems - Better support for caching - Protocol extensibility Some of these items had been discussed previously on the nfs4-wg@sunroof.eng.sun.com mailing list. Mike summarized these discussions in his presentation. The following notes summarise BOF discussion on some of these items: On Internationalisation: Case mapping is language-dependent, but unicode specifies pretty good language-independent case mapping. Perhaps server can translate OTW character set to local character set before doing case mapping, but need to deal with possibility that some OTW chars may not translate to local character set. On facilitating operation on the Internet: Brian Pawlowski of Network Appliance mentioned that the bundling of locking with the NFS protocol will not in itself "fix" locking. He was concerned that a running the protocol over TCP is not necessarily a good move since UDP still currently outperforms TCP on LANs and TCP introduces scalability problems with connection state on the server. Brent mentioned that web servers already cope with very heavy connection loads and that there are techniques available for servers to manage connection overhead. On embrace of non-Unix systems: Brian is concerned that if we add stuff like a "hidden" bit for better PC semantics and few servers supported it we may be worse off. Boris Zuckerman from FTP argued that the protocol should support wildcard semantics. "Just because it's difficult doesn't mean we shouldn't do it." Jon Dreyer is concerned that it's not really possible without also adding protocol support for 8.3 names, since filenames with wildcards may contain 8.3 components. He views protocol support for 8.3 names as an anachronistic nightmare. On protocol extensibility: Adding extensions means there's more than one protocol. Some concern was expressed that this might facilitate creeping featurism and make testing of multiple minor-versions more difficult. Providing support for arbitrary named attributes might cause problems with name space clashes, e.g. two clients might assign different semantics to attribute "frobnitz." Someone proposed using something like an OID to identify attributes rather than names. But this handles only protocol-defined attributes rather than arbitrary name-value attributes. There was some discussion as to how named attributes might be stored in filesystems that do not support them. Mike Eisler mentioned that a directory can be thought of as containing named attributes each with arbitrary data. There was some concern as to how the protocol would cater to clients and servers that mutually identify with a particular set of filesystem semantics and wish to use them, e.g. where a Windows NT client identifies the server as a Windows NT server and needs full NTFS semantics. Several people expressed the opinion that the protocol should not stray into this dangerous ground. On security mechanisms: Jon Dreyer was surprised about the requirement that to be a conformant implementation must implement all security mechanism in the identified gss-api mechanisms, especially with lightweight clients like the toaster. Mike Eisler reaffirmed this requirement. On additional items: Tom Kessler asked if the protocol should support the use of proxy servers. Brent Callaghan replied that proxying was not possible with the current protocol versions and that it would be useful for V4 to support proxying. Mike Eisler mentioned that the current model of persisent filehandles is limiting and that a dynamic filehandles backed by pathnames that permit recovery of filehandle data would be more useful. Version 4 could tag filehandles with a hint as to its volatility. The client could use this information to decide whether to cache the pathname corresponding to the filehandle. How about adding a copy procedure to the protocol so if OSs support it later we can support it? Many felt that second-guessing the future tends to add useless baggage because we second-guess wrong. Brian Pawlowski asked a rhetorical question: "Why don't we just adopt DFS?" Mike Eisler replied that OSF/Open Group isn't bringing it to the table. Brent concluded the BOF with a summary of actions required for working group formation. Working group chair(s) would need to be approved by the ADs. Current candidates for co-chairs are Brent Callaghan (Sun) and Spencer Shepler (IBM). The current WG mailing list addresses are: nfs4-wg@sunroof.eng.sun.com nfs4-wg-request@sunroof.eng.sun.com (for maillist requests) He reminded the attendees that the draft WG charter would need to be approved by those on the mailing list along with a list of milestones. He suggested that a working draft of the protocol should be ready a month ahead of the next IETF meeting (April) and that the upcoming Connectathon event late February in South San Francisco would be a good venue for an initial review and feedback. Keith Moore polled the attendees (~60) for their interest in participating in an NFS V4 Working Group and received an apparently unanimous show of hands. ______________________________________________