Network Working Group                                          D. Ellard
Internet-Draft                                          BBN Technologies
Intended status: Standards Track                             C. Everhart
Expires: March 30, 2009                                       J. Lentini
                                                                  NetApp
                                                               R. Tewari
                                                                 M. Naik
                                                             IBM Almaden
                                                      September 26, 2008


           Administration Protocol for Federated Filesystems
               draft-ietf-nfsv4-federated-fs-admin-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 30, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).









Ellard, et al.           Expires March 30, 2009                 [Page 1]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


Abstract

   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.


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Error Definitions  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Administrator-Initiated Operations . . . . . . . . . . . . . .  7
     4.1.  Basic Definition . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Required Operations  . . . . . . . . . . . . . . . . . . .  8
       4.2.1.  CREATE_JUNCTION  . . . . . . . . . . . . . . . . . . .  9
       4.2.2.  DELETE_JUNCTION  . . . . . . . . . . . . . . . . . . . 10
       4.2.3.  LOOKUP_FSN . . . . . . . . . . . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Requirements  . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22






















Ellard, et al.           Expires March 30, 2009                 [Page 2]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Ellard, et al.           Expires March 30, 2009                 [Page 3]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


2.  Introduction

   A federated filesystem enables file access and namespace traversal in
   a uniform, secure and consistent manner across multiple independent
   fileservers within an enterprise (and possibly across multiple
   enterprises) with reasonably good performance.

   The first requirement of a federated filesystem is the ability to
   traverse the data exported by different fileservers without requiring
   a static client configuration.  The second requirement is that the
   location of the data should be dynamically discovered and the
   discovery process should be transparent to the clients.  The third
   requirement is that it should be possible for all clients, with
   sufficient privilege, to view the same namespace regardless of the
   fileserver they connect to.

   Traditionally, fileserver collections are administered by a single
   entity.  Fileservers may provide proprietary management tools and in
   some cases an administrator may be able to use the proprietary tools
   to build a shared namespace out of the exported filesystems.  Relying
   on vendor-proprietary tools does not work in larger enterprises or
   when collaborating across enterprises because it is likely that the
   system will contain fileservers running different software, each with
   their own interfaces, with no common protocol to manage the namespace
   or exchange namespace information.  There may also be independently-
   administered singleton servers that export some or all of their
   filesystem resources.  A filesystem federation protocol enables the
   interoperation across multi-vendor fileservers managed by the same
   administrative entity, across singleton independent fileservers, and
   across independent administrative entities that may manage a
   collection of fileservers.  The scope of the filesystem federation
   protocol is limited to NFSv4 capable fileservers.  The support for
   NFSv3 fileservers is optional.

   The basic requirements for a federated file system protocol are
   described in IETF draft draft-ellard-nfsv4-federated-fs-reqts, and
   the current proposed protocol is described in
   draft-tewari-nfsv4-federated-fs-protocol.  Those drafts are
   companions (and essential background material) to this document.
   Please refer to those documents for the definitions of basic terms
   and concepts used in this document.










Ellard, et al.           Expires March 30, 2009                 [Page 4]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


3.  Error Definitions

   The results of successful operations will consist of a status of
   FEDFS_OK.  The results of unsuccessful operations will begin with a
   status, other than FEDFS_OK, that indicates the reason why the
   operation failed.

   Many of the error status names and meanings (and the prose for their
   descriptions) are taken from the specification for NFSv4 [RFC3530].
   Note, however, that the literal values for the status codes are
   different.

   Note that the status of an unsuccessful operation will generally only
   indicate the first error encountered during the attempt to execute
   the operation.

   FEDFS_OK  No errors were encountered.  The operation was a success.

   FEDFS_ERR_ACCESS  Permission denied.  The caller does not have the
      correct permission to perform the requested operation.

   FEDFS_ERR_BADCHAR  A UTF-8 string contains a character which is not
      supported by the server in the context in which it being used.

   FEDFS_ERR_BADXDR  The server encountered an XDR decoding error while
      processing an operation.

   FEDFS_ERR_EXIST  The junction specified already exists.

   FEDFS_ERR_INVAL  Invalid argument for an operation.

   FEDFS_ERR_IO  A hard error occurred while processing the requested
      operation.

   FEDFS_ERR_NOSPC  The requested operation would have caused the
      server's filesystem to exceed some limit (for example, if there is
      a fixed number of junctions per fileset or per server).

   FEDFS_ERR_NOTDIR  The caller specified a non-directory in an
      operation that requires a directory.

   FEDFS_ERR_NOTEMPTY  The caller specified a directory that is not
      empty as the operand of an operation that requires an empty
      directory.







