[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