NFSv4 Working Group Meeting @ IETF 47, Adelaide
-----------------------------------------------

        Reported by Brent Callaghan

The NFSv4 working group met in two sessions. The first on Monday
evening for 2 1/2 hours and the second on Tuesday night for 1
hour.  The meetings were attended by 20 people. WG co-chair,
Brent Callaghan, welcomed the attendees and introduced the first
speaker, document editor, Spencer Shepler.

Spencer gave a quick summary of the changes that went into draft
06.  He added some new compound operations: OPEN_CONFIRM,
SETCLIENTID_CONFIRM, and OPEN_DOWNGRADE, and clarified the text
of the RENEW operation.  The document is currently pending IESG
review and more minor updates are expected following this
review.  Spencer then went on to describe some of the contents
of an Implementation Choices RFC.  The intent of this RFC is to
describe implementation detail specific to operating systems
such as UNIX.  This level of detail would be innapropriate in
the protocol spec. Spencer suggested the following items
be included:

    - Suggestions for persistent and volatile filehandle content.
    - How to support Internationalized text strings on filesystems
      that support single-byte encodings.
    - Discussions of client and server state management.
    - Options for converting between owner/group identities and
      protocol string representation.
    - Issues with allowing local access to an exported filesystem
      on a server (having NFS detect access to delegated files).
    - Managing missing attributes, solutions for file migration
      and replication.
    - Translating Access Control Lists from one representation to
      another.
    - Mapping locking and lease semantics across heterogeneous servers.

Brent summarized the results of the NFS v4 testing at
Connectathon.  As with the previous bakeoff in October, there
were six servers and 4 clients from 5 vendors.  The Solaris
snoop sniffer with extensions to handle NFSv4 decodes was used
as well as a new Tcl-based testing client. In addition to
testing some of the simpler ops (putrootfh, getfh, lookup,
getattr) there was some testing of more complex v4 ops (open,
create, rpcsec_gss security).

Bev Crair of Sun announced the availability of TI-RPC source
from Sun under the new Sun Industry Standards Source License
(SISSL) - downloadable from http://soldc.sun.com . This source
contains an implementation of the GSS-API (rfc2078) and
RPCSEC_GSS (rfc2203) along with updated RPC and XDR source code.
Sun also makes binaries of its NFS v4 prototypes available under
an evaluation license (contact dana.barsan@eng.sun.com). The
NFSv4 Tcl testing client, nfsv4shell, will be made available in
source form mid-April. Sun also continues to license its ONC+
source to ONC+ licensees.  The ONC+ license may provide early
access to NFS v4 product source.

Co-chair, Brian Pawlowski lead an interactive discussion through
the remainder of the session and the 1 hour session on Tuesday
night. Costas Sapuntzakis asked whether there was still interest
in adding protocol support for hardware decode of NFSv4
requests.  In a previous post to the list he suggested the
addition of byte counts fields that would allow ops containing
large chunks of data to be located quickly with a minimum of
protocol parsing.  The consensus seemed to favor leaving the
protocol alone - with a contention that smart enough hardware
could parse without the additional fields.  Neil Brown asked how
key exchange would be handled by LIPKEY in the reverse direction
when the server makes a callback (section 3.4 in the spec). Mike
Eisler suggested that the server might return a public key to
the client (Mike subsequently followed up with an additional
proposal on the list).  There was some discussion on the
properties of the changeid attribute: whether it should increase
or decrease.  Consensus seemed to be that the value should
increase (acknowledging wraparound for overflow).

Brian wound up the discussion by soliciting proposals for
further work that the WG could undertake:

        - Proxying support
                The protocol is not currently proxyable.
        - Implementation Choices document
                As described in Spencer's presentation.
        - Migration/replication protocols
                The NFSv4 protocol does not describe
                protocols for back-end migration of
                file data or replica management.
        - Global naming
                There is no global namespace described for
                NFSv4.  Possibilities include automounter-style
                naming (/net/server), NFS URLs, or AFS-style
                global namespaces.
        - Hardware acceleration
                Opportunities for accelerating protocol
                processing with hardware.
        - Minor versioning
                Development of a minor version of the
                protocol that includes some of the above
                features.

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

The slides from the meeting can be viewed at:

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

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