Ellard, et al.           Expires March 30, 2009                 [Page 5]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


   FEDFS_ERR_NOTJUNCT  The caller specified a path that does not end in
      a junction as the operand for an operation that requires the last
      component of the path to be a junction.

   FEDFS_ERR_NOTLOCAL  The caller specified a path that contains a
      junction in any position other than the last component.

   FEDFS_ERR_PERM  The operation was not allowed because the caller is
      either not a privileged user or not the owner of an object that
      would be modified by the operation.

   FEDFS_ERR_ROFS  A modifying operation was attempted on a read-only
      filesystem.

   FEDFS_ERR_SVRFAULT  An unanticipated non-protocol error occurred on
      the server.



































Ellard, et al.           Expires March 30, 2009                 [Page 6]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


4.  Administrator-Initiated Operations

   The RPC protocol used by the administration operations is ONC RPC
   [RFC1831].  The data structures used for the parameters and return
   values of these procedures are expressed in this document in XDR
   [RFC4506].

   In contrast to earlier designs (which are not described in this
   document), the current admin/server interface is very simple.  A
   server is relatively oblivious to the existence of junctions that
   target the filesets it exports: the target server does not play an
   essential role in the creation of junctions that reference them.

4.1.  Basic Definition

   We begin by defining basic constants and structs, in XDR notation,
   that will be used to specify the types of the RPCs described in the
   rest of this subsection.











  enum FedFsStatus {
      FEDFS_OK            = 0,
      FEDFS_ERR_ACCESS    = 1,
      FEDFS_ERR_BADCHAR   = 2,
      FEDFS_ERR_BADXDR    = 3,
      FEDFS_ERR_EXIST     = 4,
      FEDFS_ERR_INVAL     = 5,
      FEDFS_ERR_IO        = 6,
      FEDFS_ERR_NOSPC     = 7,
      FEDFS_ERR_NOTDIR    = 8,
      FEDFS_ERR_NOTEMPTY  = 9,
      FEDFS_ERR_NOTJUNCT  = 10,
      FEDFS_ERR_NOTLOCAL  = 11,
      FEDFS_ERR_PERM      = 12,
      FEDFS_ERR_ROFS      = 13,
      FEDFS_ERR_SVRFAULT  = 14
  };

  typedef opaque FedFsFsnUuid<64>;



Ellard, et al.           Expires March 30, 2009                 [Page 7]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


  typedef opaque FedFsHostName<128>;
  typedef opaque FedFsNsdbName<256>;
  typedef opaque FedFsPathName<1024>;

  struct FedFsFsn {
      FedFsFsnUuid fsnUuid;
      FedFsNsdbName nsdbName;
  };

  struct FedFsCreateJunctionArgs {
      FedFsPathName path;
      FedFsFsn fsn;
      FedFsUuid junctionKey;
  };

  union FedFsLookupFsnRes switch (FedFsStatus status) {
      case FEDFS_OK:
          FedFsFsn fsn;
      default:
          void;
  };

  program FEDFS_PROG {
      version FEDFS_VERSION {
          void NULL(void) = 0;
          FedFsStatus CREATE_JUNCTION(FedFsCreateJunctionArgs args) = 1;
          FedFsStatus DELETE_JUNCTION(FedFsPathName path) = 2;
          FedFsLookupFsnRes LOOKUP_FSN(FedFsPathName path) = 3;
      } = 1;
  } = 100205;


4.2.  Required Operations

   There are three operations that servers MUST implement provide in
   order to serve as "internal" nodes in the federated namespace:

   NULL  The null RPC, which is included, by convention, in every ONC
      RPC protocol.

   CREATE_JUNCTION  Create a new junction from some location on the
      server (defined as a pathname) to an FSN.

   DELETE_JUNCTION  Delete an existing junction from some location on
      the server (defined as a pathname).






Ellard, et al.           Expires March 30, 2009                 [Page 8]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


   LOOKUP_FSN  Query the server to discover the current value of the
      junction (if any) at a given path in the server namespace.

   The CREATE_JUNCTION, DELETE_JUNCTION, and LOOKUP_FSN operations are
   described in more detail in the following sections.

   Servers that implement "leaf" nodes in the namespace (i.e., servers
   that host filesets that are the target of junctions, but that do not
   contain any junctions) are not required to implement any of these
   operations.

   Note that operations that modify the state of a replicated fileset
   MUST result in the update of all of the replicas in a consistent
   manner.  Ideally all of the replicas SHOULD be updated before any
   operation returns.  If one or more of the replicas are unavailable,
   the operation MAY succeed, but the changes MUST be applied before the
   unavailable replicas are brought back online.  We assume that
   replicas are updated via some protocol that permits state changes to
   be reflected consistently across the set of replicas in such a manner
   that the replicas will converge to a consistent state within a
   bounded number of successful message exchanges between the servers
   hosting the replicas.

