draft-ietf-nfsv4-federated-fs-reqts-03.txt | draft-ietf-nfsv4-federated-fs-reqts-04.txt | |||
---|---|---|---|---|
NFSv4 Working Group J. Lentini | NFSv4 Working Group J. Lentini | |||
Internet-Draft C. Everhart | Internet-Draft C. Everhart | |||
Intended status: Informational NetApp | Intended status: Informational NetApp | |||
Expires: November 19, 2009 D. Ellard | Expires: April 4, 2010 D. Ellard | |||
BBN Technologies | BBN Technologies | |||
R. Tewari | R. Tewari | |||
M. Naik | M. Naik | |||
IBM Almaden | IBM Almaden | |||
May 18, 2009 | October 1, 2009 | |||
Requirements for Federated File Systems | Requirements for Federated File Systems | |||
draft-ietf-nfsv4-federated-fs-reqts-03 | draft-ietf-nfsv4-federated-fs-reqts-04 | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. This document may contain material | |||
from IETF Documents or IETF Contributions published or made publicly | ||||
available before November 10, 2008. The person(s) controlling the | ||||
copyright in some of this material may not have granted the IETF | ||||
Trust the right to allow modifications of such material outside the | ||||
IETF Standards Process. Without obtaining an adequate license from | ||||
the person(s) controlling the copyright in such materials, this | ||||
document may not be modified outside the IETF Standards Process, and | ||||
derivative works of it may not be created outside the IETF Standards | ||||
Process, except to format it for publication as an RFC or to | ||||
translate it into languages other than English. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on November 19, 2009. | This Internet-Draft will expire on April 4, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents in effect on the date of | |||
publication of this document (http://trustee.ietf.org/license-info). | publication of this document (http://trustee.ietf.org/license-info). | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. | and restrictions with respect to this document. | |||
Abstract | Abstract | |||
skipping to change at page 2, line 10 | skipping to change at page 4, line 5 | |||
Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents in effect on the date of | |||
publication of this document (http://trustee.ietf.org/license-info). | publication of this document (http://trustee.ietf.org/license-info). | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. | and restrictions with respect to this document. | |||
Abstract | Abstract | |||
This document describes and lists the functional requirements of a | This document describes and lists the functional requirements of a | |||
federated file system and defines related terms. | federated file system and defines related terms. | |||
Table of Contents | Requirements Language | |||
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 | ||||
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | ||||
3. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | ||||
4. Examples and Discussion . . . . . . . . . . . . . . . . . . . 7 | ||||
4.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 7 | ||||
4.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 7 | ||||
4.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 8 | ||||
4.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 8 | ||||
4.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 10 | ||||
5. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
6. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 15 | ||||
6.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 15 | ||||
6.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 | ||||
7. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 25 | ||||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 | ||||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | ||||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 | ||||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 | ||||
10.2. Informational References . . . . . . . . . . . . . . . . . 28 | ||||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 29 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 | ||||
1. Requirements notation | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
Note, that this is a requirements document, and in many instances | Note, that this is a requirements document, and in many instances | |||
where these words are used in this document they refer to qualities | where these words are used in this document they refer to qualities | |||
of a specification for a system that satisfies the document, or | of a specification for a system that satisfies the document, or | |||
requirements of a system that matches that specification. These | requirements of a system that matches that specification. These | |||
cases are distinguished when there is potential for ambiguity. | cases are distinguished when there is potential for ambiguity. | |||
2. Overview | Table of Contents | |||
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | ||||
2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | ||||
3. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8 | ||||
3.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 8 | ||||
3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 8 | ||||
3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 9 | ||||
3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 9 | ||||
3.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 11 | ||||
4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
5. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 16 | ||||
5.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 16 | ||||
5.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 | ||||
6. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 26 | ||||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | ||||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | ||||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | ||||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 | ||||
9.2. Informational References . . . . . . . . . . . . . . . . . 29 | ||||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 | ||||
1. Overview | ||||
This document describes and lists the functional requirements of a | This document describes and lists the functional requirements of a | |||
federated file system and defines related terms. | federated file system and defines related terms. | |||
We do not describe the mechanisms that might be used to implement | We do not describe the mechanisms that might be used to implement | |||
this functionality except in cases where specific mechanisms, in our | this functionality except in cases where specific mechanisms, in our | |||
opinion, follow inevitably from the requirements. Our focus is on | opinion, follow inevitably from the requirements. Our focus is on | |||
the interfaces between the entities of the system, not on the | the interfaces between the entities of the system, not on the | |||
protocols or their implementations. | protocols or their implementations. | |||
skipping to change at page 6, line 5 | skipping to change at page 7, line 5 | |||
| | | | | | | | | | | | | | | | | | |||
| +----------+ | | +----------+ | | | +----------+ | | +----------+ | | |||
+----------------------+ +----------------------+ | +----------------------+ +----------------------+ | |||
A federation with two members, ALPHA and BETA. ALPHA and BETA each | A federation with two members, ALPHA and BETA. ALPHA and BETA each | |||
have their own NSDB node and several file servers, and they are | have their own NSDB node and several file servers, and they are | |||
administered separately. | administered separately. | |||
Figure 1 | Figure 1 | |||
3. Purpose | 2. Purpose | |||
Our objective is to specify a set of protocols by which fileservers | Our objective is to specify a set of protocols by which fileservers | |||
or collections of fileservers, with different administrators, can | or collections of fileservers, with different administrators, can | |||
form a federation of fileservers and NSDB nodes that provides a | form a federation of fileservers and NSDB nodes that provides a | |||
namespace composed of the filesets hosted on the different | namespace composed of the filesets hosted on the different | |||
fileservers and fileserver collections. | fileservers and fileserver collections. | |||
It should be possible, using a system that implements the protocols, | It should be possible, using a system that implements the protocols, | |||
to share a common namespace across all the fileservers in the | to share a common namespace across all the fileservers in the | |||
federation. It should also be possible for different fileservers in | federation. It should also be possible for different fileservers in | |||
skipping to change at page 7, line 5 | skipping to change at page 8, line 5 | |||
nodes. Acting in concert, the administrators should be able to build | nodes. Acting in concert, the administrators should be able to build | |||
and administer this multi-fileserver, multi-collection namespace. | and administer this multi-fileserver, multi-collection namespace. | |||
It is not the intent of the federation to guarantee namespace | It is not the intent of the federation to guarantee namespace | |||
consistency across all client views. Since different parts of the | consistency across all client views. Since different parts of the | |||
namespace may be administered by different entities, it is possible | namespace may be administered by different entities, it is possible | |||
that a client could be accessing a stale area of the namespace | that a client could be accessing a stale area of the namespace | |||
managed by one entity because a part of the namespace above it, | managed by one entity because a part of the namespace above it, | |||
managed by another entity, has changed. | managed by another entity, has changed. | |||
4. Examples and Discussion | 3. Examples and Discussion | |||
In this section we provide examples and discussion of the basic | In this section we provide examples and discussion of the basic | |||
operations facilitated by the federated file system protocol: | operations facilitated by the federated file system protocol: | |||
creating a fileset, adding a replica of a fileset, resolving a | creating a fileset, adding a replica of a fileset, resolving a | |||
junction, and creating a junction. | junction, and creating a junction. | |||
4.1. Create a Fileset and its FSL(s) | 3.1. Create a Fileset and its FSL(s) | |||
A fileset is the abstraction of a set of files and their containing | A fileset is the abstraction of a set of files and their containing | |||
directory tree. The fileset abstraction is the fundamental unit of | directory tree. The fileset abstraction is the fundamental unit of | |||
data management in the federation. This abstraction is implemented | data management in the federation. This abstraction is implemented | |||
by an actual directory tree whose root location is specified by a | by an actual directory tree whose root location is specified by a | |||
fileset location (FSL). | fileset location (FSL). | |||
In this section, we describe the basic requirements for starting with | In this section, we describe the basic requirements for starting with | |||
a directory tree and creating a fileset that can be used in the | a directory tree and creating a fileset that can be used in the | |||
federation protocols. Note that we do not assume that the process of | federation protocols. Note that we do not assume that the process of | |||
skipping to change at page 7, line 36 | skipping to change at page 8, line 36 | |||
location(s) of the implementation of the fileset as FSL(s). | location(s) of the implementation of the fileset as FSL(s). | |||
There are many possible variations to this procedure, depending on | There are many possible variations to this procedure, depending on | |||
how the FSN that binds the FSL is created, and whether other replicas | how the FSN that binds the FSL is created, and whether other replicas | |||
of the fileset exist, are known to the federation, and need to be | of the fileset exist, are known to the federation, and need to be | |||
bound to the same FSN. | bound to the same FSN. | |||
It is easiest to describe this in terms of how to create the initial | It is easiest to describe this in terms of how to create the initial | |||
implementation of the fileset, and then describe how to add replicas. | implementation of the fileset, and then describe how to add replicas. | |||
4.1.1. Creating a Fileset and an FSN | 3.1.1. Creating a Fileset and an FSN | |||
1. Choose the NSDB node that will keep track of the FSL(s) and | 1. Choose the NSDB node that will keep track of the FSL(s) and | |||
related information for the fileset. | related information for the fileset. | |||
2. Request that the NSDB node register a new FSN for the fileset. | 2. Request that the NSDB node register a new FSN for the fileset. | |||
The FSN may either be chosen by the NSDB node or by the server. | The FSN may either be chosen by the NSDB node or by the server. | |||
The latter case is used if the fileset is being restored, perhaps | The latter case is used if the fileset is being restored, perhaps | |||
as part of disaster recovery, and the server wishes to specify | as part of disaster recovery, and the server wishes to specify | |||
the FSN in order to permit existing junctions that reference that | the FSN in order to permit existing junctions that reference that | |||
skipping to change at page 8, line 10 | skipping to change at page 9, line 10 | |||
At this point, the FSN exists, but its location is unspecified. | At this point, the FSN exists, but its location is unspecified. | |||
3. Send the FSN, the local volume path, the export path, and the | 3. Send the FSN, the local volume path, the export path, and the | |||
export options for the local implementation of the fileset to the | export options for the local implementation of the fileset to the | |||
NSDB node. Annotations about the FSN or the location may also be | NSDB node. Annotations about the FSN or the location may also be | |||
sent. | sent. | |||
The NSDB node records this info and creates the initial FSL for | The NSDB node records this info and creates the initial FSL for | |||
the fileset. | the fileset. | |||
4.1.2. Adding a Replica of a Fileset | 3.1.2. Adding a Replica of a Fileset | |||
Adding a replica is straightforward: the NSDB node and the FSN are | Adding a replica is straightforward: the NSDB node and the FSN are | |||
already known. The only remaining step is to add another FSL. | already known. The only remaining step is to add another FSL. | |||
Note that the federation protocols do not include methods for | Note that the federation protocols do not include methods for | |||
creating or managing replicas: this is assumed to be a platform- | creating or managing replicas: this is assumed to be a platform- | |||
dependent operation (at least at this time). The only requirement is | dependent operation (at least at this time). The only requirement is | |||
that these fileset replicas be registered and unregistered with the | that these fileset replicas be registered and unregistered with the | |||
NSDB. | NSDB. | |||
4.2. Junction Resolution | 3.2. Junction Resolution | |||
A fileset may contain references to other filesets. These references | A fileset may contain references to other filesets. These references | |||
are represented by junctions. If a client requests access to a | are represented by junctions. If a client requests access to a | |||
fileset object that is a junction, the server resolves the junction | fileset object that is a junction, the server resolves the junction | |||
to discover the FSL(s) that implements the referenced fileset. | to discover the FSL(s) that implements the referenced fileset. | |||
There are many possible variations to this procedure, depending on | There are many possible variations to this procedure, depending on | |||
how the junctions are represented and how the information necessary | how the junctions are represented and how the information necessary | |||
to perform resolution is represented by the server. | to perform resolution is represented by the server. | |||
skipping to change at page 10, line 39 | skipping to change at page 11, line 39 | |||
| +---------------+ | | +---------------+ | | | +---------------+ | | +---------------+ | | |||
| | | | | | | | | | | | | | | | | | |||
| | Server X | | | | Server Y | | | | | Server X | | | | Server Y | | | |||
| | | | | | | | | | | | | | | | | | |||
| +---------------+ | | +---------------+ | | | +---------------+ | | +---------------+ | | |||
| | | | | | | | | | |||
+-----------------------+ +-----------------------+ | +-----------------------+ +-----------------------+ | |||
Figure 2 | Figure 2 | |||
4.3. Junction Creation | 3.3. Junction Creation | |||
Given a local path and the FSN of a remote fileset, an administrator | Given a local path and the FSN of a remote fileset, an administrator | |||
can create a junction from the local path to the remote fileset. | can create a junction from the local path to the remote fileset. | |||
There are many possible variations to this procedure, depending on | There are many possible variations to this procedure, depending on | |||
how the junctions are represented and how the information necessary | how the junctions are represented and how the information necessary | |||
to perform resolution is represented by the server. | to perform resolution is represented by the server. | |||
Step 1 is the only step that uses the federation interfaces. The | Step 1 is the only step that uses the federation interfaces. The | |||
remaining step may use platform-specific interfaces. | remaining step may use platform-specific interfaces. | |||
1. The administrator requests the server create a junction to the | 1. The administrator requests the server create a junction to the | |||
FSN of the remote fileset at the given path. | FSN of the remote fileset at the given path. | |||
2. The server inserts the junction to the FSN, at the given path, | 2. The server inserts the junction to the FSN, at the given path, | |||
into the local filesystem. | into the local filesystem. | |||
5. Glossary | 4. Glossary | |||
Administrator: user with the necessary authority to initiate | Administrator: user with the necessary authority to initiate | |||
administrative tasks on one or more servers. | administrative tasks on one or more servers. | |||
Admin entity: A server or agent that administers a collection of | Admin entity: A server or agent that administers a collection of | |||
fileservers and persistently stores the namespace information. | fileservers and persistently stores the namespace information. | |||
Client: Any client that accesses the fileserver data using a | Client: Any client that accesses the fileserver data using a | |||
supported filesystem access protocol. | supported filesystem access protocol. | |||
skipping to change at page 13, line 41 | skipping to change at page 14, line 41 | |||
the access to the object at the new location. | the access to the object at the new location. | |||
Replica: A replica is a redundant implementation of a fileset. Each | Replica: A replica is a redundant implementation of a fileset. Each | |||
replica shares the same FSN, but has a different FSL. | replica shares the same FSN, but has a different FSL. | |||
Replicas may be used to increase availability or performance. | Replicas may be used to increase availability or performance. | |||
Updates to replicas of the same fileset MUST appear to occur in | Updates to replicas of the same fileset MUST appear to occur in | |||
the same order, and therefore each replica is self-consistent at | the same order, and therefore each replica is self-consistent at | |||
any moment. | any moment. | |||
We do not assume that updates to each replica occur simultaneously | We do not assume that updates to each replica occur | |||
If a replica is offline or unreachable, the other replicas may be | simultaneously. If a replica is offline or unreachable, the other | |||
updated. | replicas may be updated. | |||
Server Collection: A set of fileservers administered as a unit. A | Server Collection: A set of fileservers administered as a unit. A | |||
server collection may be administered with vendor-specific | server collection may be administered with vendor-specific | |||
software. | software. | |||
The namespace provided by a server collection could be part of the | The namespace provided by a server collection could be part of the | |||
federated namespace. | federated namespace. | |||
Singleton Server: A server collection containing only one server; a | Singleton Server: A server collection containing only one server; a | |||
stand-alone fileserver. | stand-alone fileserver. | |||
6. Proposed Requirements | 5. Proposed Requirements | |||
The phrase "USING THE FEDERATION INTERFACES" implies that the | The phrase "USING THE FEDERATION INTERFACES" implies that the | |||
subsequent requirement must be satisfied, in its entirety, via the | subsequent requirement must be satisfied, in its entirety, via the | |||
federation interfaces. | federation interfaces. | |||
Note that the requirements are described in terms of correct behavior | Note that the requirements are described in terms of correct behavior | |||
by all entities. We do not address the requirements of the system in | by all entities. We do not address the requirements of the system in | |||
the presence of faults. | the presence of faults. | |||
6.1. Basic Assumptions | 5.1. Basic Assumptions | |||
Several of the requirements are so fundamental that we treat them as | Several of the requirements are so fundamental that we treat them as | |||
basic assumptions; if any of these assumptions are violated, the rest | basic assumptions; if any of these assumptions are violated, the rest | |||
of the requirements must be reviewed in their entirety. | of the requirements must be reviewed in their entirety. | |||
A1: The federation protocols do not require any changes to existing | A1: The federation protocols do not require any changes to existing | |||
client-facing protocols, and MAY be extended to incorporate new | client-facing protocols, and MAY be extended to incorporate new | |||
client-facing protocols. | client-facing protocols. | |||
A2: A client SHOULD NOT require any a priori knowledge of the | A2: A client SHOULD NOT require any a priori knowledge of the | |||
skipping to change at page 18, line 9 | skipping to change at page 19, line 9 | |||
NSDB node. (It is not necessary that the FQDN always resolve to | NSDB node. (It is not necessary that the FQDN always resolve to | |||
the same address; the same service may appear at different | the same address; the same service may appear at different | |||
addresses on different networks.) | addresses on different networks.) | |||
It is the responsibility of each federation member to ensure | It is the responsibility of each federation member to ensure | |||
that the resources it wishes to expose have accessible network | that the resources it wishes to expose have accessible network | |||
locations and that the necessary resolution mechanisms (i.e., | locations and that the necessary resolution mechanisms (i.e., | |||
DNS) are given the necessary data to perform the resolution | DNS) are given the necessary data to perform the resolution | |||
correctly. | correctly. | |||
6.2. Requirements | 5.2. Requirements | |||
R1: Requirements of each FSN: | R1: Requirements of each FSN: | |||
a. Each FSN MUST be unique within the scope of its NSDB (so | a. Each FSN MUST be unique within the scope of its NSDB (so | |||
that the FSN is globally unique). | that the FSN is globally unique). | |||
b. The FSN MUST be sufficiently descriptive to locate an | b. The FSN MUST be sufficiently descriptive to locate an | |||
instance of the fileset it names within the federation at | instance of the fileset it names within the federation at | |||
any time. | any time. | |||
skipping to change at page 25, line 5 | skipping to change at page 26, line 5 | |||
multiple file servers to project a common root with defined | multiple file servers to project a common root with defined | |||
consistency semantics. | consistency semantics. | |||
g. If a root fileset is defined it SHOULD be stored using a | g. If a root fileset is defined it SHOULD be stored using a | |||
compact representation that is compatible with | compact representation that is compatible with | |||
heterogeneous fileserver implementations. The root | heterogeneous fileserver implementations. The root | |||
fileset's internal format SHOULD contain enough information | fileset's internal format SHOULD contain enough information | |||
to generate any attributes, including referrals, required | to generate any attributes, including referrals, required | |||
by the standard filesystem access protocols in R9. | by the standard filesystem access protocols in R9. | |||
7. Non-Requirements | 6. Non-Requirements | |||
N1: It is not necessary for the namespace to be known by any | N1: It is not necessary for the namespace to be known by any | |||
specific fileserver. | specific fileserver. | |||
In the same manner that clients do not need to have a priori | In the same manner that clients do not need to have a priori | |||
knowledge of the structure of the namespace or its mapping onto | knowledge of the structure of the namespace or its mapping onto | |||
federation members, the projected namespace can exist without | federation members, the projected namespace can exist without | |||
individual fileservers knowing the entire organizational | individual fileservers knowing the entire organizational | |||
structure, or, indeed, without knowing exactly where in the | structure, or, indeed, without knowing exactly where in the | |||
projected namespace the filesets they host exist. | projected namespace the filesets they host exist. | |||
Fileservers do need to be able to handle referrals from other | Fileservers do need to be able to handle referrals from other | |||
fileservers, but they do not need to know what path the client | fileservers, but they do not need to know what path the client | |||
was accessing when the referral was generated. | was accessing when the referral was generated. | |||
N2: It is not necessary for updates and accesses to the federation | N2: It is not necessary for updates and accesses to the NSDB data to | |||
data to occur in transaction or transaction-like contexts. | occur in transaction or transaction-like contexts. | |||
One possible requirement that is omitted from our current list | One possible requirement that is omitted from our current list | |||
is that updates and accesses to the data stored in the NSDB (or | is that updates and accesses to the data stored in the NSDB (or | |||
individual NSDB nodes) occur within a transaction context. We | individual NSDB nodes) occur within a transaction context. We | |||
were not able to agree whether the benefits of transactions are | were not able to agree whether the benefits of transactions are | |||
worth the complexity they add (both to the specification and its | worth the complexity they add (both to the specification and its | |||
eventual implementation) but this topic is open for discussion. | eventual implementation) but this topic is open for discussion. | |||
Below is the the draft of a proposed requirement that provides | Below is the the draft of a proposed requirement that provides | |||
transactional semantics: | transactional semantics: | |||
skipping to change at page 26, line 5 | skipping to change at page 27, line 5 | |||
the namespace or related data stored in the system (including | the namespace or related data stored in the system (including | |||
the creation, renaming, or deletion of junctions, and the | the creation, renaming, or deletion of junctions, and the | |||
creation, altering, or deletion of mappings between FSN and | creation, altering, or deletion of mappings between FSN and | |||
filesystem locations), can be performed in a manner that | filesystem locations), can be performed in a manner that | |||
provides predictable semantics for the relationship between | provides predictable semantics for the relationship between | |||
the observed values and the effect of the changes." | the observed values and the effect of the changes." | |||
"It MUST be possible to protect sequences of operations by | "It MUST be possible to protect sequences of operations by | |||
transactions with NSDB-wide or server-wide ACID semantics." | transactions with NSDB-wide or server-wide ACID semantics." | |||
8. Security Considerations | 7. Security Considerations | |||
Assuming the Internet threat model, the federated resolution | Assuming the Internet threat model, the federated resolution | |||
mechanism described in this document MUST be implemented in such a | mechanism described in this document MUST be implemented in such a | |||
way to prevent loss of CONFIDENTIALITY, DATA INTEGRITY and PEER | way to prevent loss of CONFIDENTIALITY, DATA INTEGRITY and PEER | |||
ENTITY AUTHENTICATION, as described in [RFC3552]. | ENTITY AUTHENTICATION, as described in [RFC3552]. | |||
CONFIDENTIALITY may be violated if an unauthorized party is able to | CONFIDENTIALITY may be violated if an unauthorized party is able to | |||
eavesdrop on the communication between authorized servers and NSDB | eavesdrop on the communication between authorized servers and NSDB | |||
nodes and thereby learn the locations or other information about FSNs | nodes and thereby learn the locations or other information about FSNs | |||
that they would not be authorized to discover via direct queries. | that they would not be authorized to discover via direct queries. | |||
skipping to change at page 27, line 5 | skipping to change at page 28, line 5 | |||
Well-established techniques for providing authenticated channels may | Well-established techniques for providing authenticated channels may | |||
be used to defeat these attacks, and the protocol MUST support at | be used to defeat these attacks, and the protocol MUST support at | |||
least one of them. | least one of them. | |||
For example, if LDAP is used to implement the query mechanism | For example, if LDAP is used to implement the query mechanism | |||
[RFC4510], then TLS may be used to provide both authentication and | [RFC4510], then TLS may be used to provide both authentication and | |||
integrity [RFC5246] [RFC4513]. If the query protocol is implemented | integrity [RFC5246] [RFC4513]. If the query protocol is implemented | |||
on top of ONC/RPC, then RPCSEC_GSS may be used to fill the same role | on top of ONC/RPC, then RPCSEC_GSS may be used to fill the same role | |||
[RFC2203] [RFC2743]. | [RFC2203] [RFC2743]. | |||
9. IANA Considerations | 8. IANA Considerations | |||
This document has no actions for IANA. | This document has no actions for IANA. | |||
10. References | 9. References | |||
10.1. Normative References | 9.1. Normative References | |||
[NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 | [NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 | |||
Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work | Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work | |||
in progress), December 2008. | in progress), December 2008. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol | [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol | |||
Specification", RFC 2203, September 1997. | Specification", RFC 2203, September 1997. | |||
skipping to change at page 28, line 45 | skipping to change at page 29, line 45 | |||
(LDAP): Technical Specification Road Map", RFC 4510, | (LDAP): Technical Specification Road Map", RFC 4510, | |||
June 2006. | June 2006. | |||
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol | [RFC4513] Harrison, R., "Lightweight Directory Access Protocol | |||
(LDAP): Authentication Methods and Security Mechanisms", | (LDAP): Authentication Methods and Security Mechanisms", | |||
RFC 4513, June 2006. | RFC 4513, June 2006. | |||
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
(TLS) Protocol Version 1.2", RFC 5246, August 2008. | (TLS) Protocol Version 1.2", RFC 5246, August 2008. | |||
10.2. Informational References | 9.2. Informational References | |||
[RFC1094] Nowicki, B., "NFS: Network File System Protocol | [RFC1094] Nowicki, B., "NFS: Network File System Protocol | |||
specification", RFC 1094, March 1989. | specification", RFC 1094, March 1989. | |||
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS | [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS | |||
Version 3 Protocol Specification", RFC 1813, June 1995. | Version 3 Protocol Specification", RFC 1813, June 1995. | |||
Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
We would like to thank Robert Thurlow of Sun Microsystems for helping | We would like to thank Robert Thurlow of Sun Microsystems for helping | |||
End of changes. 27 change blocks. | ||||
54 lines changed or deleted | 62 lines changed or added | |||
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |