[nfsv4] [FedFS] Meeting Minutes, 09/10/2009

[James Lentini <[e-mail]>]

FedFS Meeting Minutes, 09/10/2009
---------------------------------

Attendees
---------

Andy Adamson (NetApp)
Sorin Faibish (EMC)
Paul Lemahieu (EMC)
James Lentini (NetApp)
Pavan Mettu (Sun)
Trond Myklebust (NetApp)
Chris Stacey (EMC)
Renu Tewari (IBM)
Rob Thurlow (Sun)

Minutes
-------

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each week's meeting with this announcement.

+ Review Action Items

  - James Lentini find out who is attending Bake-a-thon from NetApp.

  Complete.

  - James Lentini will draft text describing the format of the fedfsNfsPath

  Complete.

+ Austin NFS Bake-a-thon

+ NSDB Draft Update

  Review updated NSDB draft:

  http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-protocol-03bis.txt

  A diff with the published draft is here:

  http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-protocol-rfcdiff.html

  This update includes the changes we've been discussing on the mailing 
  list and at our weekly meetings, including:

  - Reference DNS SRV document
  - Clarify LDAP user configuration (Section 4.1)
  - Updated fedfsNfsPathname to use pathname4 encoding
  - Expand descriptions to include example values (Section 5)
  - Add missing LDAP OID registration field.

+ Admin Draft Update

  The admin draft has been updated to use the equivalent of a pathname4 
  data type. The current text specifies a unique type rather than 
  rely on the NFSv4 definition.

+ Discuss Feedback on LDAP Configuration

  We discussed the recent discussion threads about our LDAP configuration.
  Nico Williams had a conflict and was unable to attend.

  [AI] Nico Williams will send his proposed changes to our LDAP
       configuration (o=fedfs) and the format of the FSL's pathname 
       attribute.

  There were comments that we didn't need UUIDs. Rob Thurlow spoke with 
  Nico about his concerns and believes Nico has a suggestion for how to 
  address them. We discussed the advantages of using UUIDs versus names.
  With UUIDS, the system is able to store the FSN in the filesystem once 
  and forever. The FSN never needs to change. Name collisions will not 
  occur. A human readable name is good if users are expected to 
  read it, but users are not required to read FSNs (although we expect them 
  to be viewable using advanced commands).

  Nico was also concerned that our LDAP design requires a dedicated 
  set of LDAP server. He would like to see a specification that allows either 
  separate LDAP servers or re-use of existing LDAP servers. 
 
  James stated that if there was some way to remove the o=fedfs and 
  keep the simplicity, that would be an improvement.

  There were also concerns about storing the FSL pathname in XDR format. 
  A binary field does not allow users to view and manipulate the field 
  easily with standard tools. James noted that some tools (e.g. Apache 
  Directory Studio) allow binary fields to be viewed, although 
  the interface is similar to a hex editor, and edited. Trond noted 
  that the FSL has other binary fields such as the fedfsNfsInfo. James 
  also mentioned that fields such as the fedfsNfsFlags are strings 
  representing binary data (A user that views the value "1" for 
  fedfsNfsFlags will need to understand that the flag specified 
  by that value).

  James stated that his goal was for the FedFS database to have 
  the same expressive capabilities with respect to pathnames as 
  the NFS protocol. 

  We did a short brain storm of how to satisfy these two goals: 
  use a string formatted pathname field for easy reading by tools 
  and be capable of describing all pathnames supported by NFS.

  One idea was to create two path-related attributes in the FSL,
  one with a string containing the path and another with the 
  pathname separator. Trond noted that there are filesystems that 
  have multiple pathname separators. For example a windows pathname 
  can have a ":" and "\". VMS pathnames are also notoriously 
  complex. It may be possible to address this by including multiple 
  pathname separators. More time needs to be spent thinking about 
  this.

  Trond suggested that another option may be to use labels for 
  each path component, similar to how LDAP Distinguished Names 
  (e.g. cn="foo",...). 

  Nico may also have a proposal for how to address the above.

  [AI] James Lentini, in consultation with Trond, will think 
       about a pathname format that is human readable and capable 
       of describing all possible NFS paths. 

  Nico is also interested in how the system would operate when 
  two companies merged.

  Rob asked if or should there be a mechanism for specifying 
  that an NSDB used a non-default port. The default LDAP port 
  is 389. There were questions about what the extra flexibility 
  would enable and the interaction with firewalls. The format 
  for an FSN's NSDB value is specified in the NSDB draft on 
  page 5 and Admin draft on page 7.

  [AI] Rob Thurlow will consider the use of alternative LDAP ports 
       for an NSDB and report back with a recommendation to the group.

  Trond described an idea he had shared with Craig offline regarding 
  zero configuration and the DNS SRV draft. Trond suggested that the 
  DNS SRV draft have a recommendation that the local top level 
  path be reserved for zero configuration setups. In small environments
  (a home user or small business), there may not be a full featured DNS 
  server running. However those environments may have UPnP or Bonjour 
  which do offer SRV records. It would be convenient if a new NAS unit 
  would find the local root filesystem and could configure itself 
  into the namespace. Trond and Craig will complete their offline 
  discussion and report back with a proposal. We will put this item 
  on the agenda for next week. 

  [AI] Trond Myklebust will send zero-configuration DNS SRV proposal