4.2.1.  CREATE_JUNCTION

   This operation creates a junction from a server-relative path to a
   (potentially) remote fileset named by the given FSN.

   We assume that the junction directory on the server is named by a
   pathname (or other arbitrary UTF-8 string that has a well-defined
   interpretation by the server).  It is not required that this path be
   accessible in any other manner (e.g., to a client).  This path does
   not appear in the federated namespace, except by coincidence; there
   is no requirement that the global namespace parallel the server
   namespace, nor is it required that this path be relative to the
   server pseudo-root.  It does not need to be a path that is accessible
   via NFS (although the junction will be of limited utility if the
   directory specified by the path is not also accessible via NFS).

   If the fileset is read-only, then this operation SHOULD indicate this
   with a status of FEDFS_ERR_ROFS.

   If the path contains an invalid UTF-8 character, then status
   FEDFS_ERR_BADCHAR must be returned.

   The path is REQUIRED to exist and be completely local to the server.
   It MUST NOT contain a junction.  If the last component of the path is
   a junction (i.e., this operation is attempting to create a junction



Ellard, et al.           Expires March 30, 2009                 [Page 9]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


   where one already exists), then this operation MUST return the error
   FEDFS_ERR_EXISTS (even if the requested junction is identical to the
   current junction).  If any other component of the path is a junction,
   then this operation MUST fail with status FEDFS_ERR_NOTLOCAL.  The
   path may contain a symbolic link (if supported by the local server),
   but the traversal of the path must remain within the server-local
   namespace.

   The last component of the path MUST be an empty directory.  If any
   component of the path does not exist, or the final component is not a
   directory, then the operation fails with status FEDFS_ERR_INVAL.

   The server MAY enforce the local permissions on the path, including
   the final component.  If the path cannot be traversed because of
   insufficient permissions, or the final component is an unexecutable
   or unwritable directory, then the operation MAY fail with status
   FEDFS_ERR_ACCESS.

   The association between the path and the FSN MUST be durable before
   the operation may return successfully.  If the operation return codes
   indicates success, then the caller may assume that the junction was
   successfully created and is immediately accessible.

   If successful, subsequent references via NFSv4 clients to the
   directory that has been replaced by junction will result in a
   referral to a current location of the target fileset (as described in
   draft-tewari-nfsv4-federated-fs-protocol).

   Note that the effective permissions of the directory that is
   converted, by this operation, into a junction are the permissions of
   the root directory of the target fileset.  The original permissions
   of the directory (and any other attributes it might have) are
   subsumed by the junction.

   Note that this operation does not create a junction from an arbitrary
   location in the namespace to another location in the namespace.  Such
   an operation can be synthesized from other protocol operations, but
   is not primitive.  It cannot be used, for example, to create the
   initial link to a fileset.

4.2.2.  DELETE_JUNCTION

   This operation removes a junction specified by a server-relative
   path.

   As with CREATE_JUNCTION, we assume that the junction on the server is
   named by a pathname (or other arbitrary UTF-8 string that has a well-
   defined interpretation by the server).  It is not required that this



Ellard, et al.           Expires March 30, 2009                [Page 10]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


   path be accessible in any other manner (e.g., to a client).  This
   path does not appear in the federated namespace, except by
   coincidence; there is no requirement that the global namespace
   reflect the server namespace, nor is it required that this path be
   relative to the server pseudo-root.  It does not need to be a path
   that is accessible via NFS.

   If the fileset is read-only, then this operation SHOULD indicate this
   with a status of FEDFS_ERR_ROFS.

   If the path contains an invalid UTF-8 character, then status
   FEDFS_ERR_BADCHAR must be returned.

   It is NOT REQUIRED that the path used to delete a junction is the
   same path that was used to create the junction.  If the namespace on
   the server has changed, then the junction may now appear at a
   different path than where it was created.  If there is more than one
   valid path to the junction, any of them may be used.

   The path is REQUIRED to exist and be completely local to the server.
   It MUST NOT contain a junction, except as the final component, which
   MUST be a junction.  If any other component of the path is a
   junction, then this operation MUST fail with status
   FEDFS_ERR_NOTLOCAL.  If the last component of the path is not a
   junction then this operation MUST return status FEDFS_ERR_INVAL.  The
   path may contain a symbolic link (if supported by the local server),
   but the traversal of the path must remain within the server-local
   namespace.

   The last component of the path MUST be a junction.  If any component
   of the path does not exist, or the final component is not a junction,
   then the operation fails with status FEDFS_ERR_NOTJUNCT.

   The server MAY enforce the local permissions on the path, including
   the final component.  If the path cannot be traversed because of
   insufficient permissions, or the parent directory of the junction
   unexecutable or unwritable directory, then the operation MAY fail
   with status FEDFS_ERR_ACCESS.

   The removal of the association between the path and the FSN MUST be
   durable before the operation may return successfully.  If the
   operation return codes indicates success, then the caller may assume
   that the junction was successfully destroyed.

   The effective permissions and other attributes of the directory that
   is restored by this operation SHOULD be identical to their value
   prior to the creation of the junction.




