Subject: Minutes of nfsv4 WG meeting in San Diego

From: Brent <[email-masked]>
Date: Fri, 22 Dec 2000 11:20:26 -0800

NFSv4 Working Group Meeting @ 49th IETF, San Diego
--------------------------------------------------

        Reported by Brent Callaghan

After welcoming the participants and presenting the meeting
agenda, Brent Callaghan gave a short presentation on the
closing of the ONCRPC working group.  This working group
was originally formed to move the Informational RFCs that
described the "Sun" RPC protocols (XDR RFC 1014 and RPC
protocol version 2 RFC 1057) onto the Standards Track.
The process involved clarifications and updates to the
documents to bring them up to standards track quality, without
any changes to the protocols themselves. These eventually
became RFC 1832 (XDR), RFC 1831 (RPC) and RFC 1833 (Binding
protocol) was added to include the previously undocumented
Portmap/Rpcbind protocol.  Also added was the RPCSEC_GSS
standard in RFC 2203.  Since NFSv4 depends on and references
RFCs 1831, 1832, and 2203, it cannot advance along the
standards track without these protocols.  Hence, the IESG
will transfer responsibility for these documents to the NFSv4
working group.  Currently, all are at Proposed Standard except
for RFC 1832 (XDR) which is at Draft.

Document editor, Spencer Shepler, then took the mike and gave
an update on the NFSv4 specification and the NFS Implementation
RFC.  Little progress has been made on the Implementation RFC
since the last meeting, but Spencer is taking input for the
first draft which is expected around March 1st.  At the last
NFSv4 bakeoff event in October, some problems were found in
the current specification that will need some changes to the
document. He took several slides to briefly enumerate some
of the issues that were brought up. Some of the changes will
be clarifications in the text, though 2 or 3 others will
require a change to the protocol. Spencer expects to have an
amended spec ready for submission March 1st.  This new draft
will be assigned a new RFC number that obsoletes the current
one (RFC 3010).

Co-chair, Brian Pawlowski, asked Allison Mankin to explain the
procedure for updating the current Proposed Standard.  Allison
mentioned that IESG might measure the 6 month minimum time to
submit a Draft standard relative to the publication of the first
Proposed draft if the changes in a subsequent draft are minor.

Brian gave a presentation on the Replication and Migration work
now before the working group. This work item was first discussed
at length at the Pittsburgh meeting. Brian presented some
material that consolidated some of the thoughts at that
meeting.  He gave a definition of the work and an overview of
some previous replication work in filesystems like AFS and
DCE/DFS as well as replica maintenance protocols like rsync and
rdist. He listed several requirements. Client failover between
replicas must be transparent to applications. Resolution of
replica differences must be conservative of bandwidth,
restartable and minimize lack of access to clients.  The
protocol must open no new security holes and be scalable from
small filesystems to huge ones.  Since replicas may be hosted on
servers and filesystems with different capabilities, there must
be provision for negotiating support of filesystem features and
attributes between replicas. In response to a question about
existing methods of replication via block-level mirrors, Brian
added a requirement that that replication be supported
independently of filesystem type and block layout. Since
replication and migration is outside the working group charter,
Brian agreed that a revised charter needs to be submitted and
approved by the IESG.

The final segment of the meeting was opened up to general
NFS version 4 issues. Brian kicked off the discussion with
several: Compatibility with NFS versions 2 and 3 must be
assured with lease handling compatible with those clients.
Interactions of client transfer sizes and workloads should
be studied so that implementations can be optimally tuned.
Some utilities may need to be defined for state management,
for instance, a utility that provides locking statistics or
that provides a way to terminate a "stuck" client that is
tying up file locks.  A standard SNMP MIB that supports
vendor independent management of NFS servers should be
investigated.  Finally, the SPEC SFS benchmark must 
eventually be extended to measure NFS version 4 performance.

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

The slides from the meeting can be viewed at:

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

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