idnits 2.17.1 draft-ellard-nfsv4-federated-fs-admin-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 664. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 5, 2008) is 5742 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4122' is defined on line 583, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1094 ** Downref: Normative reference to an Informational RFC: RFC 1813 ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531) ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Ellard 3 Internet-Draft C. Everhart 4 Intended status: Standards Track NetApp, Inc. 5 Expires: February 6, 2009 R. Tewari 6 M. Naik 7 IBM Almaden 8 August 5, 2008 10 Administration Protocol for Federated Filesystems 11 draft-ellard-nfsv4-federated-fs-admin-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on February 6, 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document describes the administration protocol for a federated 45 file system that enables file access and namespace traversal across 46 collections of independently administered fileservers. The protocol 47 specifies a set of interfaces by which fileservers and collections of 48 fileservers with different administrators can form a fileserver 49 federation that provides a namespace composed of the filesystems 50 physically hosted on and exported by the constituent fileservers. 52 Table of Contents 54 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Error Definitions . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Administrator-Initiated Operations . . . . . . . . . . . . . . 7 58 4.1. Basic Definition . . . . . . . . . . . . . . . . . . . . . 7 59 4.2. Required Operations . . . . . . . . . . . . . . . . . . . 8 60 4.2.1. CREATE_JUNCTION . . . . . . . . . . . . . . . . . . . 9 61 4.2.2. DELETE_JUNCTION . . . . . . . . . . . . . . . . . . . 10 62 4.2.3. LOOKUP_FSN . . . . . . . . . . . . . . . . . . . . . . 11 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 64 6. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 14 65 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 9. Normative References . . . . . . . . . . . . . . . . . . . . . 19 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 69 Intellectual Property and Copyright Statements . . . . . . . . . . 21 71 1. Requirements notation 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Introduction 79 A federated filesystem enables file access and namespace traversal in 80 a uniform, secure and consistent manner across multiple independent 81 fileservers within an enterprise (and possibly across multiple 82 enterprises) with reasonably good performance. 84 The first requirement of a federated filesystem is the ability to 85 traverse the data exported by different fileservers without requiring 86 a static client configuration. The second requirement is that the 87 location of the data should be dynamically discovered and the 88 discovery process should be transparent to the clients. The third 89 requirement is that it should be possible for all clients, with 90 sufficient privilege, to view the same namespace regardless of the 91 fileserver they connect to. 93 Traditionally, fileserver collections are administered by a single 94 entity. Fileservers may provide proprietary management tools and in 95 some cases an administrator may be able to use the proprietary tools 96 to build a shared namespace out of the exported filesystems. Relying 97 on vendor-proprietary tools does not work in larger enterprises or 98 when collaborating across enterprises because it is likely that the 99 system will contain fileservers running different software, each with 100 their own interfaces, with no common protocol to manage the namespace 101 or exchange namespace information. There may also be independently- 102 administered singleton servers that export some or all of their 103 filesystem resources. A filesystem federation protocol enables the 104 interoperation across multi-vendor fileservers managed by the same 105 administrative entity, across singleton independent fileservers, and 106 across independent administrative entities that may manage a 107 collection of fileservers. The scope of the filesystem federation 108 protocol is limited to NFSv4 capable fileservers. The support for 109 NFSv3 fileservers is optional. 111 The basic requirements for a federated file system protocol are 112 described in IETF draft draft-ellard-nfsv4-federated-fs-reqts, and 113 the current proposed protocol is described in 114 draft-tewari-nfsv4-federated-fs-protocol. Those drafts are 115 companions (and essential background material) to this document. 116 Please refer to those documents for the definitions of basic terms 117 and concepts used in this document. 119 3. Error Definitions 121 The results of successful operations will consist of a status of 122 FEDFS_OK. The results of unsuccessful operations will begin with a 123 status, other than FEDFS_OK, that indicates the reason why the 124 operation failed. 126 Many of the error status names and meanings (and the prose for their 127 descriptions) are taken from the specification for NFSv4 [RFC3530]. 128 Note, however, that the literal values for the status codes are 129 different. 131 Note that the status of an unsuccessful operation will generally only 132 indicate the first error encountered during the attempt to execute 133 the operation. 135 FEDFS_OK No errors were encountered. The operation was a success. 137 FEDFS_ERR_ACCESS Permission denied. The caller does not have the 138 correct permission to perform the requested operation. 140 FEDFS_ERR_BADCHAR A UTF-8 string contains a character which is not 141 supported by the server in the context in which it being used. 143 FEDFS_ERR_BADXDR The server encountered an XDR decoding error while 144 processing an operation. 146 FEDFS_ERR_EXIST The junction specified already exists. 148 FEDFS_ERR_INVAL Invalid argument for an operation. 150 FEDFS_ERR_IO A hard error occurred while processing the requested 151 operation. 153 FEDFS_ERR_NOSPC The requested operation would have caused the 154 server's filesystem to exceed some limit (for example, if there is 155 a fixed number of junctions per fileset or per server). 157 FEDFS_ERR_NOTDIR The caller specified a non-directory in an 158 operation that requires a directory. 160 FEDFS_ERR_NOTEMPTY The caller specified a directory that is not 161 empty as the operand of an operation that requires an empty 162 directory. 164 FEDFS_ERR_NOTJUNCT The caller specified a path that does not end in 165 a junction as the operand for an operation that requires the last 166 component of the path to be a junction. 168 FEDFS_ERR_NOTLOCAL The caller specified a path that contains a 169 junction in any position other than the last component. 171 FEDFS_ERR_PERM The operation was not allowed because the caller is 172 either not a privileged user or not the owner of an object that 173 would be modified by the operation. 175 FEDFS_ERR_ROFS A modifying operation was attempted on a read-only 176 filesystem. 178 FEDFS_ERR_SVRFAULT An unanticipated non-protocol error occurred on 179 the server. 181 4. Administrator-Initiated Operations 183 The RPC protocol used by the administration operations is ONC RPC 184 [RFC1831]. The data structures used for the parameters and return 185 values of these procedures are expressed in this document in XDR 186 [RFC4506]. 188 In contrast to earlier designs (which are not described in this 189 document), the current admin/server interface is very simple. A 190 server is relatively oblivious to the existence of junctions that 191 target the filesets it exports: the target server does not play an 192 essential role in the creation of junctions that reference them. 194 4.1. Basic Definition 196 We begin by defining basic constants and structs, in XDR notation, 197 that will be used to specify the types of the RPCs described in the 198 rest of this subsection. 200 enum FedFsStatus { 201 FEDFS_OK = 0, 202 FEDFS_ERR_ACCESS = 1, 203 FEDFS_ERR_BADCHAR = 2, 204 FEDFS_ERR_BADXDR = 3, 205 FEDFS_ERR_EXIST = 4, 206 FEDFS_ERR_INVAL = 5, 207 FEDFS_ERR_IO = 6, 208 FEDFS_ERR_NOSPC = 7, 209 FEDFS_ERR_NOTDIR = 8, 210 FEDFS_ERR_NOTEMPTY = 9, 211 FEDFS_ERR_NOTJUNCT = 10, 212 FEDFS_ERR_NOTLOCAL = 11, 213 FEDFS_ERR_PERM = 12, 214 FEDFS_ERR_ROFS = 13, 215 FEDFS_ERR_SVRFAULT = 14 216 }; 218 typedef opaque FedFsFsnUuid<64>; 219 typedef opaque FedFsHostName<128>; 220 typedef opaque FedFsNsdbName<256>; 221 typedef opaque FedFsPathName<1024>; 222 struct FedFsFsn { 223 FedFsFsnUuid fsnUuid; 224 FedFsNsdbName nsdbName; 225 }; 227 struct FedFsCreateJunctionArgs { 228 FedFsPathName path; 229 FedFsFsn fsn; 230 FedFsUuid junctionKey; 231 }; 233 union FedFsLookupFsnRes switch (FedFsStatus status) { 234 case FEDFS_OK: 235 FedFsFsn fsn; 236 default: 237 void; 238 }; 240 program FEDFS_PROG { 241 version FEDFS_VERSION { 242 void NULL(void) = 0; 243 FedFsStatus CREATE_JUNCTION(FedFsCreateJunctionArgs args) = 1; 244 FedFsStatus DELETE_JUNCTION(FedFsPathName path) = 2; 245 FedFsLookupFsnRes LOOKUP_FSN(FedFsPathName path) = 3; 246 } = 1; 247 } = 100205; 249 4.2. Required Operations 251 There are three operations that servers MUST implement provide in 252 order to serve as "internal" nodes in the federated namespace: 254 NULL The null RPC, which is included, by convention, in every ONC 255 RPC protocol. 257 CREATE_JUNCTION Create a new junction from some location on the 258 server (defined as a pathname) to an FSN. 260 DELETE_JUNCTION Delete an existing junction from some location on 261 the server (defined as a pathname). 263 LOOKUP_FSN Query the server to discover the current value of the 264 junction (if any) at a given path in the server namespace. 266 The CREATE_JUNCTION, DELETE_JUNCTION, and LOOKUP_FSN operations are 267 described in more detail in the following sections. 269 Servers that implement "leaf" nodes in the namespace (i.e., servers 270 that host filesets that are the target of junctions, but that do not 271 contain any junctions) are not required to implement any of these 272 operations. 274 Note that operations that modify the state of a replicated fileset 275 MUST result in the update of all of the replicas in a consistent 276 manner. Ideally all of the replicas SHOULD be updated before any 277 operation returns. If one or more of the replicas are unavailable, 278 the operation MAY succeed, but the changes MUST be applied before the 279 unavailable replicas are brought back online. We assume that 280 replicas are updated via some protocol that permits state changes to 281 be reflected consistently across the set of replicas in such a manner 282 that the replicas will converge to a consistent state within a 283 bounded number of successful message exchanges between the servers 284 hosting the replicas. 286 4.2.1. CREATE_JUNCTION 288 This operation creates a junction from a server-relative path to a 289 (potentially) remote fileset named by the given FSN. 291 We assume that the junction directory on the server is named by a 292 pathname (or other arbitrary UTF-8 string that has a well-defined 293 interpretation by the server). It is not required that this path be 294 accessible in any other manner (e.g., to a client). This path does 295 not appear in the federated namespace, except by coincidence; there 296 is no requirement that the global namespace parallel the server 297 namespace, nor is it required that this path be relative to the 298 server pseudo-root. It does not need to be a path that is accessible 299 via NFS (although the junction will be of limited utility if the 300 directory specified by the path is not also accessible via NFS). 302 If the fileset is read-only, then this operation SHOULD indicate this 303 with a status of FEDFS_ERR_ROFS. 305 If the path contains an invalid UTF-8 character, then status 306 FEDFS_ERR_BADCHAR must be returned. 308 The path is REQUIRED to exist and be completely local to the server. 309 It MUST NOT contain a junction. If the last component of the path is 310 a junction (i.e., this operation is attempting to create a junction 311 where one already exists), then this operation MUST return the error 312 FEDFS_ERR_EXISTS (even if the requested junction is identical to the 313 current junction). If any other component of the path is a junction, 314 then this operation MUST fail with status FEDFS_ERR_NOTLOCAL. The 315 path may contain a symbolic link (if supported by the local server), 316 but the traversal of the path must remain within the server-local 317 namespace. 319 The last component of the path MUST be an empty directory. If any 320 component of the path does not exist, or the final component is not a 321 directory, then the operation fails with status FEDFS_ERR_INVAL. 323 The server MAY enforce the local permissions on the path, including 324 the final component. If the path cannot be traversed because of 325 insufficient permissions, or the final component is an unexecutable 326 or unwritable directory, then the operation MAY fail with status 327 FEDFS_ERR_ACCESS. 329 The association between the path and the FSN MUST be durable before 330 the operation may return successfully. If the operation return codes 331 indicates success, then the caller may assume that the junction was 332 successfully created and is immediately accessible. 334 If successful, subsequent references via NFSv4 clients to the 335 directory that has been replaced by junction will result in a 336 referral to a current location of the target fileset (as described in 337 draft-tewari-nfsv4-federated-fs-protocol). 339 Note that the effective permissions of the directory that is 340 converted, by this operation, into a junction are the permissions of 341 the root directory of the target fileset. The original permissions 342 of the directory (and any other attributes it might have) are 343 subsumed by the junction. 345 Note that this operation does not create a junction from an arbitrary 346 location in the namespace to another location in the namespace. Such 347 an operation can be synthesized from other protocol operations, but 348 is not primitive. It cannot be used, for example, to create the 349 initial link to a fileset. 351 4.2.2. DELETE_JUNCTION 353 This operation removes a junction specified by a server-relative 354 path. 356 As with CREATE_JUNCTION, we assume that the junction on the server is 357 named by a pathname (or other arbitrary UTF-8 string that has a well- 358 defined interpretation by the server). It is not required that this 359 path be accessible in any other manner (e.g., to a client). This 360 path does not appear in the federated namespace, except by 361 coincidence; there is no requirement that the global namespace 362 reflect the server namespace, nor is it required that this path be 363 relative to the server pseudo-root. It does not need to be a path 364 that is accessible via NFS. 366 If the fileset is read-only, then this operation SHOULD indicate this 367 with a status of FEDFS_ERR_ROFS. 369 If the path contains an invalid UTF-8 character, then status 370 FEDFS_ERR_BADCHAR must be returned. 372 It is NOT REQUIRED that the path used to delete a junction is the 373 same path that was used to create the junction. If the namespace on 374 the server has changed, then the junction may now appear at a 375 different path than where it was created. If there is more than one 376 valid path to the junction, any of them may be used. 378 The path is REQUIRED to exist and be completely local to the server. 379 It MUST NOT contain a junction, except as the final component, which 380 MUST be a junction. If any other component of the path is a 381 junction, then this operation MUST fail with status 382 FEDFS_ERR_NOTLOCAL. If the last component of the path is not a 383 junction then this operation MUST return status FEDFS_ERR_INVAL. The 384 path may contain a symbolic link (if supported by the local server), 385 but the traversal of the path must remain within the server-local 386 namespace. 388 The last component of the path MUST be a junction. If any component 389 of the path does not exist, or the final component is not a junction, 390 then the operation fails with status FEDFS_ERR_NOTJUNCT. 392 The server MAY enforce the local permissions on the path, including 393 the final component. If the path cannot be traversed because of 394 insufficient permissions, or the parent directory of the junction 395 unexecutable or unwritable directory, then the operation MAY fail 396 with status FEDFS_ERR_ACCESS. 398 The removal of the association between the path and the FSN MUST be 399 durable before the operation may return successfully. If the 400 operation return codes indicates success, then the caller may assume 401 that the junction was successfully destroyed. 403 The effective permissions and other attributes of the directory that 404 is restored by this operation SHOULD be identical to their value 405 prior to the creation of the junction. 407 4.2.3. LOOKUP_FSN 409 This operation queries a server to determine whether a given path 410 ends in a junction, and if so, the FSN to which the junction refers. 412 Ordinary NFSv4 operations do not provide any general mechanism to 413 determine whether an object is a junction -- there is no encoding 414 specified by the NFSv4 protocol that can represent this information. 416 As with CREATE_JUNCTION, we assume that any junction on the server 417 can be named by a pathname (or other arbitrary UTF-8 string that has 418 a well-defined interpretation by the server). It is not required 419 that this path be accessible in any other manner (e.g., to a client). 420 This path does not appear in the federated namespace, except by 421 coincidence; there is no requirement that the global namespace 422 reflect the server namespace, nor is it required that this path be 423 relative to the server pseudo-root. It does not need to be a path 424 that is accessible via NFS. 426 If the path contains an invalid UTF-8 character, then status 427 FEDFS_ERR_BADCHAR must be returned. 429 It is NOT REQUIRED that the path used to lookup a junction is the 430 same path that was used to create the junction. If the namespace on 431 the server has changed, then a junction may now appear at a different 432 path than where it was created. If there is more than one valid path 433 to the junction, any of them may be used. 435 The path is REQUIRED to exist and be completely local to the server. 436 It MUST NOT contain a junction, except as the final component. If 437 any other component of the path is a junction, then this operation 438 MUST fail with status FEDFS_ERR_NOTLOCAL. If the last component of 439 the path is not a junction then this operation MUST return the status 440 FEDFS_ERR_NOTJUNCT. The path may contain a symbolic link (if 441 supported by the local server), but the traversal of the path must 442 remain within the server-local namespace. 444 The server MAY enforce the local permissions on the path, including 445 the final component. If the path cannot be traversed because of 446 insufficient permissions, or the parent directory of the junction 447 unexecutable or unwritable directory, then the operation MAY fail 448 with status FEDFS_ERR_ACCESS. 450 5. Security Considerations 452 To be added. 454 6. IANA Requirements 456 The RPC protocol must be assigned a valid and reserved ONC RPC 457 protocol number. 459 7. Conclusions 461 The federated filesystem protocol manages multiple independently 462 administered fileservers to share namespace and referral information 463 to enable clients to traverse seamlessly across them. 465 8. Glossary 467 Administrator: user with the necessary authority to initiate 468 administrative tasks on one or more servers. 470 Admin entity: A server or agent that administers a collection of 471 fileservers and persistently stores the namespace information. 473 Client: Any client that accesses the fileserver data using a 474 supported filesystem access protocol. 476 Federation: A set of server collections and singleton servers that 477 use a common set of interfaces and protocols in order to provide 478 to their clients a federated namespace accessible through a 479 filesystem access protocol. 481 Fileserver: A server exporting a filesystem via a network filesystem 482 access protocol. 484 Fileset: The abstraction of a set of files and their containing 485 directory tree. A fileset is the fundamental unit of data 486 management in the federation. 488 Note that all files within a fileset are descendants of one 489 directory, and that filesets do not span filesystems. 491 Filesystem: A self-contained unit of export for a fileserver, and 492 the mechanism used to implement filesets. The fileset does not 493 need to be rooted at the root of the filesystem, nor at the export 494 point for the filesystem. 496 A single filesystem MAY implement more than one fileset, if the 497 client protocol and the fileserver permit this. 499 Filesystem access protocol: A network filesystem access protocol 500 such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or 501 CIFS. 503 FSL (Fileset location): The location of the implementation of a 504 fileset at a particular moment in time. A FSL MUST be something 505 that can be translated into a protocol-specific description of a 506 resource that a client can access directly, such as a fs_location 507 (for NFSv4), or share name (for CIFS). Note that not all FSLs 508 need to be explicitly exported as long as they are contained 509 within an exported path on the fileserver. 511 FSN (Fileset name): A platform-independent and globally unique name 512 for a fileset. Two FSLs that implement replicas of the same 513 fileset MUST have the same FSN, and if a fileset is migrated from 514 one location to another, the FSN of that fileset MUST remain the 515 same. 517 Junction: A filesystem object used to link a directory name in the 518 current fileset with an object within another fileset. The 519 server-side "link" from a leaf node in one fileset to the root of 520 another fileset. 522 Junction key: The UUID of a fileset, used as a key to lookup an FSN 523 within an NSDB node or a local table of information about 524 junctions. 526 Namespace: A filename/directory tree that a sufficiently-authorized 527 client can observe. 529 NSDB (Namespace Database Service): A service that maps FSNs to FSLs. 530 The NSDB may also be used to store other information, such as 531 annotations for these mappings and their components. 533 NSDB Node: The name or location of a server that implements part of 534 the NSDB service and is responsible for keeping track of the FSLs 535 (and related info) that implement a given partition of the FSNs. 537 Referral: A server response to a client access that directs the 538 client to evaluate the current object as a reference to an object 539 at a different location (specified by an FSL) in another fileset, 540 and possibly hosted on another fileserver. The client re-attempts 541 the access to the object at the new location. 543 Replica: A replica is a redundant implementation of a fileset. Each 544 replica shares the same FSN, but has a different FSL. 546 Replicas may be used to increase availability or performance. 547 Updates to replicas of the same fileset MUST appear to occur in 548 the same order, and therefore each replica is self-consistent at 549 any moment. 551 We do not assume that updates to each replica occur simultaneously 552 If a replica is offline or unreachable, the other replicas may be 553 updated. 555 Server Collection: A set of fileservers administered as a unit. A 556 server collection may be administered with vendor-specific 557 software. 559 The namespace provided by a server collection could be part of the 560 federated namespace. 562 Singleton Server: A server collection containing only one server; a 563 stand-alone fileserver. 565 9. Normative References 567 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 568 specification", RFC 1094, March 1989. 570 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 571 Version 3 Protocol Specification", RFC 1813, June 1995. 573 [RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol 574 Specification Version 2", RFC 1831, August 1995. 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, March 1997. 579 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 580 Beame, C., Eisler, M., and D. Noveck, "Network File System 581 (NFS) version 4 Protocol", RFC 3530, April 2003. 583 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 584 Unique IDentifier (UUID) URN Namespace", RFC 4122, 585 July 2005. 587 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 588 STD 67, RFC 4506, May 2006. 590 Authors' Addresses 592 Daniel Ellard 593 NetApp, Inc. 594 1601 Trapelo Rd, Suite 16 595 Waltham, MA 02451 596 US 598 Phone: +1 781-768-5421 599 Email: ellard@netapp.com 601 Craig Everhart 602 NetApp, Inc. 603 7301 Kit Creek Rd 604 Research Triangle Park, NC 27709 605 US 607 Phone: +1 919-476-5320 608 Email: everhart@netapp.com 610 Renu Tewari 611 IBM Almaden 612 650 Harry Rd 613 San Jose, CA 95120 614 US 616 Email: tewarir@us.ibm.com 618 Manoj Naik 619 IBM Almaden 620 650 Harry Rd 621 San Jose, CA 95120 622 US 624 Email: manoj@almaden.ibm.com 626 Full Copyright Statement 628 Copyright (C) The IETF Trust (2008). 630 This document is subject to the rights, licenses and restrictions 631 contained in BCP 78, and except as set forth therein, the authors 632 retain all their rights. 634 This document and the information contained herein are provided on an 635 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 636 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 637 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 638 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 639 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 640 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 642 Intellectual Property 644 The IETF takes no position regarding the validity or scope of any 645 Intellectual Property Rights or other rights that might be claimed to 646 pertain to the implementation or use of the technology described in 647 this document or the extent to which any license under such rights 648 might or might not be available; nor does it represent that it has 649 made any independent effort to identify any such rights. Information 650 on the procedures with respect to rights in RFC documents can be 651 found in BCP 78 and BCP 79. 653 Copies of IPR disclosures made to the IETF Secretariat and any 654 assurances of licenses to be made available, or the result of an 655 attempt made to obtain a general license or permission for the use of 656 such proprietary rights by implementers or users of this 657 specification can be obtained from the IETF on-line IPR repository at 658 http://www.ietf.org/ipr. 660 The IETF invites any interested party to bring to its attention any 661 copyrights, patents or patent applications, or other proprietary 662 rights that may cover technology that may be required to implement 663 this standard. Please address the information to the IETF at 664 ietf-ipr@ietf.org. 666 Acknowledgment 668 Funding for the RFC Editor function is provided by the IETF 669 Administrative Support Activity (IASA).