From jlentini at netapp.com Wed Sep 3 08:34:39 2008 From: jlentini at netapp.com (James Lentini) Date: Wed, 3 Sep 2008 11:34:39 -0400 (EDT) Subject: [Federated-fs] Proposed FedFS Meeting Agenda for 9/4/2008 Message-ID: Tomorrow's meeting is at the usual time and place: Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST Dial-in: 1-888-765-3653 # 2354843 Please let me know if you would like to add topics to the agenda. Proposed Agenda --------------- + Dublin Demo Amy Weaver and Theresa Raj will show the 10 minute demo they gave at the IETF NFSv4 working group meeting in Dublin. To view the demo, please join the following Webex meeting: ---- Topic: FedFS Demo Date: Thursday, September 4, 2008 Time: 10:15 am, Pacific Daylight Time (GMT -07:00, San Francisco ) Meeting number: 927 435 560 Meeting password: test1 Please click the link below to see more information, or to join the meeting. NOTE: You do not need to register for a WebEx Account to attend this meeting. Just click on the link below and use the Meeting password: test1 https://netapp-meeting.webex.com/netapp-meeting/j.php?ED=106788442&UID=1056450467 [netapp-meeting.webex.com] ---- + LDAP transactions + Root Fileset From ellard at gmail.com Thu Sep 4 08:51:16 2008 From: ellard at gmail.com (Daniel Ellard) Date: Thu, 4 Sep 2008 11:51:16 -0400 Subject: [Federated-fs] No revised draft yet Message-ID: I apologize for the delay, but I don't have a revised version of the protocol spec yet. James and I are working out the logistics. -Dan From robert.thurlow at sun.com Thu Sep 4 11:35:57 2008 From: robert.thurlow at sun.com (Robert Thurlow) Date: Thu, 04 Sep 2008 12:35:57 -0600 Subject: [Federated-fs] Spencer's new contact info Message-ID: <48C02A8D.1090706@sun.com> Hi folks, Spencer is using this address on the nfsv4-wg alias now: shepler at storspeed.com Rob T From jlentini at netapp.com Thu Sep 4 12:03:49 2008 From: jlentini at netapp.com (James Lentini) Date: Thu, 4 Sep 2008 15:03:49 -0400 (EDT) Subject: [Federated-fs] FedFS Meeting Minutes, 9/4/2008 Message-ID: FedFS Meeting Minutes, 9/4/2008 ------------------------------- Attendees --------- Dan Ellard (BBN) Renu Tewari (IBM/ARC) Robert Thurlow (Sun) Paul Lemahieu (EMC) Manoj Naik (IBM/ARC) James Lentini (NetApp) Amy Weaver (NetApp) Mario Wurzl (EMC) Minutes ------- + LDAP transactions Mario will report back on this topic at the end of the month. + Root Fileset Q. What is the problem that the root fileset discussion is trying to solve? A. If you mount one of a set of root servers, customers want to see a common and consistent namespace. Q. Would the root fileset mechanism be unnecessary given a fileset replication protocol? A. If there was a replication protocol, the fileset would be replicated to other servers and therefore this would not be an issue. However, given the lack of a replication protocol, the root fileset mechanism is needed. The reason the root fileset has no data is so that it can be hosted in an NSDB (LDAP). The current proposal is for clients to locate a root file server via DNS SRV records and for the root fileset metadata (FSN and FSLs) to be stored in a set of root NSDBs. The lack of a common administration interface between DNS and NSDB records is a potential issue. The root fileset definition should be synchronized between both locations. How does a user determine where a given directory resides (e.g. their home directory)? Is this information stored in a file in the local file system or is it located through the global namespace? The normal fed-fs mechanisms for linking filesets through junctions and returning the corresponding client referrals can be used by the client to navigate the namespace to some particular directory (such as a home directory). How would a new root fileserver be bootstrapped? The root fileset information stored in the root NSDB would be used to create a new root file server. Renu will be producing a revised version of the fileset document. Craig will update his DNS SRV record draft. + Dublin Demo Amy Weaver and Theresa Raj reenacted the demo they gave at the IETF NFSv4 working group meeting in Dublin. They also showed a wire trace of the NSDB protocol traffic. The feedback was that this was the most unique and interesting part of the demonstration. + Next week agenda - root fileset - CIFS From spencer.shepler at gmail.com Thu Sep 4 12:25:08 2008 From: spencer.shepler at gmail.com (spencer shepler) Date: Thu, 4 Sep 2008 14:25:08 -0500 Subject: [Federated-fs] Spencer's new contact info In-Reply-To: <48C02A8D.1090706@sun.com> References: <48C02A8D.1090706@sun.com> Message-ID: I use this one as well. :-) Either will find me. On Thu, Sep 4, 2008 at 1:35 PM, Robert Thurlow wrote: > Hi folks, > > Spencer is using this address on the nfsv4-wg alias now: > > shepler at storspeed.com > > Rob T > From ellard at gmail.com Sun Sep 7 04:22:38 2008 From: ellard at gmail.com (Daniel Ellard) Date: Sun, 7 Sep 2008 07:22:38 -0400 Subject: [Federated-fs] sourceforge location of the NSDB prototype Message-ID: I've finally finished the sourceforge process and the draft of the "Simple NSDB" (SNSDB) code is available. You can browse the source at: snsdb.sourceforge.net or access the CVS repository at: snsdb.cvs.sourceforge.net -Dan From Craig.Everhart at netapp.com Mon Sep 8 07:50:49 2008 From: Craig.Everhart at netapp.com (Everhart, Craig) Date: Mon, 8 Sep 2008 10:50:49 -0400 Subject: [Federated-fs] FW: New Version Notification for draft-everhart-nfsv4-namespace-via-dns-srv-03 Message-ID: I re-submitted this draft, as we discussed in the call last Thursday. The only technical change was to the SECURITY section. I re-worded it to accommodate the new RFC status of the KITTEN group work (RFCs 5178 and 5179), and to include a recommended use of that functionality. Basically, it gives you a way to authenticate/authorize the result of the DNS SRV record lookup. Since NFS (4.1, anyway) recommends GSS-API RPC integrity for lookups of fs_locations information, those two mechanisms together let an organization authorize a specific namespace as the one it intended to publish. Probably the same root-namespace authentication value could be added with DNSSEC as with the new RFCs, but I don't think that the DNSEXT WG is getting to closure with that. Craig -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org] Sent: Monday, September 08, 2008 10:41 AM To: Everhart, Craig Cc: Adamson, Andy; jiayingz at umich.edu Subject: New Version Notification for draft-everhart-nfsv4-namespace-via-dns-srv-03 A new version of I-D, draft-everhart-nfsv4-namespace-via-dns-srv-03.txt has been successfuly submitted by Craig Everhart and posted to the IETF repository. Filename: draft-everhart-nfsv4-namespace-via-dns-srv Revision: 03 Title: Using DNS SRV to Specify a Global File Name Space with NFS version 4 Creation_date: 2008-09-05 WG ID: Independent Submission Number_of_pages: 11 Abstract: The NFS version 4 protocol provides a natural way for a collection of NFS file servers to collaborate in providing an organization-wide file name space. The DNS SRV RR allows a simple and appropriate way for an organization to publish the root of its name space, even to clients that might not be intimately associated with such an organization. DNS SRV can be used to join these organization-wide file name spaces together to allow construction of a global, uniform NFS version 4 file name space. This document refreshes the draft. The IETF Secretariat. From jlentini at netapp.com Thu Sep 11 06:48:10 2008 From: jlentini at netapp.com (James Lentini) Date: Thu, 11 Sep 2008 09:48:10 -0400 (EDT) Subject: [Federated-fs] FedFS meeting today (9/11/2008) Message-ID: This is a reminder that there will be a FedFs meeting today. Here are the logistics: Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST Dial-in: 1-888-765-3653 # 2354843 Last week, we planned to discuss the following topics today: - root fileset - CIFS From danlo at windows.microsoft.com Thu Sep 11 10:23:45 2008 From: danlo at windows.microsoft.com (Dan Lovinger) Date: Thu, 11 Sep 2008 10:23:45 -0700 Subject: [Federated-fs] FedFS meeting today (9/11/2008) In-Reply-To: References: Message-ID: <61E7CE7880A3B34EB078290285D0E8A5109B706C60@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Folks, To introduce myself, I work on DFSN in the Windows Server & Tools group here in Redmond. I'll be joining the conference call today to listen in, though at this time we will not be actively participating. With that caveat, I will be happy to answer questions about DFSN and CIFS that may come up. I believe several folks have already seen our protocol documentation on DFSN ([MS-DFSC] & [MS-DFSNM]). Thanks. -----Original Message----- From: federated-fs-bounces at sdsc.edu [mailto:federated-fs-bounces at sdsc.edu] On Behalf Of James Lentini Sent: Thursday, September 11, 2008 6:48 AM To: federated-fs at sdsc.edu Subject: [Federated-fs] FedFS meeting today (9/11/2008) This is a reminder that there will be a FedFs meeting today. Here are the logistics: Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST Dial-in: 1-888-765-3653 # 2354843 Last week, we planned to discuss the following topics today: - root fileset - CIFS From jlentini at netapp.com Thu Sep 11 13:53:43 2008 From: jlentini at netapp.com (James Lentini) Date: Thu, 11 Sep 2008 16:53:43 -0400 (EDT) Subject: [Federated-fs] FedFS Meeting Minutes, 9/11/2008 Message-ID: FedFS Meeting Minutes, 9/11/2008 -------------------------------- Attendees --------- Dan Ellard (BBN) Craig Everhart (NetApp) Robert Thurlow (Sun) James Lentini (NetApp) Dan Lovinger (Microsoft) Theresa Raj (NetApp) Minutes ------- + CIFS To date, the fedfs protocols and architecture have been NFS specific. The question has arisen if this infrastructure can accommodate CIFS. Dan Lovinger who works on DFSN in the Windows Server & Tools group at Microsoft joined us to answer questions on DFS, CIFS, and Windows. DFSN is the set of protocols described in the MS-DFSNM and MS-DFSC documents. - What is in a CIFS referral? CIFS referrals have roughly the same functionality as NFSv4 referrals with one interesting difference. NFSv4 assumes that referrals are to other NFSv4 servers (there is no support for other protocols). DFSN allows the referral to contain a link to be any protocol. The Windows client may interpret the link to be CIFS, WebDAV, NFS, or something else. A CIFS referral contains a UNC pathname describing the target of the referral. Out of the box, Vista comes with a CIFS and Webdav client. Other clients can be installed. Microsoft does not have an NFS client (v3,v4,..) at this time. Third party NFS clients are available from companies such as Hummingbird. - How does protocol switching work? On the CIFS client, the list of referral targets is delivered up from the CIFS client to the I/O subsystem. The I/O subsystem then evaluates the targets regardless of what protocol the referral arrived on. This behavior has been a part of Windows for around 8-10 years. The client's system configuration controls how a path is interrupted. The configuration prioritizes the list of protocols that will be used to interpret the UNC paths. As a result, two clients with different configurations could end up using two different protocols to access the same path. - How does the CIFS client detect a referral-capable share? DFSN is an extra feature of an SMB share. There are two types of shares, ones that are capable of generating a referral and ones that are not capable. The ones that are not referral capable are similar to NFSv3 servers. They are leaves in the namespace tree. The protocol is backward compatible with older version of CIFS that do not support referrals. A DFSN-aware CIFS client asks for a referral as the first operation when interacting with a share. This interrogation step is used to determine if the state machine for handling referrals needs to be available. If the share is unable to provide a referral, that state machine is de-activated for the given mount and a subsequent referral will not work. Therefore, all CIFS servers with FSNs that are internal nodes of the namespace tree must be DFSN capable. At the very least, the server providing the namespace root must be DFSN capable. - How does this interact with FedFs? Previously, we had assumed that an NFS client would always receive an referral to an NFS server and a CIFS client would always receive a referral to a CIFS server. CIFS is more flexible than we had realized. NFSv4 referrals are intended to be NFS only, although it is conceivable that NFS could be extended to allow referrals to other protocols. The task for FedFs is to keep the server informed of alternate paths. The mechanism by which this information is communicated to the client is a separate issue and the arena for discussing it is different. The consensus was that the client referral mechanisms are outside the scope of FedFs and that FedFs should concentrate on providing enough information to support the various referral mechanisms. We did not conclude if or how CIFS support would be added. Does a multi-protocol namespace open up interesting new applications? Could this answer the following quest: given the path of a CIFS share, what is the corresponding NFS export path or vice versa? One way to do this would be to walk the namespace from the root and map each FSN path in the CIFS (NFS) namespace to the FSN path in the NFS (CIFS) namespace. This would be rather expensive. It would be easier if the namespaces mapped one to one, although we didn't have time to discuss how that would be arranged. + Root Fileset With Renu and Paul absent, we only spent about 10 minutes on this topic. We came up with the following question for next week: What are the requirements for the root fileset? We also need to understand if this needs to be resolved completely before the working group would consider taking on FedFs. + Next week For next week: - more on root fileset - more on multi-protocol support From danlo at windows.microsoft.com Thu Sep 11 14:52:25 2008 From: danlo at windows.microsoft.com (Dan Lovinger) Date: Thu, 11 Sep 2008 14:52:25 -0700 Subject: [Federated-fs] FedFS Meeting Minutes, 9/11/2008 In-Reply-To: References: Message-ID: <61E7CE7880A3B34EB078290285D0E8A5109B706ED0@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> A few minor clarifications. Microsoft does have an NFSv3 client, which is an optional component (not in the default out-of-the-box install). I believe the context around that part of the discussion was whether we had an NFSv4 client, which we do not at this time. There are a number of third party NFS implementations, of which Hummingbird sprang most easily to mind. I am not aware of where they are on the NFSv4 track. Protocol switching has been part of Microsoft platforms since circa the late 1980's. Note that since CIFS/SMB is the only protocol which supports DFSN, it's the only source of referrals. The 8-10 year number was my hazy recollection of NT 4.0 SP2, which was the first vehicle DFSN showed up in. Double checking, Wikipedia mentions that date as 12/14/1996, creeping up on 12 years ago. Thanks. -----Original Message----- From: federated-fs-bounces at sdsc.edu [mailto:federated-fs-bounces at sdsc.edu] On Behalf Of James Lentini Sent: Thursday, September 11, 2008 1:54 PM To: federated-fs at sdsc.edu Subject: [Federated-fs] FedFS Meeting Minutes, 9/11/2008 FedFS Meeting Minutes, 9/11/2008 -------------------------------- Attendees --------- Dan Ellard (BBN) Craig Everhart (NetApp) Robert Thurlow (Sun) James Lentini (NetApp) Dan Lovinger (Microsoft) Theresa Raj (NetApp) Minutes ------- [...] Microsoft does not have an NFS client (v3,v4,..) at this time. Third party NFS clients are available from companies such as Hummingbird. [...] - How does protocol switching work? On the CIFS client, the list of referral targets is delivered up from the CIFS client to the I/O subsystem. The I/O subsystem then evaluates the targets regardless of what protocol the referral arrived on. This behavior has been a part of Windows for around 8-10 years. [...] From jlentini at netapp.com Thu Sep 18 07:12:41 2008 From: jlentini at netapp.com (James Lentini) Date: Thu, 18 Sep 2008 10:12:41 -0400 (EDT) Subject: [Federated-fs] Proposed agenda for today's call (9/18) Message-ID: Please let me know if you have additional agenda items. Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST Dial-in: 1-888-765-3653 # 2354843 Proposed Agenda --------------- + root fileset + multi-protocol support + IETF NFSv4 WG Charter From spencer.shepler at gmail.com Thu Sep 18 07:39:26 2008 From: spencer.shepler at gmail.com (spencer shepler) Date: Thu, 18 Sep 2008 09:39:26 -0500 Subject: [Federated-fs] Proposed agenda for today's call (9/18) In-Reply-To: References: Message-ID: On Thu, Sep 18, 2008 at 9:12 AM, James Lentini wrote: > > Please let me know if you have additional agenda items. > > Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST > Dial-in: 1-888-765-3653 # 2354843 > > Proposed Agenda > --------------- > + root fileset > > + multi-protocol support > > + IETF NFSv4 WG Charter I mentioned this to James in off-list email but as everyone knows, the work/ideas developed around federated-fs have been well received within the NFSv4 WG and by our area advisor. Brian and I have details to work through for the charter update but that should not delay the protocol definition, etc. I suggested to James that the current I-Ds be resubmitted at NFSv4 WG I-Ds. This means their names need to change to something like: draft-ietf-nfsv4- and will start at draft version "00". Once they are submitted I will approve and we can move the discussions over to the nfsv4 at ietf.org working group alias. Spencer From jlentini at netapp.com Thu Sep 18 07:46:44 2008 From: jlentini at netapp.com (James Lentini) Date: Thu, 18 Sep 2008 10:46:44 -0400 (EDT) Subject: [Federated-fs] Proposed agenda for today's call (9/18) In-Reply-To: References: Message-ID: On Thu, 18 Sep 2008, spencer shepler wrote: > On Thu, Sep 18, 2008 at 9:12 AM, James Lentini wrote: > > > > Please let me know if you have additional agenda items. > > > > Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST > > Dial-in: 1-888-765-3653 # 2354843 > > > > Proposed Agenda > > --------------- > > + root fileset > > > > + multi-protocol support > > > > + IETF NFSv4 WG Charter > > I mentioned this to James in off-list email but as everyone > knows, the work/ideas developed around federated-fs have > been well received within the NFSv4 WG and by our > area advisor. Brian and I have details to work through > for the charter update but that should not delay the > protocol definition, etc. I suggested to James that the > current I-Ds be resubmitted at NFSv4 WG I-Ds. This > means their names need to change to something like: > draft-ietf-nfsv4- > and will start at draft version "00". > > Once they are submitted I will approve and we can move > the discussions over to the nfsv4 at ietf.org working group > alias. > > Spencer > Spencer, will you be able to join us on the call today? From spencer.shepler at gmail.com Thu Sep 18 08:09:24 2008 From: spencer.shepler at gmail.com (Spencer Shepler) Date: Thu, 18 Sep 2008 10:09:24 -0500 Subject: [Federated-fs] Proposed agenda for today's call (9/18) In-Reply-To: References: Message-ID: Sent from my iPhone On Sep 18, 2008, at 9:46 AM, James Lentini wrote: > > > On Thu, 18 Sep 2008, spencer shepler wrote: > >> On Thu, Sep 18, 2008 at 9:12 AM, James Lentini >> wrote: >>> >>> Please let me know if you have additional agenda items. >>> >>> Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST >>> Dial-in: 1-888-765-3653 # 2354843 >>> >>> Proposed Agenda >>> --------------- >>> + root fileset >>> >>> + multi-protocol support >>> >>> + IETF NFSv4 WG Charter >> >> I mentioned this to James in off-list email but as everyone >> knows, the work/ideas developed around federated-fs have >> been well received within the NFSv4 WG and by our >> area advisor. Brian and I have details to work through >> for the charter update but that should not delay the >> protocol definition, etc. I suggested to James that the >> current I-Ds be resubmitted at NFSv4 WG I-Ds. This >> means their names need to change to something like: >> draft-ietf-nfsv4- >> and will start at draft version "00". >> >> Once they are submitted I will approve and we can move >> the discussions over to the nfsv4 at ietf.org working group >> alias. >> >> Spencer >> > > Spencer, will you be able to join us on the call today? Unfortunately, no. Please send email if there are follow up questions. From jlentini at netapp.com Thu Sep 18 10:39:43 2008 From: jlentini at netapp.com (James Lentini) Date: Thu, 18 Sep 2008 13:39:43 -0400 (EDT) Subject: [Federated-fs] FedFs text for charter Message-ID: As the NFSv4 working group expands their charter to include the issues of constructing a federated namespace, we have an opportunity to help them with the additional text for the charter. Craig and I have put together this piece of text as a draft for the modifications for the working group charter. Please let us know if you have comments. Spencer and Brian will have the final decision on what text to use. We may also need a set of milestones. --- + Federated Namespace The NFSv4 protocol provides a referral mechanism that allows a server to redirect a client to another server. The working group will produce documents describing a mechanism for creating a federated namespace using the NFSv4 protocol's referral capabilities. In addition, these documents will describe a convention for a shared global namespace. The file system federation protocol will enable file access and namespace traversal across collections of independently administered fileservers. No modifications will be made to the NFS client to server protocol. From ellard at gmail.com Thu Sep 18 10:43:39 2008 From: ellard at gmail.com (Daniel Ellard) Date: Thu, 18 Sep 2008 13:43:39 -0400 Subject: [Federated-fs] FedFs text for charter In-Reply-To: References: Message-ID: Per our discussion on the conf call, here's the prose from last March. (the names of the drafts will have changes, of course) On behalf of myself, Craig Everhart (NetApp), Renu Tewari (IBM), and Manoj Naik (IBM): As discussed at the NFSv4 WG meeting in Philadelphia at the beginning of March, we request that the work we have been doing to develop a requirements document for a federated naming system that can be used to implement a federated file system, and protocols that satisfy the requirements, be taken up for review by the NFSv4 WG. The first milestone will be to refine the requirements document so that it can be published as an informational RFC. The next milestone is to publish the specifications for the proposed protocols, based on the requirements document, as draft RFCs for discussion in the NFSv4 WG. The starting points for the WG discussion are a preliminary requirements document and protocol specification. These documents are the result of more than a year of open discussion in the form of BoF sessions at FAST'07 and FAST'08, discussion on an open mailing list (federated-fs at ucsd.edu), and frequent open conference calls (announced on the federated-fs list). Participants in this discussion have included representatives from NetApp, IBM, Sun, EMC, Rainfinity, CITI, and others. The current state of the work is summarized in the following personal drafts: draft-ellard-nfsv4-federated-fs-00 draft-tewari-nfsv4-federated-fs-protocol-01 draft-ellard-nfsv4-federated-fs-admin-00 -Dan On Thu, Sep 18, 2008 at 1:39 PM, James Lentini wrote: > > As the NFSv4 working group expands their charter to include the issues > of constructing a federated namespace, we have an opportunity to help > them with the additional text for the charter. Craig and I have put > together this piece of text as a draft for the modifications for the > working group charter. Please let us know if you have comments. > > Spencer and Brian will have the final decision on what text to use. > > We may also need a set of milestones. > > --- > > + Federated Namespace > > The NFSv4 protocol provides a referral mechanism that allows a > server to redirect a client to another server. The working group > will produce documents describing a mechanism for creating a > federated namespace using the NFSv4 protocol's referral > capabilities. In addition, these documents will describe a > convention for a shared global namespace. The file system > federation protocol will enable file access and namespace > traversal across collections of independently administered > fileservers. No modifications will be made to the > NFS client to server protocol. > > From jlentini at netapp.com Thu Sep 18 14:29:03 2008 From: jlentini at netapp.com (James Lentini) Date: Thu, 18 Sep 2008 17:29:03 -0400 (EDT) Subject: [Federated-fs] FedFS Meeting Minutes, 9/18/2008 Message-ID: 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 From jlentini at netapp.com Thu Sep 18 14:34:40 2008 From: jlentini at netapp.com (James Lentini) Date: Thu, 18 Sep 2008 17:34:40 -0400 (EDT) Subject: [Federated-fs] Proposed agenda for today's call (9/18) In-Reply-To: References: Message-ID: On Thu, 18 Sep 2008, spencer shepler wrote: > On Thu, Sep 18, 2008 at 9:12 AM, James Lentini wrote: > > > > Please let me know if you have additional agenda items. > > > > Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST > > Dial-in: 1-888-765-3653 # 2354843 > > > > Proposed Agenda > > --------------- > > + root fileset > > > > + multi-protocol support > > > > + IETF NFSv4 WG Charter > > I mentioned this to James in off-list email but as everyone > knows, the work/ideas developed around federated-fs have > been well received within the NFSv4 WG and by our > area advisor. Brian and I have details to work through > for the charter update but that should not delay the > protocol definition, etc. I suggested to James that the > current I-Ds be resubmitted at NFSv4 WG I-Ds. This > means their names need to change to something like: > draft-ietf-nfsv4- > and will start at draft version "00". > > Once they are submitted I will approve and we can move > the discussions over to the nfsv4 at ietf.org working group > alias. > > Spencer > Spencer, This is great news. We are all excited about moving the FedFs working inside the NFSv4 working group. Recently we've been discussing how FedFs could be used to create a federated CIFS namespace. Where would you recommend we discuss this topic? We could continue to use this mailing list as a forum for the CIFS-related discussions and concentrate exclusively on the NFS issues on the nfsv4 at ietf.org mailing list. From spencer.shepler at gmail.com Thu Sep 18 15:16:36 2008 From: spencer.shepler at gmail.com (spencer shepler) Date: Thu, 18 Sep 2008 17:16:36 -0500 Subject: [Federated-fs] Proposed agenda for today's call (9/18) In-Reply-To: References: Message-ID: I would suggest that all discussions end up on the nfsv4 wg alias given that the functionality will eventually land somewhere or have some impact on the federated naming drafts and protocols. Spencer On Thu, Sep 18, 2008 at 4:34 PM, James Lentini wrote: > > > On Thu, 18 Sep 2008, spencer shepler wrote: > >> On Thu, Sep 18, 2008 at 9:12 AM, James Lentini wrote: >> > >> > Please let me know if you have additional agenda items. >> > >> > Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST >> > Dial-in: 1-888-765-3653 # 2354843 >> > >> > Proposed Agenda >> > --------------- >> > + root fileset >> > >> > + multi-protocol support >> > >> > + IETF NFSv4 WG Charter >> >> I mentioned this to James in off-list email but as everyone >> knows, the work/ideas developed around federated-fs have >> been well received within the NFSv4 WG and by our >> area advisor. Brian and I have details to work through >> for the charter update but that should not delay the >> protocol definition, etc. I suggested to James that the >> current I-Ds be resubmitted at NFSv4 WG I-Ds. This >> means their names need to change to something like: >> draft-ietf-nfsv4- >> and will start at draft version "00". >> >> Once they are submitted I will approve and we can move >> the discussions over to the nfsv4 at ietf.org working group >> alias. >> >> Spencer >> > > Spencer, > > This is great news. We are all excited about moving the FedFs working > inside the NFSv4 working group. > > Recently we've been discussing how FedFs could be used to create a > federated CIFS namespace. Where would you recommend we discuss this > topic? > > We could continue to use this mailing list as a forum for the > CIFS-related discussions and concentrate exclusively on the NFS issues > on the nfsv4 at ietf.org mailing list. > From jlentini at netapp.com Fri Sep 19 07:58:42 2008 From: jlentini at netapp.com (James Lentini) Date: Fri, 19 Sep 2008 10:58:42 -0400 (EDT) Subject: [Federated-fs] updated NSDB draft Message-ID: Attached is a revised draft of the NSDB protocol specification. Please let me know if you have any comments by 5:00 PM PST Monday, 9/22. As we discussed on the call yesterday, our goal is to republish this draft and the requirements, admin protocol, and DNS SRV drafts as NFSv4 wg drafts next week. Here is a diff of the changes: --- draft-tewari-nfsv4-federated-fs-protocol-03.txt 2008-09-19 10:00:48.736339000 -0400 +++ draft-tewari-nfsv4-federated-fs-protocol.txt 2008-09-19 10:56:48.371746000 -0400 @@ -2,12 +2,14 @@ Network Working Group D. Ellard -Internet-Draft C. Everhart -Intended status: Standards Track NetApp, Inc. -Expires: February 6, 2009 R. Tewari +Internet-Draft BBN Technologies +Intended status: Standards Track C. Everhart +Expires: March 23, 2009 J. Lentini + NetApp, Inc. + R. Tewari M. Naik IBM Almaden - August 5, 2008 + September 19, 2008 NSDB Protocol for Federated Filesystems @@ -36,7 +38,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on February 6, 2009. + This Internet-Draft will expire on March 23, 2009. Copyright Notice @@ -50,11 +52,9 @@ Copyright Notice - - -Ellard, et al. Expires February 6, 2009 [Page 1] +Ellard, et al. Expires March 23, 2009 [Page 1] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 Abstract @@ -75,16 +75,19 @@ Table of Contents 2.1. Protocol Goals . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of Features and Concepts . . . . . . . . . . . . . . 7 3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2. Fileset . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. Fileset and Fileset Name (FSN) . . . . . . . . . . . . . . 7 3.3. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 8 - 3.3.1. Mutual Consistency across Fileset Locations . . . . . 9 - 3.4. Namespace Repository (NSDB) . . . . . . . . . . . . . . . 9 + 3.3.1. Mutual Consistency across Fileset Locations . . . . . 8 + 3.4. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 9 3.5. Mount Points, Junctions and Referrals . . . . . . . . . . 10 - 3.6. Federation Root FileServers . . . . . . . . . . . . . . . 11 + 3.6. Federation Root FileServers . . . . . . . . . . . . . . . 10 3.7. Federation Root FileSet . . . . . . . . . . . . . . . . . 11 3.8. Fileservers . . . . . . . . . . . . . . . . . . . . . . . 11 3.9. File-access Clients . . . . . . . . . . . . . . . . . . . 11 - 4. Interaction with NFSv4 . . . . . . . . . . . . . . . . . . . . 12 + 4. Interaction with client protocols . . . . . . . . . . . . . . 12 + 4.1. Interaction with NFSv4 . . . . . . . . . . . . . . . . . . 12 + 4.2. Interaction with other distributed file system + protocols . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Finding the local NSDB . . . . . . . . . . . . . . . . . . . . 13 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 14 @@ -102,46 +105,44 @@ Table of Contents 8.2.4. nsdbName . . . . . . . . . . . . . . . . . . . . . . . 20 8.2.5. fslHost . . . . . . . . . . . . . . . . . . . . . . . 20 8.2.6. fslPath . . . . . . . . . . . . . . . . . . . . . . . 20 - 8.2.7. annotation . . . . . . . . . . . . . . . . . . . . . . 21 - 8.2.8. descr . . . . . . . . . . . . . . . . . . . . . . . . 21 - 8.2.9. fslUuid . . . . . . . . . . . . . . . . . . . . . . . 21 -Ellard, et al. Expires February 6, 2009 [Page 2] +Ellard, et al. Expires March 23, 2009 [Page 2] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 - 8.2.10. junctionKey . . . . . . . . . . . . . . . . . . . . . 21 - 8.2.11. childFsnUuid . . . . . . . . . . . . . . . . . . . . . 21 - 8.2.12. childNsdbName . . . . . . . . . . . . . . . . . . . . 22 + 8.2.7. fslUuid . . . . . . . . . . . . . . . . . . . . . . . 20 + 8.2.8. type . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.2.9. currency . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.2.10. annotation . . . . . . . . . . . . . . . . . . . . . . 21 + 8.2.11. junctionKey . . . . . . . . . . . . . . . . . . . . . 21 + 8.2.12. childFsnUuid . . . . . . . . . . . . . . . . . . . . . 22 + 8.2.13. childNsdbName . . . . . . . . . . . . . . . . . . . . 22 8.3. LDAP Objects . . . . . . . . . . . . . . . . . . . . . . . 22 8.3.1. FsnObject . . . . . . . . . . . . . . . . . . . . . . 22 8.3.2. FslObject . . . . . . . . . . . . . . . . . . . . . . 22 - 8.3.3. JunctionObject . . . . . . . . . . . . . . . . . . . . 22 + 8.3.3. JunctionObject . . . . . . . . . . . . . . . . . . . . 23 9. NSDB Protocol Operations . . . . . . . . . . . . . . . . . . . 24 9.1. Administrative NSDB Operations . . . . . . . . . . . . . . 24 9.1.1. Creating an FSN . . . . . . . . . . . . . . . . . . . 25 9.1.2. Deleting an FSN . . . . . . . . . . . . . . . . . . . 26 9.1.3. Mount an FSN . . . . . . . . . . . . . . . . . . . . . 26 9.1.4. Unmount an FSN . . . . . . . . . . . . . . . . . . . . 27 - 9.1.5. Create an FSL . . . . . . . . . . . . . . . . . . . . 28 + 9.1.5. Create an FSL . . . . . . . . . . . . . . . . . . . . 27 9.1.6. Delete an FSL . . . . . . . . . . . . . . . . . . . . 28 - 9.1.7. Update an FSL . . . . . . . . . . . . . . . . . . . . 29 - 9.1.8. Examining an FSL . . . . . . . . . . . . . . . . . . . 29 - 9.1.9. Finding the children FSNs of a fileset . . . . . . . . 29 - 9.2. Fileserver to NSDB Operations . . . . . . . . . . . . . . 30 - 9.2.1. Looking up FSLs for an FSN . . . . . . . . . . . . . . 30 + 9.1.7. Update an FSL . . . . . . . . . . . . . . . . . . . . 28 + 9.1.8. Finding the children FSNs of a fileset . . . . . . . . 29 + 9.2. Fileserver to NSDB Operations . . . . . . . . . . . . . . 29 + 9.2.1. Looking up FSLs for an FSN . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 11. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 32 12. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 14. Normative References . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 - Intellectual Property and Copyright Statements . . . . . . . . . . 39 - - + Intellectual Property and Copyright Statements . . . . . . . . . . 40 @@ -163,10 +164,9 @@ Internet-Draft NSDB Protocol for Feder - -Ellard, et al. Expires February 6, 2009 [Page 3] +Ellard, et al. Expires March 23, 2009 [Page 3] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 1. Requirements notation @@ -220,9 +220,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 4] +Ellard, et al. Expires March 23, 2009 [Page 4] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 2. Introduction @@ -276,9 +276,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 5] +Ellard, et al. Expires March 23, 2009 [Page 5] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 also have an arbitrary number of administrative entities responsible @@ -332,9 +332,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 6] +Ellard, et al. Expires March 23, 2009 [Page 6] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 3. Overview of Features and Concepts @@ -364,12 +364,12 @@ Internet-Draft NSDB Protocol for Feder that should permit traversal into another namespace at defined junction points. -3.2. Fileset +3.2. Fileset and Fileset Name (FSN) A fileset is defined to be a container of data and is the basic unit of data management. It is uniquely represented by the fileset name (FSN). An FSN is considered unique across the federation. An FSN - contains information sufficient to locate the namespace repository + contains information sufficient to locate the namespace database (NSDB) that holds authoritative information about it and an identifier, called fsn_uuid, that identifies it on that NSDB. After an FSN is created, it is associated with a fileset location (FSL) on @@ -380,78 +380,52 @@ Internet-Draft NSDB Protocol for Feder contains authoritative information for this FSN. FsnUuid: a 128-bit UUID (universally unique identifier), conforming - to [RFC4122], that is used to uniquely identify an FSN. - + to [RFC4122], that is used to uniquely identify an FSN. An NSDB + SHOULD ensure that no two FSNs it stores have the same FsnUuid. -Ellard, et al. Expires February 6, 2009 [Page 7] +Ellard, et al. Expires March 23, 2009 [Page 7] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 3.3. Fileset Location (FSL) An FSL represents the location where the fileset data resides. Each - FSL maps to a host:path pair on a file server. An FSL may also have + FSL contains a host:path pair on a file server. An FSL may also have additional attributes. Each location has an associated type that determines the protocol(s) that may be used to access its data. Type information can be used to decide the list of locations that will be - returned to the client. It also has associated status information. - Other attributes associated with an FSL are based on the NFSv4.1 - fs_locations_info attribute[RFCTBD]. - - struct FSL { - utf8string host_fqdn; - utf8string pathname; - FSL_ATTR attrs; - }; + returned to the client. Other attributes associated with an FSL are + based on the NFSv4.1 fs_locations_info attribute[RFCTBD]. Each FSL consists of: - host_fqdn: the name of the host fileserver storing the physical data - - pathname: the exported pathname at that host fileserver - - attrs: additional attributes for this FSL, as described in the - FSL_ATTR structure + FslHost: the fully qualified domain name of the host fileserver + storing the physical data + FslPathname: the exported pathname at that host fileserver - struct FSL_ATTR { - protocol_t type; - int32_t currency; - annotation_t annotations<>; - fs_status_t status; - opaque_t info<>; - } + FslUuid: the 128-bit UUID of the FSL - The attributes associated with each FSL are: + Type: the protocol that should be used to access this FSL (e.g. + NFSv4) - type: the protocol(s) supported by the fileserver hosting this FSL - - currency: the time lag of this FSL represented as the number of time + Currency: the time lag of this FSL represented as the number of time units it lags the latest version as defined by the NFSv4.1 - fs_locations_info attribute. A currency value of 0 represents the - latest version. Currency values are less than or equal to zero - - annotations: a list of name/value pairs that can be interpreted by - an individual NSDB. The semantics of the name/value pair is not - defined by this protocol and is intended to be used by higher- - level administration protocols - - - -Ellard, et al. Expires February 6, 2009 [Page 8] - -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 - - - status: fls_status as defined by the NFSv4.1 status attribute - - info: as defined in NFSv4.1 fs_locations_info attribute + fs_locations_server's fls_currency field. A currency value of 0 + represents the latest version. Currency values are less than or + equal to zero + + Annotations: a list of name/value pairs that can be interpreted by a + fileserver and used to generate a referral. The semantics of the + name/value pair is not defined by this protocol and is intended to + be used by higher-level protocols. This field MAY be used to + store the NFSv4.1 fl_locations_server's fls_info values 3.3.1. Mutual Consistency across Fileset Locations @@ -467,6 +441,14 @@ Internet-Draft NSDB Protocol for Feder write location. The federation protocols, however, cannot prevent subsequent changes to a read-only location nor guarantee point-in- time consistency of a read-only location if the read-write location + + + +Ellard, et al. Expires March 23, 2009 [Page 8] + +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 + + is changing. Regardless of the type, all locations exist at the same mount point @@ -485,7 +467,7 @@ Internet-Draft NSDB Protocol for Feder raises a concern for NFSv3 fileservers, which the federation protocol may support, that may lack such control. -3.4. Namespace Repository (NSDB) +3.4. Namespace Database (NSDB) The NSDB service is a federation-wide service that provides interfaces to define, update, and query FSN information and FSN to @@ -498,13 +480,6 @@ Internet-Draft NSDB Protocol for Feder analogous to that between the DNS service and a particular DNS server. - - -Ellard, et al. Expires February 6, 2009 [Page 9] - -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 - - The term local NSDB is shorthand for an NSDB location that is known a priori to a server. It is typically located within the same federation member as the server, but this is not required. A local @@ -519,13 +494,26 @@ Internet-Draft NSDB Protocol for Feder location to resolve a junction. Each NSDB location supports an LDAP interface and can be accessed by an LDAP client. + An NSDB may be replicated throught the federation. The mechanism by + which this is acheived is outside the scope of this document. Many + LDAP implementations support replication. These features MAY be used + + + +Ellard, et al. Expires March 23, 2009 [Page 9] + +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 + + + to replicate the NSDB. + 3.5. Mount Points, Junctions and Referrals A mount point is a directory in a parent fileset where a target fileset may be attached. If a client traverses the path leading from - the root of the namespace to the mount point of a fileset it should - be able to access the data in that fileset (assuming appropriate - permissions). + the root of the namespace to the mount point of a target fileset it + should be able to access the data in that target fileset (assuming + appropriate permissions). The directory where a fileset is mounted is represented by a junction in the underlying filesystem. In other words, a junction can be @@ -538,9 +526,10 @@ Internet-Draft NSDB Protocol for Feder What data is used by the underlying file system to represent the junction is not defined by this protocol. The essential property is that the server must be able to find, given the junction, the FSN for - the target fileset. The FSN (as described earlier) contains both the - NSDB location of the authoritative NSDB location and the FsnUuid (a - UUID for the fileset). + the target fileset. The mechanism by which the server maps a + junction to an FSN is outside the scope of this document. The FSN + (as described earlier) contains both the NSDB location of the + authoritative NSDB location and the FsnUuid (a UUID for the fileset). When a client traversal reaches a junction, the client is referred to a list of FSLs associated with the FSN that was the target of the @@ -553,14 +542,6 @@ Internet-Draft NSDB Protocol for Feder fileset is mounted in the namespace. Filesets can be nested -- a fileset can be mounted under another fileset. - - - -Ellard, et al. Expires February 6, 2009 [Page 10] - -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 - - 3.6. Federation Root FileServers A set of designated fileservers that render the common federation- @@ -572,6 +553,14 @@ Internet-Draft NSDB Protocol for Feder fileservers. If a client mounts from a non-root fileserver then it can traverse the part of the namespace that is visible starting from that fileserver. A client can mount multiple individual filesets + + + +Ellard, et al. Expires March 23, 2009 [Page 10] + +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 + + from multiple non-root fileservers and chose to navigate the namespace in any manner. How the client discovers the root fileserver(s), if one is defined, is not in the scope of the @@ -600,7 +589,9 @@ Internet-Draft NSDB Protocol for Feder 3.9. File-access Clients File access clients are standard off-the-shelf NAS clients that - access file data using the NFSv4 protocol. + access file data using the NFSv4 protocol or some other protocol. + + @@ -612,23 +603,32 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 11] - -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 -4. Interaction with NFSv4 - The federation protocol is compatible with the requirements of NFSv4 - referral mechanisms as defined in [RFC3530]. +Ellard, et al. Expires March 23, 2009 [Page 11] + +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 + + +4. Interaction with client protocols + +4.1. Interaction with NFSv4 + + The federation protocol is compatible with the requirements of NFSv4 + referral mechanisms as defined in [RFC3530]. +4.2. Interaction with other distributed file system protocols + The federation protocol does not mandate a specific format for + pathnames. Therefore it is possible to store the pathnames used by a + variety of distributed file systems, including CIFS. @@ -668,20 +668,16 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 12] +Ellard, et al. Expires March 23, 2009 [Page 12] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 5. Finding the local NSDB - The local NSDB may be used for finding the mapping from the server's - local representation of a junction to an FSN. How the mapping is - resolved is implementation-specific. The fed-fs protocol does not - mandate how and if a local NSDB is defined or located. A fileserver - could choose to have a special configuration setup for defining the - local or default NSDB in a manner similar to a resolv.conf file for - DNS. + The fed-fs protocol does not mandate how and if a local NSDB is + defined or located. A fileserver's local NSDB configuration could be + specified using a simple text file or some other mechanism. @@ -724,9 +720,13 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 13] + + + + +Ellard, et al. Expires March 23, 2009 [Page 13] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 6. Examples @@ -767,26 +767,26 @@ Internet-Draft NSDB Protocol for Feder 2. Request that the NSDB node register a new FSN for the fileset. - The FSN may either be chosen by the NSDB node or by the server. - The latter case is used if the fileset is being restored, perhaps - as part of disaster recovery, and the server wishes to specify - the FSN in order to permit existing junctions that reference that - FSN to work again. + The FSN UUID is choosen by the administrator or generated + automatically by administration software. The former case is + used if the fileset is being restored, perhaps as part of + disaster recovery, and the administrator wishes to specify the + FSN UUID in order to permit existing junctions that reference + that FSN to work again. - At this point, the FSN exists, but its location is unspecified. + At this point, the FSN exists, but its fileset locations are + unspecified. - 3. Send the FSN, the local volume path, the export path, and the - export options for the local implementation of the fileset to the -Ellard, et al. Expires February 6, 2009 [Page 14] +Ellard, et al. Expires March 23, 2009 [Page 14] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 - NSDB node. Annotations about the FSN or the location may also be - sent. + 3. Send the FSN, the export path, the type, the currency, and + annotations for the fileset to the NSDB node. The NSDB node records this info and creates the initial FSL for the fileset. @@ -836,9 +836,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 15] +Ellard, et al. Expires March 23, 2009 [Page 15] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 of FSLs. @@ -892,9 +892,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 16] +Ellard, et al. Expires March 23, 2009 [Page 16] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 7. Error Definitions @@ -948,9 +948,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 17] +Ellard, et al. Expires March 23, 2009 [Page 17] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 ERR_WRONGSEC The security mechanism being used by the client for the @@ -1004,9 +1004,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 18] +Ellard, et al. Expires March 23, 2009 [Page 18] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 8. Mapping the NSDB onto LDAP @@ -1017,12 +1017,12 @@ Internet-Draft NSDB Protocol for Feder used in order to ensure compatibility between different implementations. The second section defines the new LDAP attribute types and the subsequent sections describe the new object types and - specifies how the distinguished name of each object instance MUST be - constructed. + specify how the distinguished name (DN) of each object instance MUST + be constructed. 8.1. Basic LDAP Configuration - The base name (or suffix) for all of DNs used by the NSDB schema is + The base name (or suffix) for all DNs used by the NSDB schema is "dc=fed-fs,dc=com". The DN of the priviledged LDAP user is, by convention, @@ -1033,14 +1033,12 @@ Internet-Draft NSDB Protocol for Feder database or view privilidged information must be made aware of the new DN. - It MUST be possible for the anonymous (unauthenticated) user perform - LDAP queries that access the NSDB data. + It MUST be possible for the anonymous (unauthenticated) user to + perform LDAP queries that access the NSDB data. - All implementation SHOULD use the same schema, or, at minimum, a + All implementations SHOULD use the same schema, or, at minimum, a schema that includes all of the objects, with each of the attributes, - named in the following sections. The complete schema SHOULD be - defined as part of the protocol (or as a separate RFC) when its - definition is complete. + named in the following sections. 8.2. LDAP Attributes @@ -1057,24 +1055,24 @@ Internet-Draft NSDB Protocol for Feder It MAY also be useful, for purposes of debugging or annotation, to permit a fedfsUuid to include members of a more general class of + strings. -Ellard, et al. Expires February 6, 2009 [Page 19] - -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Ellard, et al. Expires March 23, 2009 [Page 19] + +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 - strings. - A fedfsUuid is a single-valued attribute. + A fedfsUuid is a single-valued LDAP attribute. 8.2.2. fedfsNetAddr - An fedfsNetAddr is the locative name of a TCP/IP-based network - service. It MUST be able to express network locations as IPv4, IPv6, - and DNS FQDN notations. It may include a port specifier, or the port - may be implicit in context. + A fedfsNetAddr is the locative name of a network service. It MUST be + able to express network locations as IPv4, IPv6, and DNS FQDN + notations. It may include a port specifier, or the port may be + implicit in context. There MAY be a special syntax at some point for specifying a SVR record (for a DNS FQDN). @@ -1111,45 +1109,56 @@ Internet-Draft NSDB Protocol for Feder This attribute is single-valued. +8.2.7. fslUuid + Each FSL must have a UUID associated with it, which serves as part of + its DN. - -Ellard, et al. Expires February 6, 2009 [Page 20] +Ellard, et al. Expires March 23, 2009 [Page 20] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 -8.2.7. annotation + The fslUuid attribute is a subclass of fedfsUuid. - An annotation of an NSDB object. + This attribute is single-valued. - This attribute is multi-valued; an object type that permits - annotations may have any number of annotations per instance. +8.2.8. type - This attribute is a placeholder; it has not been well-defined at the - date of this draft. + The type of an FSL. -8.2.8. descr + This attribute is used to specify the distribute file system protocol + that can be used to access an FSL. The following values are defined + for this field: - A descriptive attribute containing information about an NSDB object. + nfsv4 : the FSL is accessible via the NFSv4 protocol. - This attribute is single-valued. + Values for other protocols may be defined at a later time. - This attribute is a placeholder; it has not been well-defined at the - date of this draft. + This attribute is single-valued. -8.2.9. fslUuid +8.2.9. currency - Each FSL must have a UUID associated with it, which serves as part of - its DN. + The currency of an FSL. - The fslUuid attribute is a subclass of fedfsUuid. + This attribute is used to populate the NFSv4.1 fs_locations_info's + currency field. This attribute is single-valued. -8.2.10. junctionKey +8.2.10. annotation + + An annotation of an NSDB object. + + This attribute is multi-valued; an object type that permits + annotations may have any number of annotations per instance. + + This attribute is a placeholder; it has not been well-defined at the + date of this draft. + +8.2.11. junctionKey Each junction has a unique junctionKey that is used to distinguish it from other junctions that may refer to the same child fileset and/or @@ -1159,25 +1168,24 @@ Internet-Draft NSDB Protocol for Feder This attribute is single-valued. -8.2.11. childFsnUuid - The fsnUuid of the target of a junction. - The childFsnUuid attribute is a subclass of fsnUuid. - - This attribute is single-valued. +Ellard, et al. Expires March 23, 2009 [Page 21] + +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 +8.2.12. childFsnUuid + The fsnUuid of the target of a junction. -Ellard, et al. Expires February 6, 2009 [Page 21] - -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 + The childFsnUuid attribute is a subclass of fsnUuid. + This attribute is single-valued. -8.2.12. childNsdbName +8.2.13. childNsdbName The nsdbName of the target of a junction. @@ -1191,10 +1199,7 @@ Internet-Draft NSDB Protocol for Feder An FsnObject represents an FSN. - The required attributes of an FsnObject are an fsnUuid and nsdbName. - - An FsnObject MAY also have descr and annotation attributes, but - neither is required. + The required attributes of an FsnObject are an nsdbName and fsnUuid. The DN of an FSN is assumed to take the following form: "fsnUuid=FSNUUID,dc=fed-fs,dc=com", where fsnUuid is the UUID of the @@ -1207,11 +1212,10 @@ Internet-Draft NSDB Protocol for Feder An FslObject represents an FSL. - The required attributes of an FslObject are an fsnUuid, nsdbName, - fslHost, fslPath, and fslUuid. + The required attributes of an FslObject are an nsdbName, fsnUuid, + fslHost, fslPath, and fslUuid, type, currency, and annotations. - An FslObject MAY also have descr and annotation attributes, but - neither is required. + An FslObject's currency and annotations attributes MAY be null. The DN of an FSL is required to take the following form: "fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com". @@ -1221,18 +1225,18 @@ Internet-Draft NSDB Protocol for Feder filter for "objectType = fslObject". (If you want to be doubly careful, you can also filter by the nsdbName.) -8.3.3. JunctionObject - - An JunctionObject captures the relationship between a fileset and its - children (if any). The children FSNs are FSNs that appear in -Ellard, et al. Expires February 6, 2009 [Page 22] +Ellard, et al. Expires March 23, 2009 [Page 22] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 + +8.3.3. JunctionObject + An JunctionObject captures the relationship between a fileset and its + children (if any). The children FSNs are FSNs that appear in junctions in the fileset named by the fsnUuid and nsdbName attributes of the parent FSN. @@ -1280,13 +1284,9 @@ Internet-Draft NSDB Protocol for Feder - - - - -Ellard, et al. Expires February 6, 2009 [Page 23] +Ellard, et al. Expires March 23, 2009 [Page 23] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 9. NSDB Protocol Operations @@ -1314,7 +1314,7 @@ Internet-Draft NSDB Protocol for Feder unnecessary to describe the LDAP operations in detail, because the operations are ordinary LDAP operations to query and update records. However, we do not require that an NSDB location implement a complete - NSDB service, and therefore we define in these sections the minimum + LDAP service, and therefore we define in these sections the minimum level of LDAP functionality required to implement an NSDB location. The NSDB sub-protocols are defined in the next two sub-sections. @@ -1322,7 +1322,7 @@ Internet-Draft NSDB Protocol for Feder The third sub-protocol defines the queries or other requests that are sent to a fileset server in order to get information from it or to modify the state of the fileset server in a manner related to the - federation protocols. The primary purpose of this for an + federation protocols. The primary purpose of this protocol is for an administrator to create or delete a junction or fileset or discover related information about a particular fileset server. @@ -1340,9 +1340,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 24] +Ellard, et al. Expires March 23, 2009 [Page 24] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 We require that each NSDB location be able to act as an LDAP server @@ -1369,9 +1369,9 @@ Internet-Draft NSDB Protocol for Feder with an fsnUuid of FSNUUID and an NsdbName of NSDB. The NSDB location that receives the request SHOULD check that the - NSDB matches its own value and return an ERR_WRONGNSDB error if does - not. This is to ensure that an FSN is always created by the NSDB - location encoded within the FSN as its owner. + NSDB matches its own value and return an ERR_WRONGNSDB error if it + does not. This is to ensure that an FSN is always created by the + NSDB location encoded within the FSN as its owner. The NSDB location that receives the request SHOULD check all of the attributes for validity and consistency, but this is not generally @@ -1396,9 +1396,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 25] +Ellard, et al. Expires March 23, 2009 [Page 25] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 dn: fsnUuid=FSNUUID,dc=fed-fs,dc=com @@ -1409,11 +1409,10 @@ Internet-Draft NSDB Protocol for Feder 9.1.2. Deleting an FSN - Deletes the Fileset with the given FSN. This assumes that all the - FSLs related to that FSN have already been deleted. If FSL records - for this FSN still exist in the database of the NSDB that receives - this request, then this function MUST return with an ERR_NOTEMPTY - error. + Deletes the given fileset name. This assumes that all the FSLs + related to that FSN have already been deleted. If FSL records for + this FSN still exist in the database of the NSDB that receives this + request, then this function MUST return with an ERR_NOTEMPTY error. Note that the FSN delete function only removes the fileset from the namespace (by removing the records for that FSN from the NSDB @@ -1427,9 +1426,9 @@ Internet-Draft NSDB Protocol for Feder 9.1.2.1. LDAP Request - The admin then sends an LDAP DELETE request to the NSDB server to - remove the FsnObject from the NSDB server. An example LDIF for the - delete request is shown below. + The admin sends an LDAP DELETE request to the NSDB server to remove + the FsnObject from the NSDB server. An example LDIF for the delete + request is shown below. dn: fsnUuid=FSNUUID,dc=fed-fs,dc=com changeType: delete @@ -1449,15 +1448,15 @@ Internet-Draft NSDB Protocol for Feder The parent/child relation is used to indicate how the filesets in the federation are related. The names "parent" and "child" should not be taken literally. A fileset can have no parent (if it is a root + fileset). A fileset may also have any number of parents. In theory, -Ellard, et al. Expires February 6, 2009 [Page 26] +Ellard, et al. Expires March 23, 2009 [Page 26] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 - fileset). A fileset may also have any number of parents. In theory, the parent of a fileset may also be its child, although in practice this is deprecated. @@ -1501,24 +1500,19 @@ Internet-Draft NSDB Protocol for Feder dn: key=KEY,fsnUuid=FSNUUID,dc=fed-fs,dc=com changeType: delete +9.1.5. Create an FSL + Creates a new Fileset location at the given location denoted by HOST + and PATH for the given FSN. Normally an FSL is identified by the + HOST:PATH pair. A UUID is an optional way to identify an FSL if it - - - -Ellard, et al. Expires February 6, 2009 [Page 27] +Ellard, et al. Expires March 23, 2009 [Page 27] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 -9.1.5. Create an FSL - - Creates a new Fileset location at the given location denoted by HOST - and PATH for the given FSN. An fsl_uuid may be provided as an - optional UUID for the FSL. Normally an FSL is identified by the - HOST:PATH pair. A UUID is an optional way to identify an FSL if it is recovered to a different HOST:PATH after a backup/restore. If the FSL belongs to an FSN that has another FSN mounted under it then there would be a related junction_create operation. @@ -1540,8 +1534,9 @@ Internet-Draft NSDB Protocol for Feder fslUuid: UUID fslHost: HOST fslPath: PATH - type: nfs4 - version: VERSION + type: file access protocol type (e.g. nfs4) + currency: CURRENCY + annotation: ANNOTATION 9.1.6. Delete an FSL @@ -1557,18 +1552,6 @@ Internet-Draft NSDB Protocol for Feder dn: fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com changeType: delete - - - - - - - -Ellard, et al. Expires February 6, 2009 [Page 28] - -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 - - 9.1.7. Update an FSL Update the attributes of a given FSL. This command results in a @@ -1578,22 +1561,21 @@ Internet-Draft NSDB Protocol for Feder PARAGRAPH DESCRIBING ERRORS -9.1.7.1. LDAP Request - dn: fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com - changeType: modify - replace: ATTRIBUTE-TYPE -9.1.8. Examining an FSL - Find all attributes of a given FSL from the FSLObject stored at the - NSDB location. +Ellard, et al. Expires March 23, 2009 [Page 28] + +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 - ERRORS: ERR_OK ERR_NOTFOUND ERR_INVALID ERR_PERM - WHERE IS THE LDAP FOR THIS? -DJE +9.1.7.1. LDAP Request -9.1.9. Finding the children FSNs of a fileset + dn: fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com + changeType: modify + replace: ATTRIBUTE-TYPE + +9.1.8. Finding the children FSNs of a fileset The NSDB also tracks information about which filesets are "children" of others. A fileset X is a child of fileset Y if there is a @@ -1616,15 +1598,6 @@ Internet-Draft NSDB Protocol for Feder of the implementation (but it may also eliminate some very useful functionality). - - - - -Ellard, et al. Expires February 6, 2009 [Page 29] - -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 - - LDAP Request Search base: fsnUuid=FSNUUID, dc=fed-fs, dc=com Search scope: onelevel @@ -1643,6 +1616,15 @@ Internet-Draft NSDB Protocol for Feder ERRORS: ERR_OK ERR_NOTFOUND ERR_INVALID ERR_PERM + + + + +Ellard, et al. Expires March 23, 2009 [Page 29] + +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 + + LDAP Request Search base: fsnUuid=FSNUUID, dc=fed-fs, dc=com Search scope: onelevel @@ -1676,14 +1658,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 30] - -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 -10. Security Considerations - To be added. @@ -1699,6 +1676,25 @@ Internet-Draft NSDB Protocol for Feder +Ellard, et al. Expires March 23, 2009 [Page 30] + +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 + + +10. Security Considerations + + Both LDAP and NFSv4 provide security mechanisms. When used in + conjunction with the federated file system protocols described in + this document, the use of these mechanisms is RECOMMENDED. + Specifically, the use of RPCSEC_GSS [RFC2203] [RFC2743] is + RECOMMENDED on all connections between a client and filerserver. For + all LDAP connections established by the federated file system + protocols, TLS [RFC4346] [RFC4513] is RECOMMENDED. + + + + + @@ -1732,9 +1728,13 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 31] + + + + +Ellard, et al. Expires March 23, 2009 [Page 31] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 11. IANA Requirements @@ -1788,9 +1788,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 32] +Ellard, et al. Expires March 23, 2009 [Page 32] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 12. Conclusions @@ -1844,9 +1844,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 33] +Ellard, et al. Expires March 23, 2009 [Page 33] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 13. Glossary @@ -1900,9 +1900,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 34] +Ellard, et al. Expires March 23, 2009 [Page 34] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 FSN (Fileset name): A platform-independent and globally unique name @@ -1956,9 +1956,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 35] +Ellard, et al. Expires March 23, 2009 [Page 35] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 The namespace provided by a server collection could be part of the @@ -2012,9 +2012,9 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 36] +Ellard, et al. Expires March 23, 2009 [Page 36] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 14. Normative References @@ -2068,21 +2068,21 @@ Internet-Draft NSDB Protocol for Feder -Ellard, et al. Expires February 6, 2009 [Page 37] +Ellard, et al. Expires March 23, 2009 [Page 37] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 Authors' Addresses Daniel Ellard - NetApp, Inc. - 1601 Trapelo Rd, Suite 16 - Waltham, MA 02451 + BBN Technologies + 10 Moulton Street + Cambridge, MA 02138 US - Phone: +1 781-768-5421 - Email: ellard at netapp.com + Phone: +1 617-873-8000 + Email: ellard at google.com Craig Everhart @@ -2095,6 +2095,16 @@ Authors' Addresses Email: everhart at netapp.com + James Lentini + NetApp, Inc. + 1601 Trapelo Rd, Suite 16 + Waltham, MA 02451 + US + + Phone: +1 781-768-5359 + Email: jlentini at netapp.com + + Renu Tewari IBM Almaden 650 Harry Rd @@ -2104,6 +2114,21 @@ Authors' Addresses Email: tewarir at us.ibm.com + + + + + + + + + + +Ellard, et al. Expires March 23, 2009 [Page 38] + +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 + + Manoj Naik IBM Almaden 650 Harry Rd @@ -2124,9 +2149,40 @@ Authors' Addresses -Ellard, et al. Expires February 6, 2009 [Page 38] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ellard, et al. Expires March 23, 2009 [Page 39] -Internet-Draft NSDB Protocol for Federated Filesystems August 2008 +Internet-Draft NSDB Protocol for Federated Filesystems September 2008 Full Copyright Statement @@ -2180,5 +2236,5 @@ Acknowledgment -Ellard, et al. Expires February 6, 2009 [Page 39] +Ellard, et al. Expires March 23, 2009 [Page 40] -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: draft-tewari-nfsv4-federated-fs-protocol.txt Url: https://lists.sdsc.edu/pipermail/federated-fs/attachments/20080919/6f2c709f/draft-tewari-nfsv4-federated-fs-protocol.txt From Craig.Everhart at netapp.com Fri Sep 19 09:14:03 2008 From: Craig.Everhart at netapp.com (Everhart, Craig) Date: Fri, 19 Sep 2008 12:14:03 -0400 Subject: [Federated-fs] updated NSDB draft In-Reply-To: References: Message-ID: Three comments are included. I hope I'm interpreting the "diff" correctly. > -----Original Message----- > From: Lentini, James > Sent: Friday, September 19, 2008 10:59 AM > To: federated-fs at sdsc.edu > Subject: [Federated-fs] updated NSDB draft > > > Attached is a revised draft of the NSDB protocol > specification. Please let me know if you have any comments by > 5:00 PM PST Monday, 9/22. > > As we discussed on the call yesterday, our goal is to > republish this draft and the requirements, admin protocol, > and DNS SRV drafts as > NFSv4 wg drafts next week. > > Here is a diff of the changes: > > --- draft-tewari-nfsv4-federated-fs-protocol-03.txt > 2008-09-19 10:00:48.736339000 -0400 > +++ draft-tewari-nfsv4-federated-fs-protocol.txt > 2008-09-19 10:56:48.371746000 -0400 > @@ -2,12 +2,14 @@ > > > Network Working Group > D. Ellard > -Internet-Draft > C. Everhart > -Intended status: Standards Track > NetApp, Inc. > -Expires: February 6, 2009 > R. Tewari > +Internet-Draft BBN > Technologies > +Intended status: Standards Track > C. Everhart > +Expires: March 23, 2009 > J. Lentini > + > NetApp, Inc. > + R. > +Tewari > > M. Naik > > IBM Almaden > - > August 5, 2008 > + September 19, > + 2008 > > > NSDB Protocol for Federated Filesystems @@ > -36,7 +38,7 @@ Status of this Memo > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > - This Internet-Draft will expire on February 6, 2009. > + This Internet-Draft will expire on March 23, 2009. > > Copyright Notice > > @@ -50,11 +52,9 @@ Copyright Notice > > > > - > - > -Ellard, et al. Expires February 6, 2009 > [Page 1] > +Ellard, et al. Expires March 23, 2009 > [Page 1] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > Abstract > @@ -75,16 +75,19 @@ Table of Contents > 2.1. Protocol Goals . . . . . . . . . . . . . . . . . > . . . . . 5 > 3. Overview of Features and Concepts . . . . . . . . . > . . . . . 7 > 3.1. Namespace . . . . . . . . . . . . . . . . . . . > . . . . . 7 > - 3.2. Fileset . . . . . . . . . . . . . . . . . . . . > . . . . . 7 > + 3.2. Fileset and Fileset Name (FSN) . . . . . . . . . > . . . . . > + 7 > 3.3. Fileset Location (FSL) . . . . . . . . . . . . . > . . . . . 8 > - 3.3.1. Mutual Consistency across Fileset Locations > . . . . . 9 > - 3.4. Namespace Repository (NSDB) . . . . . . . . . . > . . . . . 9 > + 3.3.1. Mutual Consistency across Fileset Locations > . . . . . 8 > + 3.4. Namespace Database (NSDB) . . . . . . . . . . . > . . . . . > + 9 > 3.5. Mount Points, Junctions and Referrals . . . . . > . . . . . 10 > - 3.6. Federation Root FileServers . . . . . . . . . . > . . . . . 11 > + 3.6. Federation Root FileServers . . . . . . . . . . > . . . . . > + 10 > 3.7. Federation Root FileSet . . . . . . . . . . . . > . . . . . 11 > 3.8. Fileservers . . . . . . . . . . . . . . . . . . > . . . . . 11 > 3.9. File-access Clients . . . . . . . . . . . . . . > . . . . . 11 > - 4. Interaction with NFSv4 . . . . . . . . . . . . . . . > . . . . . 12 > + 4. Interaction with client protocols . . . . . . . . . > . . . . . 12 > + 4.1. Interaction with NFSv4 . . . . . . . . . . . . . > . . . . . 12 > + 4.2. Interaction with other distributed file system > + protocols . . . . . . . . . . . . . . . . . . . > . . . . . > + 12 > 5. Finding the local NSDB . . . . . . . . . . . . . . . > . . . . . 13 > 6. Examples . . . . . . . . . . . . . . . . . . . . . . > . . . . . 14 > 6.1. Create a Fileset and its FSL(s) . . . . . . . . > . . . . . 14 @@ -102,46 +105,44 @@ Table of Contents > 8.2.4. nsdbName . . . . . . . . . . . . . . . . . . > . . . . . 20 > 8.2.5. fslHost . . . . . . . . . . . . . . . . . . > . . . . . 20 > 8.2.6. fslPath . . . . . . . . . . . . . . . . . . > . . . . . 20 > - 8.2.7. annotation . . . . . . . . . . . . . . . . . > . . . . . 21 > - 8.2.8. descr . . . . . . . . . . . . . . . . . . . > . . . . . 21 > - 8.2.9. fslUuid . . . . . . . . . . . . . . . . . . > . . . . . 21 > > > > -Ellard, et al. Expires February 6, 2009 > [Page 2] > +Ellard, et al. Expires March 23, 2009 > [Page 2] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > - 8.2.10. junctionKey . . . . . . . . . . . . . . . . > . . . . . 21 > - 8.2.11. childFsnUuid . . . . . . . . . . . . . . . . > . . . . . 21 > - 8.2.12. childNsdbName . . . . . . . . . . . . . . . > . . . . . 22 > + 8.2.7. fslUuid . . . . . . . . . . . . . . . . . . > . . . . . 20 > + 8.2.8. type . . . . . . . . . . . . . . . . . . . . > . . . . . 21 > + 8.2.9. currency . . . . . . . . . . . . . . . . . . > . . . . . 21 > + 8.2.10. annotation . . . . . . . . . . . . . . . . . > . . . . . 21 > + 8.2.11. junctionKey . . . . . . . . . . . . . . . . > . . . . . 21 > + 8.2.12. childFsnUuid . . . . . . . . . . . . . . . . > . . . . . 22 > + 8.2.13. childNsdbName . . . . . . . . . . . . . . . > . . . . . > + 22 > 8.3. LDAP Objects . . . . . . . . . . . . . . . . . . > . . . . . 22 > 8.3.1. FsnObject . . . . . . . . . . . . . . . . . > . . . . . 22 > 8.3.2. FslObject . . . . . . . . . . . . . . . . . > . . . . . 22 > - 8.3.3. JunctionObject . . . . . . . . . . . . . . . > . . . . . 22 > + 8.3.3. JunctionObject . . . . . . . . . . . . . . . > . . . . . > + 23 > 9. NSDB Protocol Operations . . . . . . . . . . . . . . > . . . . . 24 > 9.1. Administrative NSDB Operations . . . . . . . . . > . . . . . 24 > 9.1.1. Creating an FSN . . . . . . . . . . . . . . > . . . . . 25 > 9.1.2. Deleting an FSN . . . . . . . . . . . . . . > . . . . . 26 > 9.1.3. Mount an FSN . . . . . . . . . . . . . . . . > . . . . . 26 > 9.1.4. Unmount an FSN . . . . . . . . . . . . . . . > . . . . . 27 > - 9.1.5. Create an FSL . . . . . . . . . . . . . . . > . . . . . 28 > + 9.1.5. Create an FSL . . . . . . . . . . . . . . . > . . . . . > + 27 > 9.1.6. Delete an FSL . . . . . . . . . . . . . . . > . . . . . 28 > - 9.1.7. Update an FSL . . . . . . . . . . . . . . . > . . . . . 29 > - 9.1.8. Examining an FSL . . . . . . . . . . . . . . > . . . . . 29 > - 9.1.9. Finding the children FSNs of a fileset . . . > . . . . . 29 > - 9.2. Fileserver to NSDB Operations . . . . . . . . . > . . . . . 30 > - 9.2.1. Looking up FSLs for an FSN . . . . . . . . . > . . . . . 30 > + 9.1.7. Update an FSL . . . . . . . . . . . . . . . > . . . . . 28 > + 9.1.8. Finding the children FSNs of a fileset . . . > . . . . . 29 > + 9.2. Fileserver to NSDB Operations . . . . . . . . . > . . . . . 29 > + 9.2.1. Looking up FSLs for an FSN . . . . . . . . . > . . . . . > + 29 > 10. Security Considerations . . . . . . . . . . . . . . > . . . . . 31 > 11. IANA Requirements . . . . . . . . . . . . . . . . . > . . . . . 32 > 12. Conclusions . . . . . . . . . . . . . . . . . . . . > . . . . . 33 > 13. Glossary . . . . . . . . . . . . . . . . . . . . . . > . . . . . 34 > 14. Normative References . . . . . . . . . . . . . . . . > . . . . . 37 > Authors' Addresses . . . . . . . . . . . . . . . . . . . > . . . . . 38 > - Intellectual Property and Copyright Statements . . . . . > . . . . . 39 > - > - > + Intellectual Property and Copyright Statements . . . . . > . . . . . > + 40 > > > > @@ -163,10 +164,9 @@ Internet-Draft NSDB Protocol for Feder > > > > - > -Ellard, et al. Expires February 6, 2009 > [Page 3] > +Ellard, et al. Expires March 23, 2009 > [Page 3] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > 1. Requirements notation > @@ -220,9 +220,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 4] > +Ellard, et al. Expires March 23, 2009 > [Page 4] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > 2. Introduction > @@ -276,9 +276,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 5] > +Ellard, et al. Expires March 23, 2009 > [Page 5] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > also have an arbitrary number of administrative entities > responsible > @@ -332,9 +332,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 6] > +Ellard, et al. Expires March 23, 2009 > [Page 6] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > 3. Overview of Features and Concepts > @@ -364,12 +364,12 @@ Internet-Draft NSDB Protocol for Feder > that should permit traversal into another namespace at defined > junction points. > > -3.2. Fileset > +3.2. Fileset and Fileset Name (FSN) > > A fileset is defined to be a container of data and is the > basic unit > of data management. It is uniquely represented by the > fileset name > (FSN). An FSN is considered unique across the federation. An FSN > - contains information sufficient to locate the namespace repository > + contains information sufficient to locate the namespace database > (NSDB) that holds authoritative information about it and an > identifier, called fsn_uuid, that identifies it on that > NSDB. After > an FSN is created, it is associated with a fileset > location (FSL) on > @@ -380,78 +380,52 @@ Internet-Draft NSDB Protocol for Feder > contains authoritative information for this FSN. > > FsnUuid: a 128-bit UUID (universally unique identifier), > conforming > - to [RFC4122], that is used to uniquely identify an FSN. > - > + to [RFC4122], that is used to uniquely identify an > FSN. An NSDB > + SHOULD ensure that no two FSNs it stores have the same FsnUuid. > > > > > > > -Ellard, et al. Expires February 6, 2009 > [Page 7] > +Ellard, et al. Expires March 23, 2009 > [Page 7] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > 3.3. Fileset Location (FSL) > > An FSL represents the location where the fileset data > resides. Each > - FSL maps to a host:path pair on a file server. An FSL > may also have > + FSL contains a host:path pair on a file server. An FSL may also > + have > additional attributes. Each location has an associated type that > determines the protocol(s) that may be used to access its > data. Type > information can be used to decide the list of locations > that will be > - returned to the client. It also has associated status > information. > - Other attributes associated with an FSL are based on the NFSv4.1 > - fs_locations_info attribute[RFCTBD]. > - > - struct FSL { > - utf8string host_fqdn; > - utf8string pathname; > - FSL_ATTR attrs; > - }; > + returned to the client. Other attributes associated with > an FSL are > + based on the NFSv4.1 fs_locations_info attribute[RFCTBD]. > > Each FSL consists of: > > - host_fqdn: the name of the host fileserver storing the > physical data > - > - pathname: the exported pathname at that host fileserver > - > - attrs: additional attributes for this FSL, as described in the > - FSL_ATTR structure > + FslHost: the fully qualified domain name of the host fileserver > + storing the physical data > > + FslPathname: the exported pathname at that host fileserver > > - struct FSL_ATTR { > - protocol_t type; > - int32_t currency; > - annotation_t annotations<>; > - fs_status_t status; > - opaque_t info<>; > - } > + FslUuid: the 128-bit UUID of the FSL > > - The attributes associated with each FSL are: > + Type: the protocol that should be used to access this FSL (e.g. > + NFSv4) > > - type: the protocol(s) supported by the fileserver > hosting this FSL > - > - currency: the time lag of this FSL represented as the > number of time > + Currency: the time lag of this FSL represented as the number of > + time > units it lags the latest version as defined by the NFSv4.1 > - fs_locations_info attribute. A currency value of 0 > represents the > - latest version. Currency values are less than or equal to zero > - > - annotations: a list of name/value pairs that can be > interpreted by > - an individual NSDB. The semantics of the name/value > pair is not > - defined by this protocol and is intended to be used by higher- > - level administration protocols > - > - > - > -Ellard, et al. Expires February 6, 2009 > [Page 8] > - > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > - > - > - status: fls_status as defined by the NFSv4.1 status attribute > - > - info: as defined in NFSv4.1 fs_locations_info attribute > + fs_locations_server's fls_currency field. A currency > value of 0 > + represents the latest version. Currency values are > less than or > + equal to zero Did we lose some text above here? > + > + Annotations: a list of name/value pairs that can be > interpreted by a > + fileserver and used to generate a referral. The > semantics of the > + name/value pair is not defined by this protocol and is > intended to > + be used by higher-level protocols. This field MAY be used to > + store the NFSv4.1 fl_locations_server's fls_info values Ditto with lost text? > > 3.3.1. Mutual Consistency across Fileset Locations > > @@ -467,6 +441,14 @@ Internet-Draft NSDB Protocol for Feder > write location. The federation protocols, however, cannot prevent > subsequent changes to a read-only location nor guarantee point-in- > time consistency of a read-only location if the > read-write location > + > + > + > +Ellard, et al. Expires March 23, 2009 > [Page 8] > + > > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > + > + > is changing. > > Regardless of the type, all locations exist at the same > mount point > @@ -485,7 +467,7 @@ Internet-Draft NSDB Protocol for Feder > raises a concern for NFSv3 fileservers, which the > federation protocol > may support, that may lack such control. > > -3.4. Namespace Repository (NSDB) > +3.4. Namespace Database (NSDB) > > The NSDB service is a federation-wide service that provides > interfaces to define, update, and query FSN information and FSN to > @@ -498,13 +480,6 @@ Internet-Draft NSDB Protocol for Feder > analogous to that between the DNS service and a particular DNS > server. > > - > - > -Ellard, et al. Expires February 6, 2009 > [Page 9] > - > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > - > - > The term local NSDB is shorthand for an NSDB location > that is known a > priori to a server. It is typically located within the same > federation member as the server, but this is not > required. A local > @@ -519,13 +494,26 @@ Internet-Draft NSDB Protocol for Feder > location to resolve a junction. Each NSDB location > supports an LDAP > interface and can be accessed by an LDAP client. > > + An NSDB may be replicated throught the federation. The > mechanism by > + which this is acheived is outside the scope of this > document. Many > + LDAP implementations support replication. These features MAY be > + used > + > + > + > +Ellard, et al. Expires March 23, 2009 > [Page 9] > + > > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > + > + > + to replicate the NSDB. > + > 3.5. Mount Points, Junctions and Referrals > > A mount point is a directory in a parent fileset where a target > fileset may be attached. If a client traverses the path > leading from > - the root of the namespace to the mount point of a fileset > it should > - be able to access the data in that fileset (assuming appropriate > - permissions). > + the root of the namespace to the mount point of a target > fileset it > + should be able to access the data in that target fileset (assuming > + appropriate permissions). > > The directory where a fileset is mounted is represented > by a junction > in the underlying filesystem. In other words, a junction can be > @@ -538,9 +526,10 @@ Internet-Draft NSDB Protocol for Feder > What data is used by the underlying file system to represent the > junction is not defined by this protocol. The essential > property is > that the server must be able to find, given the junction, > the FSN for > - the target fileset. The FSN (as described earlier) > contains both the > - NSDB location of the authoritative NSDB location and the > FsnUuid (a > - UUID for the fileset). > + the target fileset. The mechanism by which the server maps a > + junction to an FSN is outside the scope of this document. The FSN > + (as described earlier) contains both the NSDB location of the > + authoritative NSDB location and the FsnUuid (a UUID for > the fileset). > > When a client traversal reaches a junction, the client is > referred to > a list of FSLs associated with the FSN that was the target of the > @@ -553,14 +542,6 @@ Internet-Draft NSDB Protocol for Feder > fileset is mounted in the namespace. Filesets can be nested -- a > fileset can be mounted under another fileset. > > - > - > - > -Ellard, et al. Expires February 6, 2009 > [Page 10] > - > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > - > - > 3.6. Federation Root FileServers > > A set of designated fileservers that render the common federation- > @@ -572,6 +553,14 @@ Internet-Draft NSDB Protocol for Feder > fileservers. If a client mounts from a non-root > fileserver then it > can traverse the part of the namespace that is visible > starting from > that fileserver. A client can mount multiple individual filesets > + > + > + > +Ellard, et al. Expires March 23, 2009 > [Page 10] > + > > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > + > + > from multiple non-root fileservers and chose to navigate the > namespace in any manner. How the client discovers the root > fileserver(s), if one is defined, is not in the scope of the Hm--I don't recall the text here, but it may want to point to the DNS SRV draft. > @@ -600,7 +589,9 @@ Internet-Draft NSDB Protocol for Feder > 3.9. File-access Clients > > File access clients are standard off-the-shelf NAS clients that > - access file data using the NFSv4 protocol. > + access file data using the NFSv4 protocol or some other protocol. > + > + > > > > @@ -612,23 +603,32 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 11] > - > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > > > -4. Interaction with NFSv4 > > - The federation protocol is compatible with the > requirements of NFSv4 > - referral mechanisms as defined in [RFC3530]. > > > > > > > +Ellard, et al. Expires March 23, 2009 > [Page 11] > + > > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > + > + > +4. Interaction with client protocols > + > +4.1. Interaction with NFSv4 > + > + The federation protocol is compatible with the > requirements of NFSv4 > + referral mechanisms as defined in [RFC3530]. > > +4.2. Interaction with other distributed file system protocols > > + The federation protocol does not mandate a specific format for > + pathnames. Therefore it is possible to store the > pathnames used by a > + variety of distributed file systems, including CIFS. > > > > @@ -668,20 +668,16 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 12] > +Ellard, et al. Expires March 23, 2009 > [Page 12] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > 5. Finding the local NSDB > > - The local NSDB may be used for finding the mapping from > the server's > - local representation of a junction to an FSN. How the mapping is > - resolved is implementation-specific. The fed-fs protocol does not > - mandate how and if a local NSDB is defined or located. A > fileserver > - could choose to have a special configuration setup for > defining the > - local or default NSDB in a manner similar to a > resolv.conf file for > - DNS. > + The fed-fs protocol does not mandate how and if a local NSDB is > + defined or located. A fileserver's local NSDB > configuration could be > + specified using a simple text file or some other mechanism. > > > > @@ -724,9 +720,13 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 13] > + > + > + > + > +Ellard, et al. Expires March 23, 2009 > [Page 13] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > 6. Examples > @@ -767,26 +767,26 @@ Internet-Draft NSDB Protocol for Feder > > 2. Request that the NSDB node register a new FSN for the fileset. > > - The FSN may either be chosen by the NSDB node or by > the server. > - The latter case is used if the fileset is being > restored, perhaps > - as part of disaster recovery, and the server wishes to specify > - the FSN in order to permit existing junctions that > reference that > - FSN to work again. > + The FSN UUID is choosen by the administrator or generated > + automatically by administration software. The former case is > + used if the fileset is being restored, perhaps as part of > + disaster recovery, and the administrator wishes to specify the > + FSN UUID in order to permit existing junctions that reference > + that FSN to work again. > > - At this point, the FSN exists, but its location is > unspecified. > + At this point, the FSN exists, but its fileset locations are > + unspecified. > > - 3. Send the FSN, the local volume path, the export path, and the > - export options for the local implementation of the > fileset to the > > > > -Ellard, et al. Expires February 6, 2009 > [Page 14] > +Ellard, et al. Expires March 23, 2009 > [Page 14] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > - NSDB node. Annotations about the FSN or the location > may also be > - sent. > + 3. Send the FSN, the export path, the type, the currency, and > + annotations for the fileset to the NSDB node. > > The NSDB node records this info and creates the > initial FSL for > the fileset. > @@ -836,9 +836,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 15] > +Ellard, et al. Expires March 23, 2009 > [Page 15] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > of FSLs. > @@ -892,9 +892,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 16] > +Ellard, et al. Expires March 23, 2009 > [Page 16] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > 7. Error Definitions > @@ -948,9 +948,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 17] > +Ellard, et al. Expires March 23, 2009 > [Page 17] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > ERR_WRONGSEC The security mechanism being used by the > client for the > @@ -1004,9 +1004,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 18] > +Ellard, et al. Expires March 23, 2009 > [Page 18] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > 8. Mapping the NSDB onto LDAP > @@ -1017,12 +1017,12 @@ Internet-Draft NSDB Protocol for Feder > used in order to ensure compatibility between different > implementations. The second section defines the new LDAP > attribute > types and the subsequent sections describe the new object > types and > - specifies how the distinguished name of each object > instance MUST be > - constructed. > + specify how the distinguished name (DN) of each object > instance MUST > + be constructed. > > 8.1. Basic LDAP Configuration > > - The base name (or suffix) for all of DNs used by the NSDB > schema is > + The base name (or suffix) for all DNs used by the NSDB schema is > "dc=fed-fs,dc=com". > > The DN of the priviledged LDAP user is, by convention, > @@ -1033,14 +1033,12 @@ Internet-Draft NSDB Protocol for Feder > database or view privilidged information must be made aware of the > new DN. > > - It MUST be possible for the anonymous (unauthenticated) > user perform > - LDAP queries that access the NSDB data. > + It MUST be possible for the anonymous (unauthenticated) user to > + perform LDAP queries that access the NSDB data. > > - All implementation SHOULD use the same schema, or, at minimum, a > + All implementations SHOULD use the same schema, or, at minimum, a > schema that includes all of the objects, with each of the > attributes, > - named in the following sections. The complete schema SHOULD be > - defined as part of the protocol (or as a separate RFC) when its > - definition is complete. > + named in the following sections. > > 8.2. LDAP Attributes > > @@ -1057,24 +1055,24 @@ Internet-Draft NSDB Protocol for Feder > > It MAY also be useful, for purposes of debugging or annotation, to > permit a fedfsUuid to include members of a more general class of > + strings. > > > > -Ellard, et al. Expires February 6, 2009 > [Page 19] > - > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > > +Ellard, et al. Expires March 23, 2009 > [Page 19] > + > > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > - strings. > > - A fedfsUuid is a single-valued attribute. > + A fedfsUuid is a single-valued LDAP attribute. > > 8.2.2. fedfsNetAddr > > - An fedfsNetAddr is the locative name of a TCP/IP-based network > - service. It MUST be able to express network locations as > IPv4, IPv6, > - and DNS FQDN notations. It may include a port specifier, > or the port > - may be implicit in context. > + A fedfsNetAddr is the locative name of a network service. > It MUST be > + able to express network locations as IPv4, IPv6, and DNS FQDN > + notations. It may include a port specifier, or the port may be > + implicit in context. > > There MAY be a special syntax at some point for specifying a SVR > record (for a DNS FQDN). > @@ -1111,45 +1109,56 @@ Internet-Draft NSDB Protocol for Feder > > This attribute is single-valued. > > +8.2.7. fslUuid > > + Each FSL must have a UUID associated with it, which > serves as part of > + its DN. > > > > - > -Ellard, et al. Expires February 6, 2009 > [Page 20] > +Ellard, et al. Expires March 23, 2009 > [Page 20] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > -8.2.7. annotation > + The fslUuid attribute is a subclass of fedfsUuid. > > - An annotation of an NSDB object. > + This attribute is single-valued. > > - This attribute is multi-valued; an object type that permits > - annotations may have any number of annotations per instance. > +8.2.8. type > > - This attribute is a placeholder; it has not been > well-defined at the > - date of this draft. > + The type of an FSL. > > -8.2.8. descr > + This attribute is used to specify the distribute file > system protocol > + that can be used to access an FSL. The following values > are defined > + for this field: > > - A descriptive attribute containing information about an > NSDB object. > + nfsv4 : the FSL is accessible via the NFSv4 protocol. > > - This attribute is single-valued. > + Values for other protocols may be defined at a later time. > > - This attribute is a placeholder; it has not been > well-defined at the > - date of this draft. > + This attribute is single-valued. > > -8.2.9. fslUuid > +8.2.9. currency > > - Each FSL must have a UUID associated with it, which > serves as part of > - its DN. > + The currency of an FSL. > > - The fslUuid attribute is a subclass of fedfsUuid. > + This attribute is used to populate the NFSv4.1 fs_locations_info's > + currency field. > > This attribute is single-valued. > > -8.2.10. junctionKey > +8.2.10. annotation > + > + An annotation of an NSDB object. > + > + This attribute is multi-valued; an object type that permits > + annotations may have any number of annotations per instance. > + > + This attribute is a placeholder; it has not been > well-defined at the > + date of this draft. > + > +8.2.11. junctionKey > > Each junction has a unique junctionKey that is used to > distinguish it > from other junctions that may refer to the same child > fileset and/or > @@ -1159,25 +1168,24 @@ Internet-Draft NSDB Protocol for Feder > > This attribute is single-valued. > > -8.2.11. childFsnUuid > > - The fsnUuid of the target of a junction. > > - The childFsnUuid attribute is a subclass of fsnUuid. > - > - This attribute is single-valued. > > > +Ellard, et al. Expires March 23, 2009 > [Page 21] > + > > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > +8.2.12. childFsnUuid > > + The fsnUuid of the target of a junction. > > -Ellard, et al. Expires February 6, 2009 > [Page 21] > - > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > + The childFsnUuid attribute is a subclass of fsnUuid. > > + This attribute is single-valued. > > -8.2.12. childNsdbName > +8.2.13. childNsdbName > > The nsdbName of the target of a junction. > > @@ -1191,10 +1199,7 @@ Internet-Draft NSDB Protocol for Feder > > An FsnObject represents an FSN. > > - The required attributes of an FsnObject are an fsnUuid > and nsdbName. > - > - An FsnObject MAY also have descr and annotation attributes, but > - neither is required. > + The required attributes of an FsnObject are an nsdbName > and fsnUuid. > > The DN of an FSN is assumed to take the following form: > "fsnUuid=FSNUUID,dc=fed-fs,dc=com", where fsnUuid is the > UUID of the > @@ -1207,11 +1212,10 @@ Internet-Draft NSDB Protocol for Feder > > An FslObject represents an FSL. > > - The required attributes of an FslObject are an fsnUuid, nsdbName, > - fslHost, fslPath, and fslUuid. > + The required attributes of an FslObject are an nsdbName, fsnUuid, > + fslHost, fslPath, and fslUuid, type, currency, and annotations. > > - An FslObject MAY also have descr and annotation attributes, but > - neither is required. > + An FslObject's currency and annotations attributes MAY be null. > > The DN of an FSL is required to take the following form: > "fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com". > @@ -1221,18 +1225,18 @@ Internet-Draft NSDB Protocol for Feder > filter for "objectType = fslObject". (If you want to be doubly > careful, you can also filter by the nsdbName.) > > -8.3.3. JunctionObject > - > - An JunctionObject captures the relationship between a > fileset and its > - children (if any). The children FSNs are FSNs that appear in > > > > -Ellard, et al. Expires February 6, 2009 > [Page 22] > +Ellard, et al. Expires March 23, 2009 > [Page 22] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > + > > +8.3.3. JunctionObject > > + An JunctionObject captures the relationship between a > fileset and its > + children (if any). The children FSNs are FSNs that appear in > junctions in the fileset named by the fsnUuid and > nsdbName attributes > of the parent FSN. > > @@ -1280,13 +1284,9 @@ Internet-Draft NSDB Protocol for Feder > > > > - > - > - > - > -Ellard, et al. Expires February 6, 2009 > [Page 23] > +Ellard, et al. Expires March 23, 2009 > [Page 23] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > 9. NSDB Protocol Operations > @@ -1314,7 +1314,7 @@ Internet-Draft NSDB Protocol for Feder > unnecessary to describe the LDAP operations in detail, because the > operations are ordinary LDAP operations to query and > update records. > However, we do not require that an NSDB location > implement a complete > - NSDB service, and therefore we define in these sections > the minimum > + LDAP service, and therefore we define in these sections > the minimum > level of LDAP functionality required to implement an NSDB > location. > > The NSDB sub-protocols are defined in the next two sub-sections. > @@ -1322,7 +1322,7 @@ Internet-Draft NSDB Protocol for Feder > The third sub-protocol defines the queries or other > requests that are > sent to a fileset server in order to get information from it or to > modify the state of the fileset server in a manner related to the > - federation protocols. The primary purpose of this for an > + federation protocols. The primary purpose of this > protocol is for > + an > administrator to create or delete a junction or fileset > or discover > related information about a particular fileset server. > > @@ -1340,9 +1340,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 24] > +Ellard, et al. Expires March 23, 2009 > [Page 24] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > We require that each NSDB location be able to act as an > LDAP server > @@ -1369,9 +1369,9 @@ Internet-Draft NSDB Protocol for Feder > with an fsnUuid of FSNUUID and an NsdbName of NSDB. > > The NSDB location that receives the request SHOULD check that the > - NSDB matches its own value and return an ERR_WRONGNSDB > error if does > - not. This is to ensure that an FSN is always created by the NSDB > - location encoded within the FSN as its owner. > + NSDB matches its own value and return an ERR_WRONGNSDB error if it > + does not. This is to ensure that an FSN is always created by the > + NSDB location encoded within the FSN as its owner. > > The NSDB location that receives the request SHOULD check > all of the > attributes for validity and consistency, but this is not generally > @@ -1396,9 +1396,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 25] > +Ellard, et al. Expires March 23, 2009 > [Page 25] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > dn: fsnUuid=FSNUUID,dc=fed-fs,dc=com > @@ -1409,11 +1409,10 @@ Internet-Draft NSDB Protocol for Feder > > 9.1.2. Deleting an FSN > > - Deletes the Fileset with the given FSN. This assumes that all the > - FSLs related to that FSN have already been deleted. If > FSL records > - for this FSN still exist in the database of the NSDB that receives > - this request, then this function MUST return with an ERR_NOTEMPTY > - error. > + Deletes the given fileset name. This assumes that all the FSLs > + related to that FSN have already been deleted. If FSL records for > + this FSN still exist in the database of the NSDB that > receives this > + request, then this function MUST return with an > ERR_NOTEMPTY error. > > Note that the FSN delete function only removes the > fileset from the > namespace (by removing the records for that FSN from the NSDB > @@ -1427,9 +1426,9 @@ Internet-Draft NSDB Protocol for Feder > > 9.1.2.1. LDAP Request > > - The admin then sends an LDAP DELETE request to the NSDB server to > - remove the FsnObject from the NSDB server. An example > LDIF for the > - delete request is shown below. > + The admin sends an LDAP DELETE request to the NSDB server > to remove > + the FsnObject from the NSDB server. An example LDIF for > the delete > + request is shown below. > > dn: fsnUuid=FSNUUID,dc=fed-fs,dc=com > changeType: delete > @@ -1449,15 +1448,15 @@ Internet-Draft NSDB Protocol for Feder > The parent/child relation is used to indicate how the > filesets in the > federation are related. The names "parent" and "child" > should not be > taken literally. A fileset can have no parent (if it is a root > + fileset). A fileset may also have any number of parents. In > + theory, > > > > -Ellard, et al. Expires February 6, 2009 > [Page 26] > +Ellard, et al. Expires March 23, 2009 > [Page 26] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > - fileset). A fileset may also have any number of parents. > In theory, > the parent of a fileset may also be its child, although > in practice > this is deprecated. > > @@ -1501,24 +1500,19 @@ Internet-Draft NSDB Protocol for Feder > dn: key=KEY,fsnUuid=FSNUUID,dc=fed-fs,dc=com > changeType: delete > > +9.1.5. Create an FSL > > + Creates a new Fileset location at the given location > denoted by HOST > + and PATH for the given FSN. Normally an FSL is identified by the > + HOST:PATH pair. A UUID is an optional way to identify an > FSL if it > > > > - > - > - > -Ellard, et al. Expires February 6, 2009 > [Page 27] > +Ellard, et al. Expires March 23, 2009 > [Page 27] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > -9.1.5. Create an FSL > - > - Creates a new Fileset location at the given location > denoted by HOST > - and PATH for the given FSN. An fsl_uuid may be provided as an > - optional UUID for the FSL. Normally an FSL is identified by the > - HOST:PATH pair. A UUID is an optional way to identify an > FSL if it > is recovered to a different HOST:PATH after a > backup/restore. If the > FSL belongs to an FSN that has another FSN mounted under it then > there would be a related junction_create operation. > @@ -1540,8 +1534,9 @@ Internet-Draft NSDB Protocol for Feder > fslUuid: UUID > fslHost: HOST > fslPath: PATH > - type: nfs4 > - version: VERSION > + type: file access protocol type (e.g. nfs4) > + currency: CURRENCY > + annotation: ANNOTATION > > 9.1.6. Delete an FSL > > @@ -1557,18 +1552,6 @@ Internet-Draft NSDB Protocol for Feder > dn: fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com > changeType: delete > > - > - > - > - > - > - > - > -Ellard, et al. Expires February 6, 2009 > [Page 28] > - > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > - > - > 9.1.7. Update an FSL > > Update the attributes of a given FSL. This command results in a > @@ -1578,22 +1561,21 @@ Internet-Draft NSDB Protocol for Feder > > PARAGRAPH DESCRIBING ERRORS > > -9.1.7.1. LDAP Request > > - dn: fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com > - changeType: modify > - replace: ATTRIBUTE-TYPE > > -9.1.8. Examining an FSL > > - Find all attributes of a given FSL from the FSLObject > stored at the > - NSDB location. > +Ellard, et al. Expires March 23, 2009 > [Page 28] > + > > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > - ERRORS: ERR_OK ERR_NOTFOUND ERR_INVALID ERR_PERM > > - WHERE IS THE LDAP FOR THIS? -DJE > +9.1.7.1. LDAP Request > > -9.1.9. Finding the children FSNs of a fileset > + dn: fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com > + changeType: modify > + replace: ATTRIBUTE-TYPE > + > +9.1.8. Finding the children FSNs of a fileset > > The NSDB also tracks information about which filesets are > "children" > of others. A fileset X is a child of fileset Y if there is a > @@ -1616,15 +1598,6 @@ Internet-Draft NSDB Protocol for Feder > of the implementation (but it may also eliminate some very useful > functionality). > > - > - > - > - > -Ellard, et al. Expires February 6, 2009 > [Page 29] > - > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > - > - > LDAP Request > Search base: fsnUuid=FSNUUID, dc=fed-fs, dc=com > Search scope: onelevel > @@ -1643,6 +1616,15 @@ Internet-Draft NSDB Protocol for Feder > > ERRORS: ERR_OK ERR_NOTFOUND ERR_INVALID ERR_PERM > > + > + > + > + > +Ellard, et al. Expires March 23, 2009 > [Page 29] > + > > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > + > + > LDAP Request > Search base: fsnUuid=FSNUUID, dc=fed-fs, dc=com > Search scope: onelevel > @@ -1676,14 +1658,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 30] > - > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > > > -10. Security Considerations > > - To be added. > > > > @@ -1699,6 +1676,25 @@ Internet-Draft NSDB Protocol for Feder > > > > +Ellard, et al. Expires March 23, 2009 > [Page 30] > + > > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > + > + > +10. Security Considerations > + > + Both LDAP and NFSv4 provide security mechanisms. When used in > + conjunction with the federated file system protocols described in > + this document, the use of these mechanisms is RECOMMENDED. > + Specifically, the use of RPCSEC_GSS [RFC2203] [RFC2743] is > + RECOMMENDED on all connections between a client and > filerserver. For > + all LDAP connections established by the federated file system > + protocols, TLS [RFC4346] [RFC4513] is RECOMMENDED. > + > + > + > + > + > > > > @@ -1732,9 +1728,13 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 31] > + > + > + > + > +Ellard, et al. Expires March 23, 2009 > [Page 31] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > 11. IANA Requirements > @@ -1788,9 +1788,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 32] > +Ellard, et al. Expires March 23, 2009 > [Page 32] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > 12. Conclusions > @@ -1844,9 +1844,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 33] > +Ellard, et al. Expires March 23, 2009 > [Page 33] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > 13. Glossary > @@ -1900,9 +1900,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 34] > +Ellard, et al. Expires March 23, 2009 > [Page 34] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > FSN (Fileset name): A platform-independent and globally > unique name > @@ -1956,9 +1956,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 35] > +Ellard, et al. Expires March 23, 2009 > [Page 35] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > The namespace provided by a server collection could be > part of the > @@ -2012,9 +2012,9 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 36] > +Ellard, et al. Expires March 23, 2009 > [Page 36] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > 14. Normative References > @@ -2068,21 +2068,21 @@ Internet-Draft NSDB Protocol for Feder > > > > -Ellard, et al. Expires February 6, 2009 > [Page 37] > +Ellard, et al. Expires March 23, 2009 > [Page 37] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > Authors' Addresses > > Daniel Ellard > - NetApp, Inc. > - 1601 Trapelo Rd, Suite 16 > - Waltham, MA 02451 > + BBN Technologies > + 10 Moulton Street > + Cambridge, MA 02138 > US > > - Phone: +1 781-768-5421 > - Email: ellard at netapp.com > + Phone: +1 617-873-8000 > + Email: ellard at google.com > > > Craig Everhart > @@ -2095,6 +2095,16 @@ Authors' Addresses > Email: everhart at netapp.com > > > + James Lentini > + NetApp, Inc. > + 1601 Trapelo Rd, Suite 16 > + Waltham, MA 02451 > + US > + > + Phone: +1 781-768-5359 > + Email: jlentini at netapp.com > + > + > Renu Tewari > IBM Almaden > 650 Harry Rd > @@ -2104,6 +2114,21 @@ Authors' Addresses > Email: tewarir at us.ibm.com > > > + > + > + > + > + > + > + > + > + > + > +Ellard, et al. Expires March 23, 2009 > [Page 38] > + > > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > + > + > Manoj Naik > IBM Almaden > 650 Harry Rd > @@ -2124,9 +2149,40 @@ Authors' Addresses > > > > -Ellard, et al. Expires February 6, 2009 > [Page 38] > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > +Ellard, et al. Expires March 23, 2009 > [Page 39] > > > -Internet-Draft NSDB Protocol for Federated Filesystems > August 2008 > +Internet-Draft NSDB Protocol for Federated Filesystems > September 2008 > > > Full Copyright Statement > @@ -2180,5 +2236,5 @@ Acknowledgment > > > > -Ellard, et al. Expires February 6, 2009 > [Page 39] > +Ellard, et al. Expires March 23, 2009 > [Page 40] > > > -------------- next part -------------- > An embedded and charset-unspecified text was scrubbed... > Name: draft-tewari-nfsv4-federated-fs-protocol.txt > Url: > https://lists.sdsc.edu/pipermail/federated-fs/attachments/2008 > 0919/6f2c709f/draft-tewari-nfsv4-federated-fs-protocol.txt > From jlentini at netapp.com Tue Sep 23 15:21:55 2008 From: jlentini at netapp.com (James Lentini) Date: Tue, 23 Sep 2008 18:21:55 -0400 (EDT) Subject: [Federated-fs] updated NSDB draft In-Reply-To: References: Message-ID: On Fri, 19 Sep 2008, Everhart, Craig wrote: > Three comments are included. I hope I'm interpreting the "diff" > correctly. > > -Internet-Draft NSDB Protocol for Federated Filesystems > > August 2008 > > - > > - > > - status: fls_status as defined by the NFSv4.1 status attribute > > - > > - info: as defined in NFSv4.1 fs_locations_info attribute > > + fs_locations_server's fls_currency field. A currency > > value of 0 > > + represents the latest version. Currency values are > > less than or > > + equal to zero > > Did we lose some text above here? > > > + > > + Annotations: a list of name/value pairs that can be > > interpreted by a > > + fileserver and used to generate a referral. The > > semantics of the > > + name/value pair is not defined by this protocol and is > > intended to > > + be used by higher-level protocols. This field MAY be used to > > + store the NFSv4.1 fl_locations_server's fls_info values > > Ditto with lost text? I am proposing to make the FSL description consistent with the LDAP definition of an FSL in section 8 and the LDIF for creating an FSL in section 9. To do that, I've removed the attrs field that is described here to contain an XDR object. This attrs field was not included in either the descriptions in section 8 or 9. The old text was: old text ----------------------- Each FSL consists of: host_fqdn: the name of the host fileserver storing the physical data pathname: the exported pathname at that host fileserver attrs: additional attributes for this FSL, as described in the FSL_ATTR structure struct FSL_ATTR { protocol_t type; int32_t currency; annotation_t annotations<>; fs_status_t status; opaque_t info<>; } The attributes associated with each FSL are: type: the protocol(s) supported by the fileserver hosting this FSL currency: the time lag of this FSL represented as the number of time units it lags the latest version as defined by the NFSv4.1 fs_locations_info attribute. A currency value of 0 represents the latest version. Currency values are less than or equal to zero annotations: a list of name/value pairs that can be interpreted by an individual NSDB. The semantics of the name/value pair is not defined by this protocol and is intended to be used by higher- level administration protocols status: fls_status as defined by the NFSv4.1 status attribute info: as defined in NFSv4.1 fs_locations_info attribute ---- On problem with the contents of the attrs field described above is that the NFSv4.1 spec (as of rev 26) does not define an fls_status. The new text I'm proposing is: --- Each FSL consists of: FslHost: the fully qualified domain name of the host fileserver storing the physical data FslPathname: the exported pathname at that host fileserver FslUuid: the 128-bit UUID of the FSL Type: the protocol that should be used to access this FSL (e.g. NFSv4) Currency: the time lag of this FSL represented as the number of time units it lags the latest version as defined by the NFSv4.1 fs_locations_server's fls_currency field. A currency value of 0 represents the latest version. Currency values are less than or equal to zero Annotations: a list of name/value pairs that can be interpreted by a fileserver and used to generate a referral. The semantics of the name/value pair is not defined by this protocol and is intended to be used by higher-level protocols. This field MAY be used to store the NFSv4.1 fl_locations_server's fls_info values --- The alternative would be to change the LDAP/LDIF to include the fls_info field. > > > > 3.3.1. Mutual Consistency across Fileset Locations > > > > @@ -467,6 +441,14 @@ Internet-Draft NSDB Protocol for Feder > > write location. The federation protocols, however, cannot prevent > > subsequent changes to a read-only location nor guarantee point-in- > > time consistency of a read-only location if the > > read-write location > > + > > + > > + > > +Ellard, et al. Expires March 23, 2009 > > [Page 8] > > + > > > +Internet-Draft NSDB Protocol for Federated Filesystems > > September 2008 > > + > > + > > is changing. > > > > Regardless of the type, all locations exist at the same > > mount point > > @@ -485,7 +467,7 @@ Internet-Draft NSDB Protocol for Feder > > raises a concern for NFSv3 fileservers, which the > > federation protocol > > may support, that may lack such control. > > > > -3.4. Namespace Repository (NSDB) > > +3.4. Namespace Database (NSDB) > > > > The NSDB service is a federation-wide service that provides > > interfaces to define, update, and query FSN information and FSN to > > @@ -498,13 +480,6 @@ Internet-Draft NSDB Protocol for Feder > > analogous to that between the DNS service and a particular DNS > > server. > > > > - > > - > > -Ellard, et al. Expires February 6, 2009 > > [Page 9] > > - > > > -Internet-Draft NSDB Protocol for Federated Filesystems > > August 2008 > > - > > - > > The term local NSDB is shorthand for an NSDB location > > that is known a > > priori to a server. It is typically located within the same > > federation member as the server, but this is not > > required. A local > > @@ -519,13 +494,26 @@ Internet-Draft NSDB Protocol for Feder > > location to resolve a junction. Each NSDB location > > supports an LDAP > > interface and can be accessed by an LDAP client. > > > > + An NSDB may be replicated throught the federation. The > > mechanism by > > + which this is acheived is outside the scope of this > > document. Many > > + LDAP implementations support replication. These features MAY be > > + used > > + > > + > > + > > +Ellard, et al. Expires March 23, 2009 > > [Page 9] > > + > > > +Internet-Draft NSDB Protocol for Federated Filesystems > > September 2008 > > + > > + > > + to replicate the NSDB. > > + > > 3.5. Mount Points, Junctions and Referrals > > > > A mount point is a directory in a parent fileset where a target > > fileset may be attached. If a client traverses the path > > leading from > > - the root of the namespace to the mount point of a fileset > > it should > > - be able to access the data in that fileset (assuming appropriate > > - permissions). > > + the root of the namespace to the mount point of a target > > fileset it > > + should be able to access the data in that target fileset (assuming > > + appropriate permissions). > > > > The directory where a fileset is mounted is represented > > by a junction > > in the underlying filesystem. In other words, a junction can be > > @@ -538,9 +526,10 @@ Internet-Draft NSDB Protocol for Feder > > What data is used by the underlying file system to represent the > > junction is not defined by this protocol. The essential > > property is > > that the server must be able to find, given the junction, > > the FSN for > > - the target fileset. The FSN (as described earlier) > > contains both the > > - NSDB location of the authoritative NSDB location and the > > FsnUuid (a > > - UUID for the fileset). > > + the target fileset. The mechanism by which the server maps a > > + junction to an FSN is outside the scope of this document. The FSN > > + (as described earlier) contains both the NSDB location of the > > + authoritative NSDB location and the FsnUuid (a UUID for > > the fileset). > > > > When a client traversal reaches a junction, the client is > > referred to > > a list of FSLs associated with the FSN that was the target of the > > @@ -553,14 +542,6 @@ Internet-Draft NSDB Protocol for Feder > > fileset is mounted in the namespace. Filesets can be nested -- a > > fileset can be mounted under another fileset. > > > > - > > - > > - > > -Ellard, et al. Expires February 6, 2009 > > [Page 10] > > - > > > -Internet-Draft NSDB Protocol for Federated Filesystems > > August 2008 > > - > > - > > 3.6. Federation Root FileServers > > > > A set of designated fileservers that render the common federation- > > @@ -572,6 +553,14 @@ Internet-Draft NSDB Protocol for Feder > > fileservers. If a client mounts from a non-root > > fileserver then it > > can traverse the part of the namespace that is visible > > starting from > > that fileserver. A client can mount multiple individual filesets > > + > > + > > + > > +Ellard, et al. Expires March 23, 2009 > > [Page 10] > > + > > > +Internet-Draft NSDB Protocol for Federated Filesystems > > September 2008 > > + > > + > > from multiple non-root fileservers and chose to navigate the > > namespace in any manner. How the client discovers the root > > fileserver(s), if one is defined, is not in the scope of the > > Hm--I don't recall the text here, but it may want to point to the DNS > SRV draft. This is a false positive. I'm not proposing any changes to this text. It is showing up in the diff because my earlier changes moved the root fileset text so that it spans a page. Hence diff thinks I am adding the header and footer into this paragraph. The text mentions the DNS SRV mechanism. Please let me know if you have suggestions on how to improve it. Here is the text as it is in the currently published draft: --- 3.6. Federation Root FileServers A set of designated fileservers that render the common federation- wide namespace are called the federation root fileservers. The federation protocol does not mandate that federation root fileservers be defined. When a client mounts the root of the namespace from a root fileserver it can traverse the entire federation-wide namespace. It is not required for a client to mount from one of the root fileservers. If a client mounts from a non-root fileserver then it can traverse the part of the namespace that is visible starting from that fileserver. A client can mount multiple individual filesets from multiple non-root fileservers and chose to navigate the namespace in any manner. How the client discovers the root fileserver(s), if one is defined, is not in the scope of the federation protocol. Numerous external techniques such as DNS SRV records can be used for this. --- From Craig.Everhart at netapp.com Wed Sep 24 06:47:38 2008 From: Craig.Everhart at netapp.com (Everhart, Craig) Date: Wed, 24 Sep 2008 09:47:38 -0400 Subject: [Federated-fs] updated NSDB draft In-Reply-To: References: Message-ID: OK, thanks. For the FSL contents, the lack of punctuation at the end of what's clearly a sequence of sentences just made me think that the text ended unnaturally there, e.g., by being cut off. > The new text I'm proposing is: > > --- > > Each FSL consists of: > > FslHost: the fully qualified domain name of the host fileserver > storing the physical data > > FslPathname: the exported pathname at that host fileserver > > FslUuid: the 128-bit UUID of the FSL > > Type: the protocol that should be used to access this FSL (e.g. > NFSv4) > > Currency: the time lag of this FSL represented as the > number of time > units it lags the latest version as defined by the NFSv4.1 > fs_locations_server's fls_currency field. A currency value of 0 > represents the latest version. Currency values are less than or > equal to zero > > Annotations: a list of name/value pairs that can be > interpreted by a > fileserver and used to generate a referral. The > semantics of the > name/value pair is not defined by this protocol and is > intended to > be used by higher-level protocols. This field MAY be used to > store the NFSv4.1 fl_locations_server's fls_info values > > --- > > The alternative would be to change the LDAP/LDIF to include > the fls_info field. > > > > > > +Internet-Draft NSDB Protocol for Federated Filesystems > > > September 2008 > > > + > > > + > > > from multiple non-root fileservers and chose to navigate the > > > namespace in any manner. How the client discovers the root > > > fileserver(s), if one is defined, is not in the scope of the > > > > Hm--I don't recall the text here, but it may want to point > to the DNS > > SRV draft. > > This is a false positive. I'm not proposing any changes to this text. > It is showing up in the diff because my earlier changes moved > the root fileset text so that it spans a page. Hence diff > thinks I am adding the header and footer into this paragraph. > The text mentions the DNS SRV mechanism. Please let me know > if you have suggestions on how to improve it. Here is the > text as it is in the currently published > draft: > > --- > > 3.6. Federation Root FileServers > > A set of designated fileservers that render the common federation- > wide namespace are called the federation root fileservers. The > federation protocol does not mandate that federation root > fileservers > be defined. When a client mounts the root of the namespace from a > root fileserver it can traverse the entire federation-wide > namespace. > It is not required for a client to mount from one of the root > fileservers. If a client mounts from a non-root fileserver then it > can traverse the part of the namespace that is visible > starting from > that fileserver. A client can mount multiple individual filesets > from multiple non-root fileservers and chose to navigate the > namespace in any manner. How the client discovers the root > fileserver(s), if one is defined, is not in the scope of the > federation protocol. Numerous external techniques such as DNS SRV > records can be used for this. Well, it's a false positive in the diff sense. I was thinking that we perhaps needed to make an actual change to refer to the DNS SRV work to tie it into a package, but the existing text is OK for that until we get a better sense from the WG. Thanks. Craig From jlentini at netapp.com Thu Sep 25 08:00:55 2008 From: jlentini at netapp.com (James Lentini) Date: Thu, 25 Sep 2008 11:00:55 -0400 (EDT) Subject: [Federated-fs] Proposed FedFS Meeting Agenda, 9/25/2008 Message-ID: Please let me know if you would like to add items to today's agenda. Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST Dial-in: 1-888-765-3653 # 2354843 Proposed Agenda --------------- + root fileset + IETF publication plan From jlentini at netapp.com Fri Sep 26 11:48:31 2008 From: jlentini at netapp.com (James Lentini) Date: Fri, 26 Sep 2008 14:48:31 -0400 (EDT) Subject: [Federated-fs] FedFs documents re-published in NFSv4 working group Message-ID: The FedFs documents have been re-published in the NFSv4 working group. ---------- Forwarded message ---------- Date: Fri, 26 Sep 2008 11:30:01 -0700 (PDT) From: Internet-Drafts at ietf.org To: i-d-announce at ietf.org Cc: nfsv4 at ietf.org Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-federated-fs-reqts-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of$ Title : Requirements for Federated File Systems Author(s) : D. Ellard, et al. Filename : draft-ietf-nfsv4-federated-fs-reqts-00.txt Pages : 30 Date : 2008-09-26 This draft describes and lists the functional requirements of a federated file system and defines related terms. Our intent is to use this draft as a starting point and refine it, with input and feedback from the file system community and other interested parties, until we reach general agreement. We will then begin, again with the help of any interested parties, to define standard, open federated file system protocols that satisfy these requirements and are suitable for implementation and deployment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-federated-fs-reqts-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---------- Forwarded message ---------- Date: Fri, 26 Sep 2008 11:30:01 -0700 (PDT) From: Internet-Drafts at ietf.org To: i-d-announce at ietf.org Cc: nfsv4 at ietf.org Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-federated-fs-protocol-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of$ Title : NSDB Protocol for Federated Filesystems Author(s) : D. Ellard, et al. Filename : draft-ietf-nfsv4-federated-fs-protocol-00.txt Pages : 40 Date : 2008-09-26 This document describes a file system federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers and collections of fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-federated-fs-protocol-00.t$ Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---------- Forwarded message ---------- Date: Fri, 26 Sep 2008 11:30:01 -0700 (PDT) From: Internet-Drafts at ietf.org To: i-d-announce at ietf.org Cc: nfsv4 at ietf.org Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-federated-fs-admin-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of$ Title : Administration Protocol for Federated Filesystems Author(s) : D. Ellard, et al. Filename : draft-ietf-nfsv4-federated-fs-admin-00.txt Pages : 22 Date : 2008-09-26 This document describes the administration protocol for a federated file system that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers and collections of fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-federated-fs-admin-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---------- Forwarded message ---------- Date: Fri, 26 Sep 2008 11:30:01 -0700 (PDT) From: Internet-Drafts at ietf.org To: i-d-announce at ietf.org Cc: nfsv4 at ietf.org Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-federated-fs-dns-srv-namespace-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF. Title : Using DNS SRV to Specify a Global File Name Space with NFS version 4 Author(s) : C. Everhart, et al. Filename : draft-ietf-nfsv4-federated-fs-dns-srv-namespace-00.txt Pages : 11 Date : 2008-09-26 The NFS version 4 protocol provides a natural way for a collection of NFS file servers to collaborate in providing an organization-wide file name space. The DNS SRV RR allows a simple and appropriate way for an organization to publish the root of its name space, even to clients that might not be intimately associated with such an organization. DNS SRV can be used to join these organization-wide file name spaces together to allow construction of a global, uniform NFS version 4 file name space. This document refreshes the draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From jlentini at netapp.com Fri Sep 26 12:03:37 2008 From: jlentini at netapp.com (James Lentini) Date: Fri, 26 Sep 2008 15:03:37 -0400 (EDT) Subject: [Federated-fs] fedfs documents published Message-ID: Greetings, As you may have noticed, four "fedfs" drafts have been published as NFSv4 working group documents today. These drafts collectively describe a set of protocols that operate in conjunction with standard NFSv4 features to create a namespace across NFS servers. These documents are works in progress. We look forward to receiving additional comments on them. There is a group of 8 or so individuals from several different organizations that discuss these protocols on a weekly phone conference. Anyone interested in participating in these meetings is welcome to join us. Here is the call info: Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST Dial-in: 1-888-765-3653 # 2354843 Again, we look forward to your comments and discussing these issues within the working group. -james -- James Lentini | NetApp | 781-768-5359 | jlentini at netapp.com From shahid.shaikh at in.ibm.com Fri Sep 26 15:32:16 2008 From: shahid.shaikh at in.ibm.com (Shahid M Shaikh) Date: Sat, 27 Sep 2008 04:02:16 +0530 Subject: [Federated-fs] Shahid M Shaikh is out of the office. Message-ID: I will be out of the office starting 27-09-2008 and will not return until 06-10-2008. I will respond to your message when I return. If its necessary, please contact my manager. From jlentini at netapp.com Mon Sep 29 07:22:36 2008 From: jlentini at netapp.com (James Lentini) Date: Mon, 29 Sep 2008 10:22:36 -0400 (EDT) Subject: [Federated-fs] FedFS Meeting Minutes, 9/25/2008 Message-ID: FedFS Meeting Minutes, 9/25/2008 -------------------------------- Attendees --------- Craig Everhart (NetApp) Paul Lemahieu (EMC) James Lentini (NetApp) Manoj Naik (IBM/ARC) Renu Tewari (IBM/ARC) Robert Thurlow (Sun) Minutes ------- + IETF publication plan The draft documents will be re-published tomorrow (9/26) as NFSv4 wg drafts. [Editors note: they were republished] The NFSv4 wg charter needs to be updated to include federated namespaces. James Lentini sent out a draft of the additional text for the charter. Please reply with comments. Two design principals that we want to retain when moving to the NFSv4 wg: - ability to support other (non-NFS) protocols - no client-server protocol changes + root fileset This discussion was fairly free flowing. We discussed a number of issues: There had been some questions on the Push versus Pull model. Craig got answers on these from Ellard that resolved his questions. What does the root fileset contain? The first level could be arbitrarily large. There would be top level directories for each member of the federation. What is the problem the root fileset addresses? We have multiple NSDBs and we want them to have a single root fileset. We don't want the root to be controlled by one NSDB since this is a federation. If there is only one master nsdb, then we know how to implement this. Given there is not one master, then we need to have a replication. Suppose two companies merge and they have two namespaces that need to be merged. How can the root fileset address this issue? Does one NSDB root imply that the root NSDB must be replicated using a single LDAP implementation? In other words, if there were only one root NSDB then the particular LDAP implementation (e.g. OpenLDAP version X.Y) used for that NSDB would need to be used throughout the federation since LDAP replication is implementation specific. Does a single root NSDB mean that there is an admin with more privileges than other admins? The root admin has control of their area and other admins have control over their areas. How is the root fileset implemented? Does the fileserver export a pseudo filesystem or an on disk structure? The server needs to present the root fileset, but how this is implemented does not need to be defined. Need to resolve schema of root file set and resolve single NSDB versus replicated NSDB issue. Next week: - security considerations and requirements - root fileset, particularly the issue of one root NSDB versus multiple root NSDBs