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
[email protected] 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:
[email protected]
[email protected] (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.
______________________________________________
