[Federated-fs] FedFS Meeting Minutes, 9/18/2008

James Lentini jlentini at netapp.com
Thu Sep 18 14:29:03 PDT 2008


FedFS Meeting Minutes, 9/18/2008
--------------------------------

Attendees
---------

Dan Ellard (BBN Technologies)
Craig Everhart (NetApp)
Paul Lemahieu (EMC)
James Lentini (NetApp)
Dan Lovinger (Microsoft)
Manoj Naik (IBM/ARC)
Renu Tewari (IBM/ARC)

Minutes
-------

+ multi-protocol support

  Q. Is what we have stored in the NSDB appropriate for a CIFS referral?
  A. This is a tricky question. It depends on what we want to do with a 
      CIFS referral. CIFS referrals are capable of re-directing to other 
      protocols. Is this something we want to take advantage of? 

  Q. Follow up: if we restrict ourselves to just CIFS clients, is there 
     enough data in the NSDB record to fill in the CIFS referral?
  A. It will take more time to answer this question.

  Dan Lovinger suggested that we not try to reflect the DFS namespace 
  in the FedFs namespace or attempt to masquerade as a DFS system. [NOTE: 
  these are my words, not his. Dan Lovinger please correct me if I 
  misinterpreted]

  We discussed the attributes of an SMB share. It was noted that an SMB share 
  is a similar to a NFS export conceptually.

  Q. Is there a way FedFs could guarantee that a CIFS referral and NFS referral 
     for the same FSN not point to different data?
  A. This is difficult to guarantee. The consensus seemed to be that we
     should not try to enforce consistency.

  Q. How would multiple protocols be integrated into our FSL concept?
  A. One possibility is for each FSL to contain a list of protocol specific 
     location entries. These entries would contain the server name, export
     name, protocol specific attributes, etc. The implication was that these
     location entries might be children of the FSL node in LDAP.

     The advantage of this approach would be to track the various protocol specific 
     locations in one place (as opposed to having separate FSLs for each
     protocol type). By grouping all the locations in one place, identifying configuration 
     errors is potentially easier and updates will occur in one place.

  We then discussed the different types of UNC names. There are two general
  types of names:

  1. //server/sharepath
  2. //domain.com/namespace/sharepath

  [NOTE: this was difficult to understand over the phone. Dan Lovinger please 
   correct me if I've misunderstood.]

  In the first instance, the "server" component is a hostname or IP address of
  the CIFS server exporting the specified sharepath.

  In the second format, the client recognizes that the first component is a 
  domain name. When this is observed, the second component is resolved using 
  Active Directory. 

  The Domain Locator protocol used for type #2 UNC paths is described in the 
  MS-DFSC document. The protocol is similar to Craig's DNS SRV record draft. 
  The MSFT protocol also uses DNS SRV records.

  Finally, we learned that new schema objects (such as the schema for our FedFs 
  objects) can be added to Active Directory. Left unresolved was if the
  recommended configuration would be to use Active Directory as an NSDB.

+ IETF NFSv4 WG Charter

  We discussed Spencer's mail to the fed-fs list announcing that the 
  NFSv4 working group was ready to expand its charter to include federated
  naming.

  Q. What drafts are should we re-publish a NFSv4 working group documents?
  A. There was consensus that the requirements, NSDB, admin, and DNS SRV 
     proposals should be published. We also agreed to create a document 
     describing our root fileset discussions. The re-publication of the 
     4 already published personal drafts does not need to wait for the 
     root fileset draft to be created.
  
  Q. What about our CIFS discussions?

  We are uncertain of whether the CIFS discussions should occur outside the
  NFSv4 working group. James Lentini will reply to Spencer's email and ask for
  guidance on this issue.

  James Lentini will send the changes he suggested to the NSDB document to the
  mailing list.

  Our goal will be to republish the FedFs documents next week. We will shoot
  for Monday.

+ Next week

  - root fileset


More information about the Federated-fs mailing list