NFSv4 Working Group Meetings @ Connectathon, San Jose 3/9/99
------------------------------------------------------------

        Reported by Brent Callaghan from notes by Spencer Shepler
        with contributions from Mike Eisler.

This meeting of the working group was scheduled at the
Connectathon event (www.connectathon.org) instead of
the IETF meeting the following week in Minneapolis. Since
the event is attended by a strong contingent of NFS engineering
talent, we expected to pick up some new participants who are
not yet in the habit of attending IETF meetings.  Our "blue sheet"
attendance was encouraging: a strong turnout of 57. The meeting
was held in a meeting room, open to the public, adjacent to
the Connectathon floor in downtown San Jose.

First Session (2:00 - 3:30pm)

  WG co-chair, Brian Pawlowski, hosted the first 90 min
  session.  Document editor, Spencer Shepler, acted as scribe.
  Since many of the attendees were new to the IETF and WG
  procedures, he showed some slides that described the draft
  charter and milestones.  A show of hands indicated that many
  were not on the mailing list.  Brian copied the WG charter
  page that contains the mailing list address and distributed it
  at the next session.

  Spencer Shepler gave an update on the status of the
  Requirements document and the draft spec. Following IESG
  feedback on the draft submitted last December, the
  requirements document will be renamed "NFSv4 Design
  Considerations" and will include some additional descriptive
  text. The document will be re-submitted for last-call before
  referral back to the IESG. The draft protocol spec has been
  extended with some major updates that include a server
  namespace proposal, file locking with OPEN and CLOSE
  procedures, and support for Unicode strings via UTF-8 wire
  encoding.

  Srini Bharadwaj presented a list of features that he would
  like to see supported in the protocol. He is concerned that
  the growth in the number of file formats is not supported by
  the protocol. He would like a file attribute that refers to a
  downloadable program that can be used by a browser to provide
  access to the file internals. He would also like the protocol
  to support a "bulk handling" feature that would allow a client
  to retrieve multiple files in a single request or to validate
  their cache consistency. He would also like a search facility
  that allows a client to search a file for specific content.
  In the discussion that followed, some expressed the view that
  the draft attribute model could be extended to describe
  content via an attribute like MIME type.  Srini asked whether
  the failure semantics of compound ops would be extended to
  permit multiple failures. Gordon Waidhofer pointed out that
  the existing spec uses an "&&" semantic that could be expanded
  to support the "||" and C "," operators.  Mike Eisler and
  Brian objected that this would add much complexity to the
  protocol. Some suggested that batching could be handled with
  the existing compound ops or request pipelining.  There were
  many negative comments on the search proposal: whether the
  feature would be useful to existing APIs or applications.
  Gordon Waidhofer brought up the issue of protocol control of
  named attributes. Rob Thurlow advocated management of 
  attribute names be left outside the protocol.

  The rest of the first session was devoted to open discussion.
  Brian kicked off by reviewing some of the features in the
  current draft spec: eliminate mount protocol, incorporate file
  locking protocol, fast, firewall-friendly binding via
  incorporation of WebNFS features like multi-component lookup,
  compound requests, pluggable security via RPCSEC_GSS and
  protocol extensibility.  Already assumed that version 4 will
  be an evolution of version 3 in its use of transport
  independent ONCRPC. There was some discussion on the issue of
  statelessness.  NFS has been described as a stateless protocol
  yet most implementations are not truly stateless since they
  support state via duplicate request caching and file locking.
  There was some concern that a stateless requirement would
  limit NFS version 4.  Spencer resolved to remove references to
  statelessness from the requirements document.


Second Session (4:00 - 5:00pm)

  Brent Callaghan began with a presentation on caching issues.
  He began with an overview of NFS v2/v3 caching and the use of
  close-to-open consistency by many implementations vs use of
  "probablistic" caching of file attributes. He finished with a
  list of design considerations for NFS v4 caching, emphasizing
  its use over the Internet: What consistency model ?  Is
  close-to-open good enough ?  Should callbacks be used ?  What
  objects should be cachable ?  How to support proxy caching ?
  How difficult to implement ?.

  Rob Thurlow gave an update on NFS v4 support for file
  attributes.  The model still assumes an extensible model of
  numbered attributes that can be requested/set with a bitmap
  but includes support for named attributes via an OPENATTR
  operation. Should attributes that indicate a capability (like
  persistent_fh) be mandatory or does lack of support imply
  false ? Some confusion as to the meaning of "extended
  attributes". Proposal to change the term to "named
  attributes". Still no proposal for ACL support is worrisome.
  Unresolved issues: still no consensus over definition of a
  mandatory attribute or how interoperability will be achieved
  if clients and servers implement disjoint attribute subsets.

  At Brian Pawlowski's request, Mike Eisler gave an impromptu
  presentation on security issues and sought some consensus on
  the use of ONC RPC as a basis for NFS v4.  There was no objection
  to that, or the use of RPCSEC_GSS as a security framework.
  Mike described the IETF policy on strong security for new
  protocols and added that Kerberos v5 is a strong
  contender for a mandatory-to-implement security mechanism.
  There was significant concern expressed that support for Kerberos
  would be burdensome and some questions about export control
  issues.  Mike replied that Kerberos v5 has wide support in the
  industry and there are previous cases of export licenses being
  granted for Kerberos authentication.  He mentioned that
  conforming implementations would be required to support it,
  but customers cannot be forced to use it if they prefer a
  weaker alternative. Mike mentioned that he had submitted an
  Internet Draft for a simple, but secure public key scheme based
  on SPKM that might be considered for NFS:
  draft-ietf-cat-lipkey-00.txt. There was also some discussion
  on the use of other security mechanisms like IPSEC or TLS.
  IPSEC and TLS do not handle the case of multiple users sharing
  the same connection. Also, TLS does not run over UDP.

  Brian Pawlowski offered some thoughts on replication and
  failover support in NFS v4. He would like support in the
  protocol to allow automatic location of replicated filesystems
  and also a mechanism that would allow clients to track a
  filesystem that is relocated from one server to another.  AFS
  and DCE/DFS support these features, but rely on their own
  volume location databases with heavy implementation
  requirements. Solaris NFS supports client-side failover with
  replica location via automount map. Brian suggested that a
  simple mechanism built into the protocol could allow clients
  to query the server for a list of replica locations and also
  permit the server to redirect the client to a new location for
  a relocated volume. He concluded that much work was yet to be
  done to determine requirements and a concrete proposal for
  meeting them.

  Brent concluded the meeting at 5:10pm.