Subject: [nfsv4] [FedFS] Meeting Minutes, 8/19/2010

From: James Lentini <[email-masked]>
Date: Thu, 19 Aug 2010 17:00:03 -0400 (EDT)

FedFS Meeting Minutes, 8/19/2010
--------------------------------

Attendees
---------

Andy Adamson (NetApp)
Craig Everhart (NetApp)
Sorin Faibish (EMC)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Chuck Lever (Oracle)
Peter Staubach (EMC)
Spencer Shepler (Microsoft)
Robert Thurlow (Oracle)

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.

+ Report from the WG Meeting (Craig Everhart)

  Craig Everhart presented at the WG meeting. The slides 
  Craig presented are located here:

  http://www.ietf.org/proceedings/78/slides/nfsv4-2.pdf

  Spenser is preparing to shepherd 
  draft-ietf-nfsv4-federated-fs-dns-srv-namespace to the 
  IESG. He has reviewed the document and requested some 
  updates related to the references. Craig is revising 
  the draft to address Spenser's request.

  Craig observed that for a WG last call on the FedFS documents 
  before the November WG meeting, the WG last call would need to 
  occur before the end of October.

+ NSDB Draft Updates

  - Draft -07 Update
  http://www.ietf.org/mail-archive/web/nfsv4/current/msg08265.html

  - Draft -08 Update
  http://www.ietf.org/mail-archive/web/nfsv4/current/msg08277.html

  Draft -08 contains a table with suggested values for an NFSv4-only 
  FSL. See Section 5.1.3.2. Chuck Lever asked if consideration had 
  been given to creating splitting the NFS FLS in version specific 
  LDAP object classes, one for NFSv4.0, one for v4.1, etc.

  James described the rational for using a single object class. Although
  some of the fedfsNfsFsl's attributes are not returned in an NFSv4.0
  fs_locations attribute, their values are still potentially of interest 
  to the NFS server that is generating the NFSv4.0 referral. The 
  fedfsNfsTransFlagRdma is a good example. Although this flag is not 
  returned in a fs_locations, the NFS server generating an fs_locations 
  could list RDMA-accessible FSLs first in the fs_locations list if 
  the client was connected using RDMA.

  Rob observed that the rank and order fields are another good example
  of where the extra information is potentially useful to the NFS 
  server. Using the rank and order values to generate a v4.0 referral 
  is discussed in Section 2.4.3 of the NSDB draft.

  Offline, Chuck had asked how future extensions to the NFS referral 
  data would be incorporated into the LDAP schema. 

  James noted that the plan is to create LDAP AUXILIARY object classes
  for future extensions.

  - i18n Rules

  The -08 NSDB draft references the i18n rules in rfc3530bis.

  This is causing some concern since rfc3530bis will likely be 
  dependent on working being done in the precis WG.

  James sent an email to WG reflector pointing out the dependency between 
  the FedFS drafts and rfc3530bis.

  Sorin is concerned about waiting for precis since the wait could be
  unbounded.

  Craig agreed and noted that the time frame for completing rfc3530bis 
  and the FedFS drafts is not the same.

  Craig suggested not referencing unpublished documents. Instead, the 
  drafts could reference existing documents.

  James observed that referencing existing documents could
  result in a divergence between FedFS's i18n rules and rfc3530bis's 
  i18n rules.

  Spencer recommended that we focus on solving the problems related to 
  i18n and worry about the references later.

+ October Bake-a-thon Planning

  Chuck Lever is hoping to have a full mock up of a Linux NFS Server and 
  ADMIN server.

  Rob Thurlow asked if anyone would be bringing an implementation that 
  used LDAP over a secure channel. Chuck has some code mocked up for 
  this, but no way to testing it yet. Chuck and Rob will discuss what 
  is potentially testable in this area offline.

  We'll keep this as a standing agenda item until October.

+ LDAP Referrals

  James and Chuck have been discussing what the documents should recommend 
  about LDAP referrals.

  James listed some preliminary thoughts:

  - The LDAP standard defines LDAP referral following as optional. For 
    that reason, it seems reasonable for to allow an NSDB client to 
    optionally follow a referral.
  - If an LDAP client follows a referral, it MUST follow certain rules 
    (prevent looping). An NSDB client would also be required to follow 
    these rules.
  - An NSDB client would be required to support authentication of the 
    LDAP referral target.
  - An NSDB client would be allowed to selectively follow LDAP referrals 
    (perhaps only follow referrals received over a secure connection, or
    only follow referrals to a NSDB that supports TLS).
  - The NSDB client's (fileserver's) LDAP referral configuration would i
     not be exposed via the ONC RPC ADMIN protocol

  Rob said that this seemed like a quality of implementation issue. Rob 
  also pointed out that many implementations will use existing tools and 
  libraries to interact with LDAP. LDAP referral support is often available 
  in this software.

  James mentioned that the sNSDB code doesn't follow referrals.

  James will send a note to the WG mailing list with some proposed text 
  on this issue before the next meeting.

+ Procedure for Flushing the Fileserver's FSN-to-FSL cache

  Postponed until next time.

+ Meeting Schedule

  Our next meeting will be on September 2.

  On the agenda for a future meeting is to discuss Andy Adamson's 
  multi-domain-access draft. Andy is going to send a list of discussion 
  items to discuss to the WG alias. Andy is circulating a list of discussion 
  items with his co-authors. In the meantime, Andy would welcome comments on
  the -02 version.