Internet DRAFT - draft-ellard-nfsv4-federated-fs-admin
draft-ellard-nfsv4-federated-fs-admin
Network Working Group D. Ellard
Internet-Draft C. Everhart
Intended status: Standards Track NetApp, Inc.
Expires: February 6, 2009 R. Tewari
M. Naik
IBM Almaden
August 5, 2008
Administration Protocol for Federated Filesystems
draft-ellard-nfsv4-federated-fs-admin-02.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 February 6, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Ellard, et al. Expires February 6, 2009 [Page 1]
Internet-Draft Admin Protocol for Federated Filesystems August 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 . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . 21
Ellard, et al. Expires February 6, 2009 [Page 2]
Internet-Draft Admin Protocol for Federated Filesystems August 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 February 6, 2009 [Page 3]
Internet-Draft Admin Protocol for Federated Filesystems August 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 February 6, 2009 [Page 4]
Internet-Draft Admin Protocol for Federated Filesystems August 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 February 6, 2009 [Page 5]
Internet-Draft Admin Protocol for Federated Filesystems August 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 February 6, 2009 [Page 6]
Internet-Draft Admin Protocol for Federated Filesystems August 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>;
typedef opaque FedFsHostName<128>;
typedef opaque FedFsNsdbName<256>;
typedef opaque FedFsPathName<1024>;
Ellard, et al. Expires February 6, 2009 [Page 7]
Internet-Draft Admin Protocol for Federated Filesystems August 2008
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).
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.
Ellard, et al. Expires February 6, 2009 [Page 8]
Internet-Draft Admin Protocol for Federated Filesystems August 2008
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
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
Ellard, et al. Expires February 6, 2009 [Page 9]
Internet-Draft Admin Protocol for Federated Filesystems August 2008
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
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.
Ellard, et al. Expires February 6, 2009 [Page 10]
Internet-Draft Admin Protocol for Federated Filesystems August 2008
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.
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
Ellard, et al. Expires February 6, 2009 [Page 11]
Internet-Draft Admin Protocol for Federated Filesystems August 2008
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 February 6, 2009 [Page 12]
Internet-Draft Admin Protocol for Federated Filesystems August 2008
5. Security Considerations
To be added.
Ellard, et al. Expires February 6, 2009 [Page 13]
Internet-Draft Admin Protocol for Federated Filesystems August 2008
6. IANA Requirements
The RPC protocol must be assigned a valid and reserved ONC RPC
protocol number.
Ellard, et al. Expires February 6, 2009 [Page 14]
Internet-Draft Admin Protocol for Federated Filesystems August 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 February 6, 2009 [Page 15]
Internet-Draft Admin Protocol for Federated Filesystems August 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 February 6, 2009 [Page 16]
Internet-Draft Admin Protocol for Federated Filesystems August 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 February 6, 2009 [Page 17]
Internet-Draft Admin Protocol for Federated Filesystems August 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 February 6, 2009 [Page 18]
Internet-Draft Admin Protocol for Federated Filesystems August 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 February 6, 2009 [Page 19]
Internet-Draft Admin Protocol for Federated Filesystems August 2008
Authors' Addresses
Daniel Ellard
NetApp, Inc.
1601 Trapelo Rd, Suite 16
Waltham, MA 02451
US
Phone: +1 781-768-5421
Email: ellard@netapp.com
Craig Everhart
NetApp, Inc.
7301 Kit Creek Rd
Research Triangle Park, NC 27709
US
Phone: +1 919-476-5320
Email: everhart@netapp.com
Renu Tewari
IBM Almaden
650 Harry Rd
San Jose, CA 95120
US
Email: tewarir@us.ibm.com
Manoj Naik
IBM Almaden
650 Harry Rd
San Jose, CA 95120
US
Email: manoj@almaden.ibm.com
Ellard, et al. Expires February 6, 2009 [Page 20]
Internet-Draft Admin Protocol for Federated Filesystems August 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 February 6, 2009 [Page 21]
