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/