Ellard, et al.           Expires March 30, 2009                [Page 11]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


4.2.3.  LOOKUP_FSN

   This operation queries a server to determine whether a given path
   ends in a junction, and if so, the FSN to which the junction refers.

   Ordinary NFSv4 operations do not provide any general mechanism to
   determine whether an object is a junction -- there is no encoding
   specified by the NFSv4 protocol that can represent this information.

   As with CREATE_JUNCTION, we assume that any junction on the server
   can be named by a pathname (or other arbitrary UTF-8 string that has
   a well-defined interpretation by the server).  It is not required
   that this path be accessible in any other manner (e.g., to a client).
   This path does not appear in the federated namespace, except by
   coincidence; there is no requirement that the global namespace
   reflect the server namespace, nor is it required that this path be
   relative to the server pseudo-root.  It does not need to be a path
   that is accessible via NFS.

   If the path contains an invalid UTF-8 character, then status
   FEDFS_ERR_BADCHAR must be returned.

   It is NOT REQUIRED that the path used to lookup a junction is the
   same path that was used to create the junction.  If the namespace on
   the server has changed, then a junction may now appear at a different
   path than where it was created.  If there is more than one valid path
   to the junction, any of them may be used.

   The path is REQUIRED to exist and be completely local to the server.
   It MUST NOT contain a junction, except as the final component.  If
   any other component of the path is a junction, then this operation
   MUST fail with status FEDFS_ERR_NOTLOCAL.  If the last component of
   the path is not a junction then this operation MUST return the status
   FEDFS_ERR_NOTJUNCT.  The path may contain a symbolic link (if
   supported by the local server), but the traversal of the path must
   remain within the server-local namespace.

   The server MAY enforce the local permissions on the path, including
   the final component.  If the path cannot be traversed because of
   insufficient permissions, or the parent directory of the junction
   unexecutable or unwritable directory, then the operation MAY fail
   with status FEDFS_ERR_ACCESS.









Ellard, et al.           Expires March 30, 2009                [Page 12]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


5.  Security Considerations

   To be added.
















































Ellard, et al.           Expires March 30, 2009                [Page 13]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


6.  IANA Requirements

   The RPC protocol must be assigned a valid and reserved ONC RPC
   protocol number.















































Ellard, et al.           Expires March 30, 2009                [Page 14]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


7.  Conclusions

   The federated filesystem protocol manages multiple independently
   administered fileservers to share namespace and referral information
   to enable clients to traverse seamlessly across them.














































Ellard, et al.           Expires March 30, 2009                [Page 15]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


8.  Glossary

   Administrator:  user with the necessary authority to initiate
      administrative tasks on one or more servers.

   Admin entity:  A server or agent that administers a collection of
      fileservers and persistently stores the namespace information.

   Client:  Any client that accesses the fileserver data using a
      supported filesystem access protocol.

   Federation:  A set of server collections and singleton servers that
      use a common set of interfaces and protocols in order to provide
      to their clients a federated namespace accessible through a
      filesystem access protocol.

   Fileserver:  A server exporting a filesystem via a network filesystem
      access protocol.

   Fileset:  The abstraction of a set of files and their containing
      directory tree.  A fileset is the fundamental unit of data
      management in the federation.

      Note that all files within a fileset are descendants of one
      directory, and that filesets do not span filesystems.

   Filesystem:  A self-contained unit of export for a fileserver, and
      the mechanism used to implement filesets.  The fileset does not
      need to be rooted at the root of the filesystem, nor at the export
      point for the filesystem.

      A single filesystem MAY implement more than one fileset, if the
      client protocol and the fileserver permit this.

   Filesystem access protocol:  A network filesystem access protocol
      such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or
      CIFS.

   FSL (Fileset location):  The location of the implementation of a
      fileset at a particular moment in time.  A FSL MUST be something
      that can be translated into a protocol-specific description of a
      resource that a client can access directly, such as a fs_location
      (for NFSv4), or share name (for CIFS).  Note that not all FSLs
      need to be explicitly exported as long as they are contained
      within an exported path on the fileserver.






