From: Brent Callaghan (Brent.Callaghan@Sun.COM)
Date: 01/02/02-11:12:06 AM Z
Message-ID: <3C333F66.DE095F05@Sun.COM>
Date: Wed, 02 Jan 2002 09:12:06 -0800
From: Brent Callaghan <Brent.Callaghan@Sun.COM>
Subject: Minutes from nfsv4 WG meeting @ 52nd IETF (Salt Lake City)
NFSv4 Working Group Meeting @ 52nd IETF, Salt Lake City
-------------------------------------------------------
Reported by Brent Callaghan
Co-chair, Brent Callaghan, presented the meeting agenda
and introduced Rob Thurlow as first speaker. Rob made a
case for file Replication and Migration work to be included
in the NFSv4 working group re-charter. He began with a quote
from Brian Pawlowski: "NFS version 4 is incomplete without this."
Distributed filesystems like AFS and DCE/DFS have provided
replication and migration services, but NFS doesn't.
He argued that this work is appropriate for the NFSv4 working
group because can more easily be designed to serve the needs
of NFS version 4, handle some of the details of NFSv4 (e.g.
its file attributes) and can be designed to support the
NFSv4 consistency and correctness requirements.
Brian Carpenter questioned the interest in this work given
the low turnout at the WG meeting. Brian Pawlowski pointed
out that the meeting did not represent those on the mailing
list, and suggested that Rob solicit mailing list
participants to help with replication/migration work.
Brian Carpenter asked about support in the NFSv4 protocol
to handle a replication/migration event, e.g. what happens
to filehandles? Brian Pawlowski responded that this support
has already been designed into the protocol.
Document editor, Spencer Shepler, then stood up and gave a
quick summary of the October "bakeoff" event, where several
implementations of NFS v4 were tested for interoperability.
A lot of progress was made with the new open state model
and few new protocol issues were raised. New protocol
features tested were named attributes and delegation.
Also mentioned was an NFSv4 client written in Python that
is suitable for use as a client test harness.
Spencer then gave an overview of the 160 items on the
list of issues with RFC 3010. The list of updates
can be seen at http://www.nfsv4.org/rfc3010updates .
Most of the issues are minor tweaks to the protocol
or its documentation and are well understood. There
are some issues on the list that are still being worked:
- Some further clarifications (minor modifications) to the
open/locking state model.
- Open upgrade/downgrade paths. Windows file open deny modes
conflict with UNIX.
- Special stateid usage by UNIX clients.
- File locking conflict at file open time between Windows and
UNIX clients.
- Support of security mechanisms in pseudo filesystems.
- Addition of WINDOWS semantics for file removal on CLOSE.
Previous behavior was to rename the file to .nfsxxxx.
- Need to handle recovery of partial state "loss". For instance,
loss of state on a single file. Also need to handle removal
of state, e.g. stuck client holding open a lock.
- Require clarification on Various delegation scenarios.
For instance, if a client mounts the same filesystem twice,
will delegations "thrash" ? This is not a protocol issue, but
it needs to be documented. We also need to clarify and contrast
the return of delegation via CLOSE and DELEGRETURN operations.
- Need additional clarification on the validation of UTF-8 strings.
Scott Bradner suggested that we look at the work of the Internationalized
Domain Names group (IDN) in canonicalizing UTF-8 strings for the
purpose of comparison. Spencer hopes to have all the changes integrated
with the draft spec by the end of January to form a stable base for
interoperability testing at Connectathon in March.
Brian Pawlowski reviewed the work items ahead for the working
group, starting with completion of revisions to rfc3010 and closing
of all open issues, followed by a verification of interoperability
(suitable for Draft submission) at Connectathon. NFSv4 is still
waiting on advancement of RPC RFC's and GSS-dependent drafts,
and a new set of milestones for advancement of the spec.
Scott mentioned that the IESG is struggling with the notion of
interoperability when applied to an API, such as GSS-API.
Scott suggested that a short RFC is needed that describes how
the IESG will evaluate API interoperability. Brian indicated that
a new draft charter has been submitted to the IESG based on
feedback from the Transport Area Directors. An additional issue
is whether this group should exploit RDMA work for NFS and RPC.
Scott added that the ROI BOF (RDMA over the Internet) was evenly
split between forming a working group and having another BOF,
but he was confident that a working group would eventually be formed.
The meeting concluded at 5:00pm.
-------------------------------
The slides from the meeting can be viewed at:
http://playground.sun.com/pub/nfsv4/presentations/ietf52
------------------------
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:28 AM Z CST