Subject: Minutes from NFSv4 WG meeting @ IETF-46

From: Brent Callaghan <[email-masked]>
Date: Tue, 23 Nov 1999 18:25:15 -0800 (PST)

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.

------------------------

The slides from the meeting can be viewed at:

   http://playground.sun.com/pub/nfsv4/presentations/ietf46

------------------------