Ellard, et al.           Expires March 30, 2009                [Page 16]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


   FSN (Fileset name):  A platform-independent and globally unique name
      for a fileset.  Two FSLs that implement replicas of the same
      fileset MUST have the same FSN, and if a fileset is migrated from
      one location to another, the FSN of that fileset MUST remain the
      same.

   Junction:  A filesystem object used to link a directory name in the
      current fileset with an object within another fileset.  The
      server-side "link" from a leaf node in one fileset to the root of
      another fileset.

   Junction key:  The UUID of a fileset, used as a key to lookup an FSN
      within an NSDB node or a local table of information about
      junctions.

   Namespace:  A filename/directory tree that a sufficiently-authorized
      client can observe.

   NSDB (Namespace Database Service):  A service that maps FSNs to FSLs.
      The NSDB may also be used to store other information, such as
      annotations for these mappings and their components.

   NSDB Node:  The name or location of a server that implements part of
      the NSDB service and is responsible for keeping track of the FSLs
      (and related info) that implement a given partition of the FSNs.

   Referral:  A server response to a client access that directs the
      client to evaluate the current object as a reference to an object
      at a different location (specified by an FSL) in another fileset,
      and possibly hosted on another fileserver.  The client re-attempts
      the access to the object at the new location.

   Replica:  A replica is a redundant implementation of a fileset.  Each
      replica shares the same FSN, but has a different FSL.

      Replicas may be used to increase availability or performance.
      Updates to replicas of the same fileset MUST appear to occur in
      the same order, and therefore each replica is self-consistent at
      any moment.

      We do not assume that updates to each replica occur simultaneously
      If a replica is offline or unreachable, the other replicas may be
      updated.

   Server Collection:  A set of fileservers administered as a unit.  A
      server collection may be administered with vendor-specific
      software.




Ellard, et al.           Expires March 30, 2009                [Page 17]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


      The namespace provided by a server collection could be part of the
      federated namespace.

   Singleton Server:  A server collection containing only one server; a
      stand-alone fileserver.














































Ellard, et al.           Expires March 30, 2009                [Page 18]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


9.  Normative References

   [RFC1094]  Nowicki, B., "NFS: Network File System Protocol
              specification", RFC 1094, March 1989.

   [RFC1813]  Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
              Version 3 Protocol Specification", RFC 1813, June 1995.

   [RFC1831]  Srinivasan, R., "RPC: Remote Procedure Call Protocol
              Specification Version 2", RFC 1831, August 1995.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
              Beame, C., Eisler, M., and D. Noveck, "Network File System
              (NFS) version 4 Protocol", RFC 3530, April 2003.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              July 2005.

   [RFC4506]  Eisler, M., "XDR: External Data Representation Standard",
              STD 67, RFC 4506, May 2006.



























Ellard, et al.           Expires March 30, 2009                [Page 19]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


Authors' Addresses

   Daniel Ellard
   BBN Technologies
   10 Moulton Street
   Cambridge, MA  02138
   US

   Phone: +1 617-873-8000
   Email: ellard@gmail.com


   Craig Everhart
   NetApp
   7301 Kit Creek Rd
   Research Triangle Park, NC  27709
   US

   Phone: +1 919-476-5320
   Email: everhart@netapp.com


   James Lentini
   NetApp
   1601 Trapelo Rd, Suite 16
   Waltham, MA  02451
   US

   Phone: +1 781-768-5359
   Email: jlentini@netapp.com


   Renu Tewari
   IBM Almaden
   650 Harry Rd
   San Jose, CA  95120
   US

   Email: tewarir@us.ibm.com












Ellard, et al.           Expires March 30, 2009                [Page 20]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


   Manoj Naik
   IBM Almaden
   650 Harry Rd
   San Jose, CA  95120
   US

   Email: manoj@almaden.ibm.com












































Ellard, et al.           Expires March 30, 2009                [Page 21]


Internet-Draft  Admin Protocol for Federated Filesystems  September 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Ellard, et al.           Expires March 30, 2009                [Page 22]