Subject: [nfsv4] [FedFS] Meeting Minutes, 06/11/2009

From: James Lentini <[email-masked]>
Date: Thu, 11 Jun 2009 15:30:28 -0400 (EDT)

FedFS Meeting Minutes, 06/11/2009
---------------------------------

Attendees
---------

Andy Adamson (NetApp)
Craig Everhart (NetApp)
James Lentini (NetApp)
Paul Lemahieu (EMC)
Chris Stacey (EMC)
Pavan Mettu (Sun)
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

  - Renu Tewari will located informational RFCs on DNS TTL values

    Complete. Renu reported on her findings:

    RFC 1033 described how admins should set DNS parameters. There is a
    discussion in this document on what the minimum TTL value should be. 
    The document recommended 1 day as a minimum. All admins used this 
    value. This led to problems. RFC 1912 discussed the problems with 
    this. RFC 1912 recommended a larger value. It recommends 3 or more 
    days and even 1-2 weeks in certain cases.

  - Craig Everhart will draft updated FSN-to-FSL caching text

    Complete. Craig sent the updated text to the mailing list. 

+ Reminder: No Meeting Next week

  Enjoy Bake-a-thon!

  Also, no meeting on July 2.

+ Bake-a-thon (June 15-19)
  http://www.connectathon.org/bakeathon/

  No news.

+ FSL Caching

  We are down to two options for maintaining the fileserver FSL cache.

  - fileserver polls (the fileserver checks periodically that the 
    FSL has not changed)

  - fileserver notifications (when an FSL is added or changed, the NSDB 
    or administrative tool will notify all the fileservers caching the FSL)

  There was a discussion regarding the characteristics of junctions (what 
  they are allowed to point to, who is allowed to create them, etc.).

  Craig pointed out that some type of fileserver polling would be necessary
  even with the fileserver notifications mechanism in case the notification 
  was lost due to a failure (e.g. disconnectivity).

  We also discussed the characteristics of an NSDB. In particular that 
  fileserver require only read access to an NSDB currently.

  For the fileserver notification mechanism each FSN would have a list of 
  caching fileservers. This list could be maintained by the fileservers or 
  by the admin tool. 

  If the fileservers added themselves to the list directly over LDAP, they 
  would need write access to the NSDB. Instead of giving the fileservers 
  write access, a service co-located with the NSDB (perhaps using an ONC 
  RPC protocol) could be used by the fileservers to update the NSDB.

  If the administrative tool added entries to the list, they would need to 
  add the fileservers permanently to the list. This would require the
  fileservers to be notified of any changes to the FSN-to-FSL mapping in 
  perpetuity, even if the fileserver was not caching any FSLs. 

  Unless the fileserver is actively telling the NSDB it is caching the 
  FSL, it seems impossible not to always inform the fileserver when an 
  FSN's FSLs change (either through addition of an FSL or modification 
  of an FSL).

  The NFS protocol uses getattr for file access. Is this much different? 
  It seems pretty similar to gettatr. The number of get

  A lease model is also attractive, similar to NFS delegations. We 
  reviewed the research we had done in this area and agreed that an 
  LDAP standard mechanism for this would be ideal.

  In the end, we agreed to move forward with the fileserver polling 
  mechanism and reserve the right to add additional mechanisms, including 
  the fileserver notifications or a delegations-like mechanism in the future 
  if prototypes encounter performance issues.

  [AI] James Lentini will update the NSDB draft with FSL caching text.

+ NSDB Draft Update

  Target a July 10th update.

  James summarized the changes he had proposed for the next NSDB draft:

  - Recommend an LDAP suffix of "o=fedfs" instead of 
    "dc=fed-fs,dc=com". The dc (domain component) attribute implies
    that there is a fed-fs.com domain. I've successfully used the 
    o=fedfs suffix in several LDAP implementations:
        - OpenLDAP
        - Microsoft Active Directory Lightweight Directory Services (LDS)
        - Fedora Directory (aka 389 Directory)
        - Apache Directory

  - Created an NFS specific FSL type. This eliminates the need to 
    define FSL type values in the standard. It also easily allows 
    for future extensions for other protocols.

  - Formatted the LDAP schema for automated processing (in the style 
    used by other IETF NFS documents)

  - Added "fedfs" prefix to LDAP objects. This allows easier searching 
    for fedfs related schema elements.

  - Added the UUID text we agreed to on 3/12

  - Added the annotations syntax we agreed to on 5/14

  In addition to these, the draft will also include:

  - FSL caching text
  - IANA considerations text