Subject: [nfsv4] FedFS Meeting Minutes, 02/05/2009

From: James Lentini <[email-masked]>
Date: Thu, 5 Feb 2009 15:07:07 -0500 (EST)

FedFS Meeting Minutes, 02/05/2009
---------------------------------

Attendees
---------

Craig Everhart (NetApp)
James Lentini (NetApp)
Renu Tewari (IBM/ARC)
Rob Thurlow (Sun)
Mario Wurzl (EMC)

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 weeks meeting with this announcement.

+ Review Action Items

  [AI] James Lentini write Spencer Shepler about scheduling a FedFS 
       talk at the March NFSv4 WG meeting.

+ Upcoming events

  - Connectathon

    Rob noted that there is a presentation slot on Monday at 
    Coonectathon. The FedFS BOF that was on the schedule has 
    be replaced by another topic. If there are additional 
    topics to discuss then we can move the discussion to the 
    atrium after the formal presentation. There will also be 
    a reception for Connectathon participants on Monday night. 

    For registered connectathon participants, there will be 
    a migration and replication kickoff meeting (private to 
    attendees). 

  - FAST '09 BOF

    No updates from last week.

+ NSDB Protocol Document Feedback

  Craig read through the document. He noted that the error 
  codes were removed and that we should consider retaining these 
  in someway. The error codes were removed because it is not 
  possible to return FedFS-specific error codes (e.g. ERR_WRONGNSDB) 
  from LDAP.

  James suggested adding an appendix that recommends a mapping from 
  LDAP errors to these error codes for library writers. Our vision 
  is that the LDAP operations will be abstracted into software 
  libraries. The appendix would provide a recommendation for 
  how to map LDAP errors into error codes for C.

  Rob recommended caution when specifying APIs. IETF documents 
  should specify wire formats. If a language specific abstraction 
  layer is envisioned, a C header file might be useful. In 
  principal, distinguishing between the various LDAP error codes 
  is a good idea. If this is not possible, then we should do what 
  is reasonable.

  James noted some additional comments he had received. A 
  reviewer noted that the FSL hostname is loosly specified. 
  The reviewer recommended tightening this up. We agreed to 
  require a specific character set (UTF-8) and specify the 
  format more precisely (FQDN, dotted decimal, or both). 
  We agreed to use the NFSv4[.1] specifications fs_locations[_info] 
  requirements as a guide and upate this.

  We also discussed expanding the security considerations section.

  A common misperception is that FedFS allows server A to fetch 
  data from server B on behalf of a user. It would be useful to 
  clarify that this is not part of FedFS. 

  Clearly stating our expectations with regards to 
  authorization and authentication schemes would also be useful.

  Another point to expand upon is how the various security schemes 
  interact and provide an analysis of the potential threats. For example, 
  the client has to have some basis for trusting the server and 
  the server trusts LDAP database. Does a failure of one affect the other?

  On idea that has been discussed is having a security token that 
  is passed from LDAP all the way to the NFS client. This would 
  require changes to the client protocol which are outside the scope 
  of this work, but it may be worth noting the possibility.

  Document update for next week:
   - error codes
   - FSL host name format
   - security considerartions
   - review mount command name

  The goal is to re-publish the NSDB specification on 2/13.
  Next, we will begin review of the Admin Protocol document.