draft-ietf-nfsv4-federated-fs-protocol-12.txt   draft-ietf-nfsv4-federated-fs-protocol-13.txt 
NFSv4 Working Group J. Lentini NFSv4 Working Group J. Lentini
Internet-Draft C. Everhart Internet-Draft NetApp
Intended status: Standards Track NetApp Intended status: Standards Track D. Ellard
Expires: November 25, 2012 D. Ellard Expires: March 29, 2013 Raytheon BBN Technologies
Raytheon BBN Technologies
R. Tewari R. Tewari
M. Naik
IBM Almaden IBM Almaden
May 24, 2012 C. Lever, Ed.
Oracle Corporation
September 25, 2012
NSDB Protocol for Federated Filesystems NSDB Protocol for Federated Filesystems
draft-ietf-nfsv4-federated-fs-protocol-12 draft-ietf-nfsv4-federated-fs-protocol-13
Abstract Abstract
This document describes a filesystem federation protocol that enables This document describes a filesystem federation protocol that enables
file access and namespace traversal across collections of file access and namespace traversal across collections of
independently administered fileservers. The protocol specifies a set independently administered fileservers. The protocol specifies a set
of interfaces by which fileservers with different administrators can of interfaces by which fileservers with different administrators can
form a fileserver federation that provides a namespace composed of form a fileserver federation that provides a namespace composed of
the filesystems physically hosted on and exported by the constituent the filesystems physically hosted on and exported by the constituent
fileservers. fileservers.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 25, 2012. This Internet-Draft will expire on March 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of Features and Concepts . . . . . . . . . . . . . . 6 2. Overview of Features and Concepts . . . . . . . . . . . . . . 6
2.1. File-access Protocol . . . . . . . . . . . . . . . . . . . 6 2.1. File-access Protocol . . . . . . . . . . . . . . . . . . . 6
2.2. File-access Client . . . . . . . . . . . . . . . . . . . . 6 2.2. File-access Client . . . . . . . . . . . . . . . . . . . . 6
2.3. Fileserver . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Fileserver . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Fileset . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.6. Fileset . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7. Fileset Name (FSN) . . . . . . . . . . . . . . . . . . . . 7 2.7. Fileset Name (FSN) . . . . . . . . . . . . . . . . . . . . 7
2.8. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 7 2.8. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 8
2.8.1. Mutual Consistency across Fileset Locations . . . . . 8 2.8.1. The NFS URI scheme . . . . . . . . . . . . . . . . . . 9
2.8.2. Caching of Fileset Locations . . . . . . . . . . . . . 9 2.8.2. Mutual Consistency across Fileset Locations . . . . . 10
2.8.3. Generating A Referral from Fileset Locations . . . . . 9 2.8.3. Caching of Fileset Locations . . . . . . . . . . . . . 11
2.9. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 10 2.8.4. Generating A Referral from Fileset Locations . . . . . 12
2.10. Mount Points, Junctions and Referrals . . . . . . . . . . 11 2.9. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 13
2.11. Unified Namespace and the Root Fileset . . . . . . . . . . 12 2.10. Junctions and Referrals . . . . . . . . . . . . . . . . . 14
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.11. Unified Namespace and the Root Fileset . . . . . . . . . . 14
3.1. Creating a Fileset and its FSL(s) . . . . . . . . . . . . 12 2.12. UUID Considerations . . . . . . . . . . . . . . . . . . . 15
3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 13 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 13 3.1. Creating a Fileset and its FSL(s) . . . . . . . . . . . . 16
3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 13 3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 17
3.3. Example Use Cases for Fileset Annotations . . . . . . . . 14 3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 17
4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 15 3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 17
4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 15 3.3. Example Use Cases for Fileset Annotations . . . . . . . . 18
4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 16 4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 19
4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 19 4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 19
4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 23
4.2.2. LDAP Objects . . . . . . . . . . . . . . . . . . . . . 37 4.2.2. LDAP Objects . . . . . . . . . . . . . . . . . . . . . 37
5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 40 5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 40
5.1. NSDB Operations for Administrators . . . . . . . . . . . . 41 5.1. NSDB Operations for Administrators . . . . . . . . . . . . 41
5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 42 5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 41
5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 43 5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 42
5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 43 5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 43
5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 47 5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 46
5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 47 5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 47
5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 48 5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 48
5.2.1. NSDB Container Entry (NCE) Enumeration . . . . . . . . 48 5.2.1. NSDB Container Entry (NCE) Enumeration . . . . . . . . 48
5.2.2. Lookup FSLs for an FSN . . . . . . . . . . . . . . . . 48 5.2.2. Lookup FSLs for an FSN . . . . . . . . . . . . . . . . 48
5.3. NSDB Operations and LDAP Referrals . . . . . . . . . . . . 50 5.3. NSDB Operations and LDAP Referrals . . . . . . . . . . . . 49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 50 6. Security Considerations . . . . . . . . . . . . . . . . . . . 50
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
7.1. Registry for the fedfsAnnotation Key Namespace . . . . . . 51 7.1. Registry for the fedfsAnnotation Key Namespace . . . . . . 51
7.2. Registry for FedFS Object Identifiers . . . . . . . . . . 51 7.2. Registry for FedFS Object Identifiers . . . . . . . . . . 51
7.3. LDAP Descriptor Registration . . . . . . . . . . . . . . . 54 7.3. LDAP Descriptor Registration . . . . . . . . . . . . . . . 53
8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.1. Normative References . . . . . . . . . . . . . . . . . . . 59 9.1. Normative References . . . . . . . . . . . . . . . . . . . 59
9.2. Informative References . . . . . . . . . . . . . . . . . . 61 9.2. Informative References . . . . . . . . . . . . . . . . . . 60
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 62 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
1. Introduction 1. Introduction
A federated filesystem enables file access and namespace traversal in A federated filesystem enables file access and namespace traversal in
a uniform, secure and consistent manner across multiple independent a uniform, secure and consistent manner across multiple independent
fileservers within an enterprise or across multiple enterprises. fileservers within an enterprise or across multiple enterprises.
This document specifies a set of protocols that allow fileservers, This document specifies a set of protocols that allow fileservers,
possibly from different vendors and with different administrators, to possibly from different vendors and with different administrators, to
skipping to change at page 5, line 41 skipping to change at page 5, line 41
administrator may be able to use the proprietary tools to build a administrator may be able to use the proprietary tools to build a
shared namespace out of the exported filesystems. However, relying shared namespace out of the exported filesystems. However, relying
on vendor-specific proprietary tools does not work in larger on vendor-specific proprietary tools does not work in larger
enterprises or when collaborating across enterprises because the enterprises or when collaborating across enterprises because the
fileservers are likely to be from multiple vendors or use different fileservers are likely to be from multiple vendors or use different
software versions, each with their own namespace protocols, with no software versions, each with their own namespace protocols, with no
common mechanism to manage the namespace or exchange namespace common mechanism to manage the namespace or exchange namespace
information. information.
The federated filesystem protocols in this document define how to The federated filesystem protocols in this document define how to
construct a namespace accessible by an NFSv4 [3530bis] or NFSv4.1 construct a namespace accessible by an NFSv4.0 [3530bis], NFSv4.1
[RFC5661] client and have been designed to accommodate other file [RFC5661] or newer client and have been designed to accommodate other
access protocols in the future. file access protocols in the future.
The requirements for federated filesystems are described in The requirements for federated filesystems are described in
[RFC5716]. A protocol for administering a fileserver's namespace is [RFC5716]. A protocol for administering a fileserver's namespace is
described in [FEDFS-ADMIN]. The mechanism for discovering the root described in [FEDFS-ADMIN]. The mechanism for discovering the root
of an NFSv4 namespace is described in [FEDFS-DNS-SRV]. of a federated namespace is described in [RFC6641].
In the rest of the document, the term fileserver denotes a fileserver In the rest of the document, the term fileserver denotes a fileserver
that is part of a federation. that is part of a federation.
2. Overview of Features and Concepts 2. Overview of Features and Concepts
2.1. File-access Protocol 2.1. File-access Protocol
A file-access protocol is a network protocol for accessing data. The A file-access protocol is a network protocol for accessing data. The
NFSv4 protocol and the NFSv4.1 protocol are both examples of a file- NFSv4.0 protocol [3530bis] is an example of a file-access protocol.
access protocol.
2.2. File-access Client 2.2. File-access Client
File-access clients are standard off-the-shelf network attached File-access clients are standard off-the-shelf network attached
storage (NAS) clients that communicate with fileservers using the storage (NAS) clients that communicate with fileservers using a
NFSv4 protocol, the NFSv4.1 protocol, or some other file-access standard file-access protocol.
protocol.
2.3. Fileserver 2.3. Fileserver
Fileservers are servers that store the physical fileset data or refer Fileservers are servers that store physical fileset data, or refer
the client to other fileservers. A fileserver can be implemented in file-access clients to other fileservers. A fileserver provides
a number of different ways, including a single system, a cluster of access to its shared filesystem data via a file-access protocol. A
systems, or some other configuration. A fileserver provides access fileserver may be implemented in a number of different ways,
to a federated filesystem via NFSv4, NFSv4.1, or some other file- including a single system, a cluster of systems, or some other
access protocol. configuration.
2.4. Referral 2.4. Referral
A referral is a mechanism by which a fileserver redirects a file- A referral is a mechanism by which a fileserver redirects a file-
access protocol client to a different fileserver. The exact access client to a different fileserver or export. The exact
information contained in a referral varies from one file-access information contained in a referral varies from one file-access
protocol to another. The NFSv4 protocol defines the fs_locations protocol to another. The NFSv4.0 protocol, for example, defines the
attribute for referral information. The NFSv4.1 protocol defines the fs_locations attribute for returning referral information to NFSv4.0
fs_locations_info attribute for referral information. clients. The NFSv4.1 protocol introduces the fs_locations_info
attribute that can return richer referral information to its clients.
NFSv4.1 fileservers may use either attribute during a referral. Both
attributes are defined in [RFC5661].
2.5. Namespace 2.5. Namespace
The goal of a unified namespace is to make all managed data available The goal of a unified namespace is to make all managed data available
to all clients via the same path in a common filesystem-like to any file-access client via the same path in a common filesystem
namespace. This should be achieved with minimal or zero client namespace. This should be achieved with minimal or zero
configuration. In particular, updates to the common namespace should configuration on file-access clients. In particular, updates to the
not require configuration changes at the client. Filesets, which are common namespace should not require configuration changes to any
the unit of data management, are a set of files and directories. file-access client.
From the perspective of the clients, the common namespace is
constructed by mounting filesets that are physically located on Filesets, which are the unit of data management, are a set of files
different fileservers. The namespace, which is defined in terms of and directories. From the perspective of file-access clients, the
fileset definitions, fileset identifiers, the location of each common namespace is constructed by mounting filesets that are
fileset in the namespace, and the physical location of the physically located on different fileservers. The namespace, which is
implementation(s) of each fileset, is stored in a set of namespace defined in terms of fileset names and locations, is stored in a set
repositories, each managed by an administrative entity. The of namespace repositories, each managed by an administrative entity.
namespace schema defines the model used for populating, modifying,
and querying the namespace repositories. It is not required by the The namespace schema defines the model used for populating,
federation that the namespace be common across all fileservers. It modifying, and querying the namespace repositories. It is not
should be possible to have several independently rooted namespaces. required by the federation that the namespace be common across all
fileservers. It should be possible to have several independently
rooted namespaces.
2.6. Fileset 2.6. Fileset
A fileset is defined to be a container of data and is the basic unit A fileset is loosely defined as a set of files and the directory tree
of data management. Depending on the configuration, they may be that contains them. The fileset abstraction is the basic unit of
anything between an individual directory of an exported filesystem to data management. Depending on the configuration, a fileset may be
an entire exported filesystem at a fileserver. anything from an individual directory of an exported filesystem to an
entire exported filesystem on a fileserver.
2.7. Fileset Name (FSN) 2.7. Fileset Name (FSN)
A fileset is uniquely represented by its fileset name (FSN). An FSN A fileset is uniquely represented by its fileset name (FSN). An FSN
is considered unique across the federation. After an FSN is created, is considered unique across a federation. After an FSN is created,
it is associated with one or more fileset locations (FSLs) on a it is associated with one or more fileset locations (FSLs) on one or
fileserver. more fileservers.
The attributes of an FSN are: An FSN consists of:
NsdbName: the network location of the NSDB node that contains NsdbName: the network location of the NSDB node that contains
authoritative information for this FSN. authoritative information for this FSN.
FsnUuid: a 128-bit UUID (universally unique identifier), FsnUuid: a UUID (universally unique identifier), conforming to
conforming to [RFC4122], that is used to uniquely identify an [RFC4122], that is used to uniquely identify an FSN.
FSN.
FsnTTL: the time in seconds during which the FSN's FSL
information may be cached.
The FsnUuid is a required attribute of an FSN record, but the
NsdbName is not stored as an attribute of the record. The NsdbName
is obvious to NSDB clients, and is indeed authenticated in cases
where TLS security is in effect.
An FSN record also contains a cache time-to-live attribute. The
FsnUuid and NsdbName values never change during an FSN's lifetime.
However, an FSN's FSL information can change over time, and is
typically cached on fileservers for performance. More detail is
provided in Section 2.8.3.
An FSN record may also contain:
Annotations: optional name/value pairs that can be interpreted by
a fileserver. The semantics of this field are not defined by
this document. These tuples are intended to be used by higher-
level protocols.
Descriptions: optional text descriptions. The semantics of this
field are not defined by this document.
2.8. Fileset Location (FSL) 2.8. Fileset Location (FSL)
An FSL describes the location where the fileset data resides. An FSL An FSL describes one physical location where a complete copy of the
contains generic and type specific information which together fileset's data resides. An FSL contains generic and type specific
describe how to access the fileset. An FSL's type indicates which information which together describe how to access the fileset data at
protocol(s) may be used to access its data. An FSL's attributes can this location. An FSL's attributes can be used by a fileserver to
be used by a fileserver to decide which locations it will return to a decide which locations it will return to a file-access client.
client.
All FSLs have the following attributes: An FSL consists of:
FslUuid: a 128-bit UUID, conforming to [RFC4122], that is used to FslUuid: a UUID, conforming to [RFC4122], that is used to
uniquely identify an FSL. uniquely identify an FSL.
FsnUuid: the 128-bit UUID of the FSL's FSN. FsnUuid: the UUID of the FSL's FSN.
NsdbName: the network location of the NSDB node that contains NsdbName: the network location of the NSDB node that contains
authoritative information for this FSL. authoritative information for this FSL.
FslHost: the network location of the host fileserver storing the The NsdbName is not stored as an attribute of an FSL record for the
physical data same reason it is not stored in FSN records.
FslTTL: the time in seconds during which the FSL may be cached An FSL record may also contain:
Annotations: optional name/value pairs that can be interpreted by Annotations: optional name/value pairs that can be interpreted by
a fileserver. The semantics of this field are not defined by a fileserver. The semantics of this field are not defined by
this document. These tuples are intended to be used by higher- this document. These tuples are intended to be used by higher-
level protocols. level protocols.
Descriptions: optional text descriptions. The semantics of this Descriptions: optional text descriptions. The semantics of this
field are not defined by this document. field are not defined by this document.
This document defines an FSL subtype for NFS. An NFS FSL contains This document defines an FSL subtype for NFS. An NFS FSL contains
information suitable for use in an NFSv4 fs_locations [3530bis] or information suitable for use in one of the NFSv4 referral attributes
NFSv4.1 fs_locations_info attribute [RFC5661]. (e.g., fs_locations or fs_locations_info).
A fileset MAY be accessible by protocols other than NFS. For each A fileset MAY be accessible by protocols other than NFS. For each
such protocol, a corresponding FSL subtype SHOULD be defined. The such protocol, a corresponding FSL subtype SHOULD be defined. The
contents and format of such FSL subtypes are not defined in this contents and format of such FSL subtypes are not defined in this
document. document.
2.8.1. Mutual Consistency across Fileset Locations 2.8.1. The NFS URI scheme
To capture the location of an NFSv4 fileset, we extend the NFS URL
scheme specified in [RFC2224]. This extention follows rules for
defining Uniform Resource Identifier schemes in [RFC3986]. In the
following text, we refer to this extended NFS URL scheme as an NFS
URI.
An NFS URI MUST contain both an authority and a path component. It
MUST NOT contain a query component or a fragment component. Use of
the familiar "nfs" scheme name is retained.
2.8.1.1. The NFS URI authority component
The rules for encoding the authority component of a generic URI are
specified in section 3.2 of [RFC3986]. The authority component of an
NFS URI MUST contain the host subcomponent. For globally-scoped NFS
URIs, a hostname used in such URIs SHOULD be a fully qualified domain
name. See section 3.2.2 of [RFC3986] for rules on encoding non-ASCII
characters in hostnames.
An NFS URI MAY contain a port subcomponent as described in section
3.2.3 of [RFC3986]. If this subcomponent is missing, a port value of
2049 is assumed.
2.8.1.2. The NFS URI path component
The rules for encoding the path component of a generic URI are
specified in section 3.3 of [RFC3986].
According to sections 5 and 6 of [RFC2224], NFS URLs specify a
pathname relative to an NFS fileserver's "public filehandle."
However, NFSv4 fileservers do not expose a "public filehandle."
Instead, NFSv4 pathnames contained in an NFS URI are evaluated
relative to the pseudoroot of the fileserver identified in the URI's
authority component.
The component4 elements of an NFSv4 pathname are encoded as path
segments in an NFS URI. NFSv4 pathnames MUST be expressed in an NFS
URI as an absolute path. An NFS URI path component MUST NOT be
empty. The NFS URI path component starts with a slash ("/")
character, followed by one or more path segments which each start
with a slash ("/") character [RFC3986].
Therefore, a double slash always follows the authority component of
an NFS URI. For example, the NFSv4 pathname "/" is represented by
two slash ("/") characters following an NFS URI's authority
component.
The component4 elements of an NFS pathname SHOULD be prepared using
the component4 rules defined in Chapter 12 "Internationalization" of
[3530bis] prior to encoding the path component of an NFS URI.
Because a URI is a US-ASCII string, any non-ASCII UTF-8 code point in
a component4 element MUST be represented by URI percent encoding.
URI-reserved characters such as the slash ("/") character contained
in a component4 element MUST be represented by URI percent encoding.
2.8.1.3. Encoding an NFS location in an FSL
The path component of an NFS URI encodes the "rootpath" field of the
NFSv4 fs_location4 data type or the "fli_rootpath" of the NFSv4
fs_locations_item4 data type (see [RFC5661]).
In its "server" field, the NFSv4 fs_location4 data type contains a
list of universal addresses or UTF-8 hostnames. Each may optionally
include a port number. The NFSv4 fs_locations_item4 data type
contains this data in its "fli_entries" field (see [RFC5661]). This
information is encoded in the authority component of an NFS URI.
The "server" and "fli_entries" fields can encode multiple server
hostnames that share the same pathname. An NFS URI, and hence an FSL
record, represents only a single hostname and pathname pair. An NFS
fileserver MUST NOT combine a set of FSL records into a single
fs_location4 or fs_locations_item4 unless each FSL record in the set
contains the same rootpath value and extended filesystem information.
2.8.2. Mutual Consistency across Fileset Locations
All of the FSLs that have the same FSN (and thereby reference the All of the FSLs that have the same FSN (and thereby reference the
same fileset) are equivalent from the point of view of client access; same fileset) are equivalent from the point of view of access by a
the different locations of a fileset represent the same data, though file-access client. Different fileset locations for an FSN represent
potentially at different points in time. Fileset locations are the same data, though potentially at different points in time.
equivalent but not identical. Locations may either be read-only or Fileset locations are equivalent but not identical. Locations may
read-write. Typically, multiple read-write locations are backed by a either be read-only or read-write. Typically, multiple read-write
clustered filesystem while read-only locations are replicas created locations are backed by a clustered filesystem while read-only
by a federation-initiated or external replication operation. Read- locations are replicas created by a federation-initiated or external
only locations may represent consistent point-in-time copies of a replication operation. Read-only locations may represent consistent
read-write location. The federation protocols, however, cannot point-in-time copies of a read-write location. The federation
prevent subsequent changes to a read-only location nor guarantee protocols, however, cannot prevent subsequent changes to a read-only
point-in-time consistency of a read-only location if the read-write location nor guarantee point-in-time consistency of a read-only
location is changing. location if the read-write location is changing.
Regardless of the type, all locations exist at the same mount point Regardless of the type, one file-access client may be referred to a
in the namespace and, thus, one client may be referred to one location described by one FSL while another client chooses to use a
location while another is directed to a different location. Since location described by another FSL. Since updates to each fileset
updates to each fileset location are not controlled by the federation location are not controlled by the federation protocol, it is the
protocol, it is the responsibility of administrators to guarantee the responsibility of administrators to guarantee the functional
functional equivalence of the data. equivalence of the data.
The federation protocol does not guarantee that the different The federation protocols do not guarantee that different fileset
locations are mutually consistent in terms of the currency of the locations are mutually consistent in terms of the currency of their
data. It relies on the client file-access protocol (e.g., NFSv4) to data. However, they provide a means to publish currency information
contain sufficient information to help the clients determine the so that all fileservers in a federation can convey the same
currency of the data at each location in order to ensure that the information to file-access clients during referrals. Clients use
clients do not revert back in time when switching locations. this information to ensure they do not revert to an out-of-date
version of a fileset's data when switching between fileset locations.
NFSv4.1 provides guidance on how replication can be handled in such a
manner. In particular see Section 11.7 of [RFC5661].
2.8.2. Caching of Fileset Locations 2.8.3. Caching of Fileset Locations
To resolve an FSN to a set of FSL records, the fileserver queries the To resolve an FSN to a set of FSL records, a fileserver queries the
appropriate NSDB for the FSL records. A fileserver MAY cache these NSDB node named in the FSN for FSL records associated with this FSN.
FSL records for a limited period of time. The period of time, if
any, during which FSL records MAY be cached is indicated by the FSL's The period of time during which these FSL records MAY be cached is
TTL field. indicated by the parent FSN's TTL attribute. A value of zero
indicates that the results of resolving this FSN SHOULD NOT be
cached. In addition, a fileserver SHOULD check back with the NSDB
node after the FSN TTL has expired to discover if any new FSL records
have been added for this FSN.
The combination of FSL caching and FSL migration presents a The combination of FSL caching and FSL migration presents a
challenge. For example, suppose there are three fileservers named A, challenge. For example, suppose there are three fileservers named A,
B, and C and fileserver A contains a junction to fileset X stored on B, and C. Suppose further that fileserver A contains a junction J to
fileserver B. Now suppose that fileset X is migrated from fileserver fileset X stored on fileserver B.
B to fileserver C and the corresponding FSL information for fileset X
in the appropriate NSDB is updated. If fileserver A has a cached FSL
for fileset X, a user traversing the junction on fileserver A will be
referred to fileserver B even though fileset X has migrated to
fileserver C. If fileserver A had not cached the FSL record, it would
have queried the NSDB and obtained the correct location of fileset X.
Administrators are advised to be aware of FSL caching when performing Now suppose that fileset X is migrated from fileserver B to
a migration. When migrating a fileset, administrators SHOULD create fileserver C, and the corresponding FSL information for fileset X in
a junction at the fileset's old location referring back to the NSDB the authoritative NSDB is updated.
entry for the fileset. This junction will redirect any users who
follow stale FSL information to the correct location. Thus, in the
above example, fileserver A would direct clients to fileserver B, but
fileserver B would in turn direct clients to fileserver C.
Such supplemental junctions (on fileserver B in the example) would If fileserver A has cached FSLs for fileset X, a file-access client
not be required to be in place forever. They need to stay in place traversing junction J on fileserver A will be referred to fileserver
only until cached FSL entries for the target fileset are invalidated. B, even though fileset X has migrated to fileserver C. If fileserver
Each FSL contains a TTL field, a count in seconds of the time A had not cached the FSL records, it would have queried the NSDB and
interval the FSL MAY be cached. This is an upper bound for the obtained the correct location of fileset X.
lifetime of the cached information and a lower bound for the lifetime
of the supplemental junctions. For example, suppose this field
contains the value 3600 seconds (one hour). In such a case,
administrators MUST keep the supplemental junctions in place for at
least one hour after the fileset move has taken place, and FSL data
MUST NOT be cached by a referring fileserver for more than one hour
without a refresh.
2.8.3. Generating A Referral from Fileset Locations Typically, the process of fileset migration leaves a redirection on
the source fileserver in place of a migrated fileset (without such a
redirection, file-access clients would find an empty space where the
migrated fileset was, which defeats the purpose of a managed
migration).
After resolving an FSN to a set of FSL records, the fileserver can This redirection might be a new junction that targets the same FSN as
generate a referral to redirect the client to one or more of the other junctions referring to the migrated fileset, or it might be
FSLs. The fileserver will convert the FSL records to a referral some other kind of directive, depending on the fileserver
format understood by the client, such as an NFSv4 fs_locations implementation, that simply refers file-access clients to the new
attribute or NFSv4.1 fs_locations_info attribute. location of the migrated fileset.
In order to give the client as many options as possible, the Back to our example. Suppose, as part of the migration process, a
junction replaces fileset X on fileserver B. Later, either:
o New file-access clients are referred to fileserver B by stale FSL
information cached on fileserver A, or
o File-access clients continue to access fileserver B because they
cache stale location data for fileset X.
In either case, thanks to the redirection, file-access clients are
informed by fileserver B that fileset X has moved to fileserver C.
Such redirecting junctions (here, on fileserver B) would not be
required to be in place forever. They need to stay in place at least
until FSL entries cached on fileservers and locations cached on file-
access clients for the target fileset are invalidated.
An FSL's parent FSN contains a TTL field which contains a count in
seconds of the time interval the FSL MAY be cached. This is an upper
bound for the lifetime of the cached information, and thus can act as
a lower bound for the lifetime of redirecting junctions.
For example, suppose this field contains the value 3600 seconds (one
hour). In such a case, administrators SHOULD keep the redirection in
place for at least one hour after a fileset migration has taken
place, and FSL data MUST NOT be cached by a referring fileserver for
more than one hour without a refresh.
To get file-access clients to access the destination fileserver more
quickly, administrators SHOULD set the FSN TTL field of the migrated
fileset to a low number or zero before migration begins. It can be
reset to a more reasonable number at a later point.
Note that some file-access protocols do not communicate location
cache expiry information to file-access clients. In some cases it
may be difficult to determine an appropriate lifetime for redirecting
junctions because file-access clients may cache location information
indefinitely.
2.8.4. Generating A Referral from Fileset Locations
After resolving an FSN to a set of FSL records, the fileserver
generates a referral to redirect a file-access client to one or more
of the FSN's FSLs. The fileserver converts the FSL records to a
referral format understood by a particular file-access client, such
as an NFSv4 fs_locations or fs_locations_info attribute.
To give file-access clients as many options as possible, the
fileserver SHOULD include the maximum possible number of FSL records fileserver SHOULD include the maximum possible number of FSL records
in a referral. However, the fileserver MAY omit some of the FSL in a referral. However, the fileserver MAY omit some of the FSL
records from the referral. For example, the fileserver might omit an records from the referral. For example, the fileserver might omit an
FSL record with a different file access protocol from the one in use
between the fileserver and client, or the fileserver might omit an
FSL record because of limitations in the file access protocol's FSL record because of limitations in the file access protocol's
referral format, or the fileserver might omit an FSL record based on referral format.
some other criteria.
For a given FSL record, the fileserver MAY convert or reduce the FSL For a given FSL record, the fileserver MAY convert or reduce the FSL
record's contents in a manner appropriate to the referral format. record's contents in a manner appropriate to the referral format.
For example, an NFS FSL record contains all the data necessary to For example, an NFS FSL record contains all the data necessary to
construct an NFSv4.1 fs_locations_info attribute, but an NFSv4.1 construct an fs_locations_info attribute, but an fs_locations_info
fs_locations_info attribute contains several pieces of information attribute contains several pieces of information that are not found
that are not found in an NFSv4 fs_locations attribute. A fileserver in the simpler fs_locations attribute. A fileserver constructs
will construct entries in an NFSv4 fs_locations attribute using the entries in an fs_locations attribute using the relevant contents of
relevant contents of an NFS FSL record. Whenever the fileserver an NFS FSL record.
converts or reduces FSL data, the fileserver SHOULD attempt to
maintain the original meaning where possible. For example, an NFS Whenever the fileserver converts or reduces FSL data, the fileserver
FSL record contains the rank and order information that is included SHOULD attempt to maintain the original meaning where possible. For
in an NFSv4.1 fs_locations_info attribute (see NFSv4.1's example, an NFS FSL record contains the rank and order information
that is included in an fs_locations_info attribute (see NFSv4.1's
FSLI4BX_READRANK, FSLI4BX_READORDER, FSLI4BX_WRITERANK, and FSLI4BX_READRANK, FSLI4BX_READORDER, FSLI4BX_WRITERANK, and
FSLI4BX_WRITEORDER). While this rank and order information is not FSLI4BX_WRITEORDER). While this rank and order information is not
explicitly expressible in an NFSv4 fs_locations attribute, the explicitly expressible in an fs_locations attribute, the fileserver
fileserver can arrange the NFSv4 fs_locations attribute's locations can arrange the fs_locations attribute's locations list based on the
list base on the rank and order values. rank and order values.
Another example: A single NFS FSL record contains the hostname of one
fileserver. A single fs_locations attribute can contain a list of
fileserver names. An NFS fileserver MAY combine two or more FSL
records into a single entry in an fs_locations or fs_locations_info
array only if each FSL record contains the same pathname and extended
filesystem information.
Refer to the NFSv4.1 protocol specification [RFC5661], sections 11.9
and 11.10, for further details.
2.9. Namespace Database (NSDB) 2.9. Namespace Database (NSDB)
The NSDB service is a federation-wide service that provides The NSDB service is a federation-wide service that provides
interfaces to define, update, and query FSN information, FSL interfaces to define, update, and query FSN information, FSL
information, and FSN to FSL mapping information. An individual information, and FSN to FSL mapping information.
repository of namespace information is called an NSDB node. Each
NSDB node is managed by a single administrative entity. A single
admin entity can manage multiple NSDB nodes.
The difference between the NSDB service and an NSDB node is analogous An individual repository of namespace information is called an NSDB
to that between the DNS service and a particular DNS server. node. The difference between the NSDB service and an NSDB node is
analogous to that between the DNS service and a particular DNS
server.
Each NSDB node is managed by a single administrative entity. A
single admininistrative entity can manage multiple NSDB nodes.
Each NSDB node stores the definition of the FSNs for which it is Each NSDB node stores the definition of the FSNs for which it is
authoritative. It also stores the definitions of the FSLs associated authoritative. It also stores the definitions of the FSLs associated
with those FSNs. An NSDB node is authoritative for the filesets that with those FSNs. An NSDB node is authoritative for the filesets that
it defines. An NSDB node can cache information from a peer NSDB it defines.
node. The fileserver can always contact a local NSDB node (if it has
been defined) or directly contact any NSDB node to resolve a Each NSDB node supports an LDAP [RFC4510] interface. The information
junction. Each NSDB node supports an LDAP [RFC4510] interface and stored on an NSDB node is accessed and updated by LDAP clients.
can be accessed by an LDAP client.
An NSDB MAY be replicated throughout the federation. If an NSDB is An NSDB MAY be replicated throughout the federation. If an NSDB is
replicated, the NSDB MUST exhibit loose, converging consistency as replicated, the NSDB MUST exhibit loose, converging consistency as
defined in [RFC3254]. The mechanism by which this is achieved is defined in [RFC3254]. The mechanism by which this is achieved is
outside the scope of this document. Many LDAP implementations outside the scope of this document. Many LDAP implementations
support replication. These features MAY be used to replicate the support replication. These features MAY be used to replicate the
NSDB. NSDB.
2.10. Mount Points, Junctions and Referrals 2.10. Junctions and Referrals
A mount point is a directory in a parent fileset where a target
fileset may be attached. If a client traverses the path leading from
the root of the namespace to the mount point of a target fileset it
should be able to access the data in that target fileset (assuming
appropriate permissions).
The directory where a fileset is mounted is represented by a junction A junction is a point in a particular fileset namespace where a
in the underlying filesystem. In other words, a junction can be specific target fileset may be attached. If a file-access client
viewed as a reference from a directory in one fileset to the root of traverses the path leading from the root of a federated namespace to
the target fileset. A junction can be implemented as a special the junction referring to a target fileset, it should be able to
marker on a directory that is interpreted by the fileserver as a mount and access the data in that target fileset (assuming
mount point, or by some other mechanism in the underlying filesystem. appropriate permissions). In other words, a junction can be viewed
as a reference from a directory in one fileset to the root of the
target fileset.
What data is used by the underlying filesystem to represent the A junction can be implemented as a special marker on a directory, or
junction is not defined by this protocol. The essential property is by some other mechanism in the fileserver's underlying filesystem.
that the server must be able to find, given the junction, the FSN for What data is used by the fileserver to represent junctions is not
the target fileset. The mechanism by which the server maps a defined by this document. The essential property is that given a
junction to an FSN is outside the scope of this document. The FSN junction, a fileserver must be able to find the FSN for the target
(as described earlier) contains the authoritative NSDB node, the fileset.
optional NSDB search base if one is defined, and the FsnUuid (a UUID
for the fileset).
When a client traversal reaches a junction, the client is referred to When a file-access client reaches a junction, the fileserver refers
a list of FSLs associated with the FSN targeted by the junction. The the client to a list of FSLs associated with the FSN targeted by the
client can then redirect its connection to one of the FSLs. This act junction. The client can then mount one of the associated FSLs.
is called a referral. For NFSv4 and NFSv4.1 clients, the FSL
information is returned in the fs_locations and fs_locations_info
attributes respectively.
The federation protocols do not limit where and how many times a The federation protocols do not limit where and how many times a
fileset is mounted in the namespace. Filesets can be nested; a fileset is mounted in the namespace. Filesets can be nested; a
fileset can be mounted under another fileset. fileset can be mounted under another fileset.
2.11. Unified Namespace and the Root Fileset 2.11. Unified Namespace and the Root Fileset
The root fileset, when defined, is the top-level fileset of the The root fileset, when defined, is the top-level fileset of the
federation-wide namespace. The root of the unified namespace is the federation-wide namespace. The root of the unified namespace is the
top level directory of this fileset. A set of designated fileservers top level directory of this fileset. A set of designated fileservers
in the federation can export the root fileset to render the in the federation can export the root fileset to render the
federation-wide unified namespace. When a client mounts the root federation-wide unified namespace. When a file-access client mounts
fileset from any of these designated fileservers it can view a common the root fileset from any of these designated fileservers it can view
federation-wide namespace. The root fileset could be implemented a common federation-wide namespace.
either as an exported NFS file system or as data in the NSDB itself.
The properties and schema definition of an NSDB-based root fileset The root fileset could be implemented either as an exported NFS file
and the protocol details that describe how to configure and replicate system or as data in the NSDB itself. The properties and schema
the root fileset are not defined in this document. definition of an NSDB-based root fileset and the protocol details
that describe how to configure and replicate the root fileset are not
defined in this document.
2.12. UUID Considerations
To ensure FSN and FSL records are unique across a domain, FedFS
employs UUIDs conforming to [RFC4122] to form the distinguished names
of LDAP records containing FedFS data (see Section 4.2.2.2).
Because junctions store a tuple containing an FSN UUID and the name
and port of an NSDB node, an FSN UUID must be unique only on a single
NSDB node. An FSN UUID collision can be detected immediately when an
administrator attempts to publish an FSN or FSL by storing it under a
specific NCE on an authoritative NSDB host.
Note that one NSDB node may store multiple NCEs, each under a
different namingContext. If an NSDB node must contain more than one
NCE, the federation's admin entity SHOULD provide a robust method for
preventing FSN UUID collisions between FSNs that reside on the same
NSDB node but under different NCEs.
Because FSLs are children of FSNs, FSL UUIDs must be unique for just
a single FSN. As with FSNs, as soon as an FSL is published, its
uniqueness is guaranteed.
Of course, there is no way to guard against UUID re-use, but that is
highly unlikely provided that UUIDs are constructed carefully.
A fileserver performs the operations described in Section 5.2 as an
unauthenticated user. Thus distinguished names of FSN and FSL
records, as well as the FSN and FSL records themselves, are required
to be readable by anyone who can bind anonymously to an NSDB node.
Therefore FSN and FSL UUIDs should be considered public information.
Version 1 UUIDs contain a host's MAC address and a time stamp in the
clear. This gives provenance to each UUID, but attackers can use
such details to guess information about the host where the UUID was
generated. Security-sensitive installations should be aware that on
externally-facing NSDBs, UUIDs can reveal information about the hosts
where they are generated.
In addition, version 1 UUIDs depend on the notion that a hardware MAC
address is unique across machines. As virtual machines do not depend
on unique physical MAC addresses and in any event an administrator
can modify the physical MAC address, version 1 UUIDs are no longer
considered sufficient.
To minimize the probability of UUIDs colliding, a consistent
procedure for generating UUIDs should be used throughout a
federation. Within a federation, UUIDs SHOULD be generated using the
procedure described for version 4 of the UUID variant specified in
[RFC4122].
3. Examples 3. Examples
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 filesystem protocol: creating operations facilitated by the federated filesystem protocol: creating
a fileset, adding a replica of a fileset, resolving a junction, and a fileset, adding a replica of a fileset, resolving a junction, and
creating a junction. creating a junction.
3.1. Creating a Fileset and its FSL(s) 3.1. Creating a Fileset and its FSL(s)
skipping to change at page 13, line 22 skipping to change at page 17, line 22
The FSN UUID is chosen by the administrator or generated The FSN UUID is chosen by the administrator or generated
automatically by administration software. The former case is automatically by administration software. The former case is
used if the fileset is being restored, perhaps as part of used if the fileset is being restored, perhaps as part of
disaster recovery, and the administrator wishes to specify the disaster recovery, and the administrator wishes to specify the
FSN UUID in order to permit existing junctions that reference FSN UUID in order to permit existing junctions that reference
that FSN to work again. that FSN to work again.
At this point, the FSN exists, but its fileset locations are At this point, the FSN exists, but its fileset locations are
unspecified. unspecified.
3. For the FSN created above, create an FSL with the appropriate 3. For the FSN created above, create an FSL in the NSDB node that
information in the NSDB node. describes the physical location of the fileset data.
3.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 only provide the mechanisms to Note that the federation protocols provide only the mechanisms to
register and unregister replicas of a fileset. Fileserver-to- register and unregister replicas of a fileset. Fileserver-to-
fileserver replication protocols are not defined. fileserver replication protocols are not defined.
3.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 file-access client requests
fileset object that is a junction, the fileserver resolves the access to a fileset object that is a junction, the fileserver
junction to discover one or more FSLs that implement the referenced resolves the junction to discover one or more FSLs that implement the
fileset. 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 by the fileserver and how the how the junctions are represented by the fileserver and how the
fileserver performs junction resolution. fileserver performs junction resolution.
Step 4 is the only step that interacts directly with the federation Step 4 is the only step that interacts directly with the federation
protocols. The rest of the steps may use platform-specific protocols. The rest of the steps may use platform-specific
interfaces. interfaces.
1. The fileserver determines that the object being accessed is a 1. The fileserver determines that the object being accessed is a
skipping to change at page 14, line 16 skipping to change at page 18, line 16
fileset. fileset.
3. Using the FSN, the fileserver finds the NSDB node responsible for 3. Using the FSN, the fileserver finds the NSDB node responsible for
the target FSN. the target FSN.
4. The fileserver contacts that NSDB node and asks for the set of 4. The fileserver contacts that NSDB node and asks for the set of
FSLs that implement the target FSN. The NSDB node responds with FSLs that implement the target FSN. The NSDB node responds with
a (possibly empty) set of FSLs. a (possibly empty) set of FSLs.
5. The fileserver converts one or more of the FSLs to the location 5. The fileserver converts one or more of the FSLs to the location
type used by the client (e.g., a Network File System (NFSv4) type used by the file-access client (e.g., an NFSv4 fs_location
fs_location, as described in [3530bis]). attribute as described in [RFC5661]).
6. The fileserver redirects (in whatever manner is appropriate for 6. The fileserver redirects (in whatever manner is appropriate for
the client) the client to the location(s). the client) the client to the location(s).
3.3. Example Use Cases for Fileset Annotations 3.3. Example Use Cases for Fileset Annotations
Fileset annotations MAY be used to convey additional attributes of a Fileset annotations MAY be used to convey additional attributes of a
fileset fileset
For example, fileset annotations can be used to define relationships For example, fileset annotations can be used to define relationships
between filesets that can be used by an auxiliary replication between filesets that can be used by an auxiliary replication
protocol. Consider the scenario where a fileset is created and protocol. Consider the scenario where a fileset is created and
mounted at some point in the namespace. A snapshot of the read-write mounted at some point in the namespace. A snapshot of the read-write
FSL of that fileset is taken periodically at different frequencies FSL of that fileset is taken periodically at different frequencies
say a daily snapshot or a weekly snapshot. The different snapshots (say, a daily or weekly snapshot). The different snapshots are
are mounted at different locations in the namespace. The daily mounted at different locations in the namespace.
snapshots are considered as a different fileset from the weekly ones
but both are related to the source fileset. For this we can define The daily snapshots are considered as different filesets from the
an annotation labeling the filesets as source and replica. The weekly ones, but both are related to the source fileset. We can
replication protocol can use this information to copy data from one define an annotation labeling the filesets as source and replica.
or more FSLs of the source fileset to all the FSLs of the replica The replication protocol can use this information to copy data from
one or more FSLs of the source fileset to all the FSLs of the replica
fileset. The replica filesets are read-only while the source fileset fileset. The replica filesets are read-only while the source fileset
is read-write. is read-write.
This follows the traditional Andrew File System (AFS) model of This follows the traditional Andrew File System (AFS) model of
mounting the read-only volume at a path in the namespace different mounting the read-only volume at a path in the namespace different
from that of the read-write volume [AFS]. from that of the read-write volume [AFS].
The federation protocol does not control or manage the relationship The federation protocol does not control or manage the relationship
among filesets. It merely enables annotating the filesets with user- among filesets. It merely enables annotating the filesets with user-
defined relationships. defined relationships.
Another potential use for annotations is recording references to an Another potential use for annotations is recording references to an
FSN. A single annotation containing the number of references could FSN. A single annotation containing the number of references could
be defined or multiple annotations, one per reference, could be used be defined; or multiple annotations, one per reference, could be used
to store detailed information on the location of each reference. As to store detailed information on the location of each reference.
with the replication annotation described above, the maintenance of
reference information would not be controlled by the federation As with the replication annotation described above, the maintenance
protocol. The information would mostly likely be non-authoritative of reference information would not be controlled by the federation
because the the ability to create a junction does not require the protocol. The information would most likely be non-authoritative
because the ability to create a junction does not require the
authority to update the FSN record. In any event, such annotations authority to update the FSN record. In any event, such annotations
could be useful to administrators for determining if an FSN is could be useful to administrators for determining if an FSN is
referenced by a junction. referenced by a junction.
4. NSDB Configuration and Schema 4. NSDB Configuration and Schema
This section describes how an NSDB is constructed using an LDAP This section describes how an NSDB is constructed using an LDAP
Version 3 [RFC4510] Directory. Section 4.1 describes the basic Version 3 [RFC4510] Directory. Section 4.1 describes the basic
properties of the LDAP configuration that MUST be used in order to properties of the LDAP configuration that MUST be used in order to
ensure compatibility between different implementations. Section 4.2 ensure compatibility between different implementations. Section 4.2
skipping to change at page 15, line 30 skipping to change at page 19, line 32
specifies how the distinguished name (DN) of each object instance specifies how the distinguished name (DN) of each object instance
MUST be constructed. MUST be constructed.
4.1. LDAP Configuration 4.1. LDAP Configuration
An NSDB is constructed using an LDAP Directory. This LDAP Directory An NSDB is constructed using an LDAP Directory. This LDAP Directory
MAY have multiple naming contexts. For each naming context, the LDAP MAY have multiple naming contexts. For each naming context, the LDAP
Directory's root DSE will have a namingContext attribute. Each Directory's root DSE will have a namingContext attribute. Each
namingContext attribute contains the DN of the naming context's root namingContext attribute contains the DN of the naming context's root
entry. For each naming context that contains federation entries entry. For each naming context that contains federation entries
(e.g. FSNs and FSLs): (e.g., FSNs and FSLs):
1. There MUST be an LDAP entry that is superior to all of the naming 1. There MUST be an LDAP entry that is superior to all of the naming
context's federation entries in the Directory Information Tree context's federation entries in the Directory Information Tree
(DIT) This entry is termed the NSDB Container Entry (NCE). The (DIT). This entry is termed the NSDB Container Entry (NCE). The
NCE's children are FSNs. An FSNs children are FSLs. NCE's children are FSNs. An FSN's children are FSLs.
2. The naming context's root entry MUST include the 2. The naming context's root entry MUST include the
fedfsNsdbContainerInfo (defined below) as one of its object fedfsNsdbContainerInfo (defined below) as one of its object
classes. The fedfsNsdbContainerInfo's fedfsNcePrefix attribute classes. The fedfsNsdbContainerInfo's fedfsNceDN attribute is
is used to locate the naming context's NCE. used to locate the naming context's NCE.
If a naming context does not contain federation entries, it will not If a naming context does not contain federation entries, it will not
contain an NCE and its root entry will not include a contain an NCE and its root entry will not include a
fedfsNsdbContainerInfo as one of its object classes. fedfsNsdbContainerInfo as one of its object classes.
A fedfsNsdbContainerInfo's fedfsNcePrefix attribute contains a A fedfsNsdbContainerInfo's fedfsNceDN attribute contains the
string. Prepending this string to the namingContext value produces Distinguished Name (DN) of the NSDB Container Entry residing under
the Distinguished Name (DN) of the NSDB Container Entry. An empty this naming context. The fedfsNceDN attribute MUST NOT be empty.
fedfsNcePrefix string value indicates that the NSDB Container Entry
is the namingContext's root entry.
For example, an LDAP directory might have the following entries: For example, an LDAP directory might have the following entries:
-+ [root DSE] -+ [root DSE]
| namingContext: o=fedfs | namingContext: o=fedfs
| namingContext: dc=example,dc=com | namingContext: dc=example,dc=com
| namingContext: ou=system | namingContext: ou=system
| |
| |
+---- [o=fedfs] +---- [o=fedfs]
| fedfsNcePrefix: | fedfsNceDN: o=fedfs
| |
| |
+---- [dc=example,dc=com] +---- [dc=example,dc=com]
| fedfsNcePrefix: ou=fedfs,ou=corp-it | fedfsNceDN: ou=fedfs,ou=corp-it,dc=example,dc=com
| |
| |
+---- [ou=system] +---- [ou=system]
In this case, the o=fedfs namingContext has an NSBD Container Entry In this case, the o=fedfs namingContext has an NSBD Container Entry
at o=fedfs, the dc=example,dc=com namingContext has an NSDB Container at o=fedfs, the dc=example,dc=com namingContext has an NSDB Container
Entry at ou=fedfs,ou=corp-it,dc=example,dc=com, and the ou=system Entry at ou=fedfs,ou=corp-it,dc=example,dc=com, and the ou=system
namingContext has no NSDB Container Entry. namingContext has no NSDB Container Entry.
The NSDB SHOULD be configured with one or more privileged LDAP users. The NSDB SHOULD be configured with one or more privileged LDAP users.
skipping to change at page 18, line 5 skipping to change at page 22, line 5
<CODE ENDS> <CODE ENDS>
The effect of the script is to remove leading white space from each The effect of the script is to remove leading white space from each
line, plus a sentinel sequence of "///". line, plus a sentinel sequence of "///".
As stated above, code components extracted from this document must As stated above, code components extracted from this document must
include the following license: include the following license:
<CODE BEGINS> <CODE BEGINS>
/// # /// #
/// # Copyright (c) 2010 IETF Trust and the persons identified /// # Copyright (c) 2010-2012 IETF Trust and the persons identified
/// # as authors of the code. All rights reserved. /// # as authors of the code. All rights reserved.
/// # /// #
/// # The authors of the code are the authors of /// # The authors of the code are the authors of
/// # [draft-ietf-nfsv4-federated-fs-protocol-xx.txt]: J. Lentini, /// # [draft-ietf-nfsv4-federated-fs-protocol-xx.txt]: J. Lentini,
/// # C. Everhart, D. Ellard, R. Tewari, and M. Naik. /// # C. Everhart, D. Ellard, R. Tewari, and M. Naik.
/// # /// #
/// # Redistribution and use in source and binary forms, with /// # Redistribution and use in source and binary forms, with
/// # or without modification, are permitted provided that the /// # or without modification, are permitted provided that the
/// # following conditions are met: /// # following conditions are met:
/// # /// #
skipping to change at page 19, line 32 skipping to change at page 23, line 32
o The Boolean syntax (1.3.6.1.4.1.1466.115.121.1.7) described in o The Boolean syntax (1.3.6.1.4.1.1466.115.121.1.7) described in
[RFC4517]. [RFC4517].
o The "booleanMatch" rule described in [RFC4517]. o The "booleanMatch" rule described in [RFC4517].
o The "distinguishedNameMatch" rule described in [RFC4517]. o The "distinguishedNameMatch" rule described in [RFC4517].
o The DN syntax (1.3.6.1.4.1.1466.115.121.1.12) described in o The DN syntax (1.3.6.1.4.1.1466.115.121.1.12) described in
[RFC4517]. [RFC4517].
o The "labeledURI" attribute described in [RFC2079].
o The UUID syntax (1.3.6.1.1.16.1) described in [RFC4530].
o The UuidMatch rule described in [RFC4530].
o The UuidOrderingMatch rule described in [RFC4530].
4.2.1.1. fedfsUuid 4.2.1.1. fedfsUuid
A fedfsUuid is the base type for all of the universally unique A fedfsUuid is the base type for all of the universally unique
identifiers (UUIDs) used by the federated filesystem protocols. identifiers (UUIDs) used by the federated filesystem protocols.
To minimize the probability of two UUIDs colliding, a consistent The fedfsUuid type is based on rules and syntax defined in [RFC4530].
procedure for generating UUIDs SHOULD be used throughout a
federation. Within a federation, UUIDs SHOULD be generated using the
procedure described for version 1 of the UUID variant specified in
[RFC4122]. This is the time-based UUID variant provided by many UUID
programming libraries (e.g., the OSF DCE uuid_generate_time(1) API).
The UUID's text representation (as defined in [RFC4122]) SHOULD be
encoded as a UTF-8 string.
A fedfsUuid is a single-valued LDAP attribute. A fedfsUuid is a single-valued LDAP attribute.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.1 NAME 'fedfsUuid' /// 1.3.6.1.4.1.31103.1.1 NAME 'fedfsUuid'
/// DESC 'A UUID used by NSDB' /// DESC 'A UUID used by NSDB'
/// SUP name /// EQUALITY uuidMatch
/// SINGLE-VALUE /// ORDERING uuidOrderingMatch
/// ) /// SYNTAX 1.3.6.1.1.16.1
///
<CODE ENDS>
4.2.1.2. fedfsNetAddr
A fedfsNetAddr is the locative name of a network service in either
IPv4, IPv6, or DNS name notation. It MUST be a UTF-8 string and
SHOULD be prepared using the server4 rules defined in Chapter 12
"Internationalization" of [3530bis].
An IPv4 address MUST be represented using the standard dotted decimal
format defined by the IPv4address rule in Section 3.2.2 of RFC 3986
[RFC3986]. An IPv6 address MUST be represented using the format
defined in Section 2.2 of RFC 4291 [RFC4291].
A DNS name MUST be represented using a fully qualified domain name.
A system (i.e. fileserver or administrative host) SHOULD resolve the
fully qualified domain name to a network address using the system's
standard resolution mechanisms.
This attribute is single-valued.
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.2 NAME 'fedfsNetAddr'
/// DESC 'The network name of a host or service'
/// SUP name
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
4.2.1.3. fedfsNetPort
A fedfsNetPort is the decimal representation of a transport service's
port number. A fedfsNetPort MUST be encoded as an Integer syntax
value [RFC4517].
This attribute is single-valued.
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.3 NAME 'fedfsNetPort'
/// DESC 'A transport port number of a service'
/// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.4. fedfsFsnUuid 4.2.1.2. fedfsFsnUuid
A fedfsFsnUuid represents the UUID component of an FSN. An NSDB A fedfsFsnUuid represents the UUID component of an FSN. An NSDB
SHOULD ensure that no two FSNs it stores have the same fedfsFsnUuid. SHOULD ensure that no two FSNs it stores have the same fedfsFsnUuid.
The fedfsFsnUuid is a subclass of fedfsUuid, with the same encoding
rules.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.4 NAME 'fedfsFsnUuid' /// 1.3.6.1.4.1.31103.1.4 NAME 'fedfsFsnUuid'
/// DESC 'The FSN UUID component of an FSN' /// DESC 'The FSN UUID component of an FSN'
/// SUP fedfsUuid /// SUP fedfsUuid
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.5. fedfsNsdbName 4.2.1.3. fedfsFsnTTL
A fedfsNsdbName is the NSDB component of an FSN.
It MUST be a UTF-8 string containing a DNS name. The DNS name MUST
be represented using a fully qualified domain name. A system (i.e.
fileserver or administrative host) SHOULD resolve the fully qualified
domain name to a network address using the system's standard
resolution mechanisms.
FSNs are immutable and invariant. The attributes of an FSN, A fedfsFsnTTL is the amount of time in seconds an FSN's TTL and its
including the fedfsNsdbName, are expected to remain constant. children FSL records SHOULD be cached by a fileserver. A fedfsFsnTTL
Therefore, a fedfsNsdbName SHOULD NOT contain a network address, such MUST be encoded as an Integer syntax value [RFC4517].
as an IPv4 or IPv6 address, as this would indefinitely assign the
network address.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.5 NAME 'fedfsNsdbName' /// 1.3.6.1.4.1.31103.1.11 NAME 'fedfsFsnTTL'
/// DESC 'The NSDB node component of an FSN' /// DESC 'Time to live of an FSN tree'
/// SUP name /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.6. fedfsNsdbPort OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
A fedfsNsdbPort is the decimal representation of an NSDB's port
number. The fedfsNsdbPort attribute is a subclass of fedfsNetPort,
with the same encoding rules.
This attribute is single-valued.
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.6 NAME 'fedfsNsdbPort'
/// DESC 'The transport port number of an NSDB'
/// SUP fedfsNetPort
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
4.2.1.7. fedfsNcePrefix 4.2.1.4. fedfsNceDN
A fedfsNcePrefix stores a distinguished name (DN) prefix. A fedfsNceDN stores a distinguished name (DN).
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.7 NAME 'fedfsNcePrefix' /// 1.3.6.1.4.1.31103.1.14 NAME 'fedfsNceDN'
/// DESC 'NCE prefix' /// DESC 'NCE Distinguished Name'
/// EQUALITY distinguishedNameMatch /// EQUALITY distinguishedNameMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.12 is the DN syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.12 is the DN syntax [RFC4517].
4.2.1.8. fedfsFslUuid 4.2.1.5. fedfsFslUuid
A fedfsFslUuid represents the UUID of an FSL. An NSDB SHOULD ensure A fedfsFslUuid represents the UUID of an FSL. An NSDB SHOULD ensure
that no two FSLs it stores have the same fedfsFslUuid. that no two FSLs it stores have the same fedfsFslUuid.
The fedfsFslUuid attribute is a subclass of fedfsUuid, with the same
encoding rules.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.8 NAME 'fedfsFslUuid' /// 1.3.6.1.4.1.31103.1.8 NAME 'fedfsFslUuid'
/// DESC 'UUID of an FSL' /// DESC 'UUID of an FSL'
/// SUP fedfsUuid /// SUP fedfsUuid
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
skipping to change at page 23, line 44 skipping to change at page 26, line 15
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.8 NAME 'fedfsFslUuid' /// 1.3.6.1.4.1.31103.1.8 NAME 'fedfsFslUuid'
/// DESC 'UUID of an FSL' /// DESC 'UUID of an FSL'
/// SUP fedfsUuid /// SUP fedfsUuid
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.9. fedfsFslHost 4.2.1.6. fedfsAnnotation
A fedfsFslHost is the host component of an FSL. The fedfsFslHost
attribute is a subclass of fedfsNetAddr, with the same encoding
rules.
This attribute is single-valued.
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.9 NAME 'fedfsFslHost'
/// DESC 'Service location for a fileserver'
/// SUP fedfsNetAddr
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
4.2.1.10. fedfsFslPort
A fedfsFslPort is the decimal representation of a file service's port
number. The fedfsFslPort attribute is a subclass of fedfsNetPort,
with the same encoding rules.
This attribute is single-valued.
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.10 NAME 'fedfsFslPort'
/// DESC 'The file service transport port number'
/// SUP fedfsNetPort
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
4.2.1.11. fedfsFslTTL
A fedfsFslTTL is the amount of time in seconds an FSL SHOULD be
cached by a fileserver. A fedfsFslTTL MUST be encoded as an Integer
syntax value [RFC4517].
This attribute is single-valued.
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.11 NAME 'fedfsFslTTL'
/// DESC 'Time to live of an FSL'
/// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.12. fedfsAnnotation
A fedfsAnnotation contains an object annotation formatted as a key/ A fedfsAnnotation contains an object annotation formatted as a key/
value pair. value pair.
This attribute is multi-valued; an object type that permits This attribute is multi-valued; an object type that permits
annotations may have any number of annotations per instance. annotations may have any number of annotations per instance.
A fedfsAnnotation attribute is a human-readable sequence of UTF-8 A fedfsAnnotation attribute is a human-readable sequence of UTF-8
characters with no non-terminal NUL characters. The value MUST be characters with no non-terminal NUL characters. The value MUST be
formatted according to the following ABNF [RFC5234] rules: formatted according to the following ABNF [RFC5234] rules:
skipping to change at page 26, line 42 skipping to change at page 27, line 39
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.12 NAME 'fedfsAnnotation' /// 1.3.6.1.4.1.31103.1.12 NAME 'fedfsAnnotation'
/// DESC 'Annotation of an object' /// DESC 'Annotation of an object'
/// SUP name /// SUP name
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.13. fedfsDescr 4.2.1.7. fedfsDescr
A fedfsDescr stores an object description. The description MUST be A fedfsDescr stores an object description. The description MUST be
encoded as a UTF-8 string. encoded as a UTF-8 string.
This attribute is multi-valued which permits any number of This attribute is multi-valued which permits any number of
descriptions per entry. descriptions per entry.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.13 NAME 'fedfsDescr' /// 1.3.6.1.4.1.31103.1.13 NAME 'fedfsDescr'
/// DESC 'Description of an object' /// DESC 'Description of an object'
/// SUP name /// SUP name
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.14. fedfsNfsPath 4.2.1.8. fedfsNfsURI
A fedfsNfsPath is the path attribute of an FSL. The path MUST be the
XDR encoded NFS path as defined by the NFS pathname4 XDR type of the
fs_location's rootpath [3530bis] and the fs_locations_item's
fli_rootpath [RFC5661]. The NFS pathname4 XDR type is a variable
length array of component4 elements. The NFS component4 XDR type is
a variable length array of opaque data. A fedfsNfsPath attribute's
component4 elements SHOULD be prepared using the component4 rules
defined in Chapter 12 "Internationalization" of [3530bis].
This attribute is single-valued.
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.100 NAME 'fedfsNfsPath'
/// DESC 'Server-local path to a fileset'
/// EQUALITY octetStringMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.40 is the Octet String syntax
[RFC4517].
4.2.1.15. fedfsNfsMajorVer
A fedfsNfsMajorVer contains the NFS major version of the associated
NFS FSL. A fedfsNfsMajorVer MUST be encoded as an Integer syntax
value [RFC4517].
For example if the FSL was exported via NFS 4.1, the contents of this
attribute would be the value 4.
This attribute is single-valued.
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.101 NAME 'fedfsNfsMajorVer'
/// DESC 'NFS major version'
/// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.16. fedfsNfsMinorVer
A fedfsNfsMinorVer contain the NFS minor version of the associated A fedfsNfsURI stores the host and pathname components of an FSL. A
NFS FSL. A fedfsNfsMinorVer MUST be encoded as an Integer syntax fedfsNfsURI MUST be encoded as an NFS URI Section 2.8.1.
value [RFC4517].
For example if the FSL was exported via NFS 4.1, the contents of this The fedfsNfsURI is a subtype of the labeledURI type [RFC2079], with
attribute would be the value 1. the same encoding rules.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.102 NAME 'fedfsNfsMinorVer' /// 1.3.6.1.4.1.31103.1.120 NAME 'fedfsNfsURI'
/// DESC 'NFS minor version' /// DESC 'Location of fileset'
/// EQUALITY integerMatch /// SUP labeledURI
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 4.2.1.9. fedfsNfsCurrency
4.2.1.17. fedfsNfsCurrency
A fedfsNfsCurrency stores the NFSv4.1 fs_locations_server's A fedfsNfsCurrency stores the NFSv4.1 fs_locations_server's
fls_currency value [RFC5661]. A fedfsNfsCurrency MUST be encoded as fls_currency value [RFC5661]. A fedfsNfsCurrency MUST be encoded as
an Integer syntax value [RFC4517] in the range [-2147483648, an Integer syntax value [RFC4517] in the range [-2147483648,
2147483647]. 2147483647].
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.103 NAME 'fedfsNfsCurrency' /// 1.3.6.1.4.1.31103.1.103 NAME 'fedfsNfsCurrency'
/// DESC 'up-to-date measure of the data' /// DESC 'up-to-date measure of the data'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
skipping to change at page 29, line 30 skipping to change at page 29, line 18
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.18. fedfsNfsGenFlagWritable 4.2.1.10. fedfsNfsGenFlagWritable
A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1 A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1
FSLI4GF_WRITABLE bit [RFC5661]. A value of "TRUE" indicates the bit FSLI4GF_WRITABLE bit [RFC5661]. A value of "TRUE" indicates the bit
is true. A value of "FALSE" indicates the bit is false. is true. A value of "FALSE" indicates the bit is false.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.104 NAME 'fedfsNfsGenFlagWritable' /// 1.3.6.1.4.1.31103.1.104 NAME 'fedfsNfsGenFlagWritable'
skipping to change at page 30, line 5 skipping to change at page 29, line 40
/// EQUALITY booleanMatch /// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
4.2.1.19. fedfsNfsGenFlagGoing 4.2.1.11. fedfsNfsGenFlagGoing
A fedfsNfsGenFlagGoing stores the value of an FSL's NFSv4.1 A fedfsNfsGenFlagGoing stores the value of an FSL's NFSv4.1
FSLI4GF_GOING bit [RFC5661]. A value of "TRUE" indicates the bit is FSLI4GF_GOING bit [RFC5661]. A value of "TRUE" indicates the bit is
true. A value of "FALSE" indicates the bit is false. true. A value of "FALSE" indicates the bit is false.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.105 NAME 'fedfsNfsGenFlagGoing' /// 1.3.6.1.4.1.31103.1.105 NAME 'fedfsNfsGenFlagGoing'
/// DESC 'Indicates if the filesystem is going' /// DESC 'Indicates if the filesystem is going'
/// EQUALITY booleanMatch /// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
skipping to change at page 30, line 27 skipping to change at page 30, line 18
/// EQUALITY booleanMatch /// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
4.2.1.20. fedfsNfsGenFlagSplit 4.2.1.12. fedfsNfsGenFlagSplit
A fedfsNfsGenFlagSplit stores the value of an FSL's NFSv4.1 A fedfsNfsGenFlagSplit stores the value of an FSL's NFSv4.1
FSLI4GF_SPLIT bit [RFC5661]. A value of "TRUE" indicates the bit is FSLI4GF_SPLIT bit [RFC5661]. A value of "TRUE" indicates the bit is
true. A value of "FALSE" indicates the bit is false. true. A value of "FALSE" indicates the bit is false.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.106 NAME 'fedfsNfsGenFlagSplit' /// 1.3.6.1.4.1.31103.1.106 NAME 'fedfsNfsGenFlagSplit'
skipping to change at page 30, line 49 skipping to change at page 30, line 40
/// EQUALITY booleanMatch /// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
4.2.1.21. fedfsNfsTransFlagRdma 4.2.1.13. fedfsNfsTransFlagRdma
A fedfsNfsTransFlagRdma stores the value of an FSL's NFSv4.1 A fedfsNfsTransFlagRdma stores the value of an FSL's NFSv4.1
FSLI4TF_RDMA bit [RFC5661]. A value of "TRUE" indicates the bit is FSLI4TF_RDMA bit [RFC5661]. A value of "TRUE" indicates the bit is
true. A value of "FALSE" indicates the bit is false. true. A value of "FALSE" indicates the bit is false.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.107 NAME 'fedfsNfsTransFlagRdma' /// 1.3.6.1.4.1.31103.1.107 NAME 'fedfsNfsTransFlagRdma'
/// DESC 'Indicates if the transport supports RDMA' /// DESC 'Indicates if the transport supports RDMA'
/// EQUALITY booleanMatch /// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
skipping to change at page 31, line 22 skipping to change at page 31, line 18
/// EQUALITY booleanMatch /// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
4.2.1.22. fedfsNfsClassSimul 4.2.1.14. fedfsNfsClassSimul
A fedfsNfsClassSimul contains the FSL's NFSv4.1 FSLI4BX_CLSIMUL A fedfsNfsClassSimul contains the FSL's NFSv4.1 FSLI4BX_CLSIMUL
[RFC5661] value. A fedfsNfsClassSimul MUST be encoded as an Integer [RFC5661] value. A fedfsNfsClassSimul MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255]. syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.108 NAME 'fedfsNfsClassSimul' /// 1.3.6.1.4.1.31103.1.108 NAME 'fedfsNfsClassSimul'
skipping to change at page 31, line 44 skipping to change at page 31, line 40
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.23. fedfsNfsClassHandle 4.2.1.15. fedfsNfsClassHandle
A fedfsNfsClassHandle contains the FSL's NFSv4.1 FSLI4BX_CLHANDLE A fedfsNfsClassHandle contains the FSL's NFSv4.1 FSLI4BX_CLHANDLE
[RFC5661] value. A fedfsNfsClassHandle MUST be encoded as an Integer [RFC5661] value. A fedfsNfsClassHandle MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255]. syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.109 NAME 'fedfsNfsClassHandle' /// 1.3.6.1.4.1.31103.1.109 NAME 'fedfsNfsClassHandle'
/// DESC 'The handle class of the filesystem' /// DESC 'The handle class of the filesystem'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.24. fedfsNfsClassFileid 4.2.1.16. fedfsNfsClassFileid
A fedfsNfsClassFileid contains the FSL's NFSv4.1 FSLI4BX_CLFILEID A fedfsNfsClassFileid contains the FSL's NFSv4.1 FSLI4BX_CLFILEID
[RFC5661] value. A fedfsNfsClassFileid MUST be encoded as an Integer [RFC5661] value. A fedfsNfsClassFileid MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255]. syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.110 NAME 'fedfsNfsClassFileid' /// 1.3.6.1.4.1.31103.1.110 NAME 'fedfsNfsClassFileid'
skipping to change at page 32, line 40 skipping to change at page 32, line 40
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.25. fedfsNfsClassWritever 4.2.1.17. fedfsNfsClassWritever
A fedfsNfsClassWritever contains the FSL's NFSv4.1 FSLI4BX_CLWRITEVER A fedfsNfsClassWritever contains the FSL's NFSv4.1 FSLI4BX_CLWRITEVER
[RFC5661] value. A fedfsNfsClassWritever MUST be encoded as an [RFC5661] value. A fedfsNfsClassWritever MUST be encoded as an
Integer syntax value [RFC4517] in the range [0, 255]. Integer syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.111 NAME 'fedfsNfsClassWritever' /// 1.3.6.1.4.1.31103.1.111 NAME 'fedfsNfsClassWritever'
/// DESC 'The write-verifier class of the filesystem' /// DESC 'The write-verifier class of the filesystem'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.26. fedfsNfsClassChange 4.2.1.18. fedfsNfsClassChange
A fedfsNfsClassChange contains the FSL's NFSv4.1 FSLI4BX_CLCHANGE A fedfsNfsClassChange contains the FSL's NFSv4.1 FSLI4BX_CLCHANGE
[RFC5661] value. A fedfsNfsClassChange MUST be encoded as an Integer [RFC5661] value. A fedfsNfsClassChange MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255]. syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.112 NAME 'fedfsNfsClassChange' /// 1.3.6.1.4.1.31103.1.112 NAME 'fedfsNfsClassChange'
skipping to change at page 33, line 40 skipping to change at page 33, line 40
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.27. fedfsNfsClassReaddir 4.2.1.19. fedfsNfsClassReaddir
A fedfsNfsClassReaddir contains the FSL's NFSv4.1 FSLI4BX_CLREADDIR A fedfsNfsClassReaddir contains the FSL's NFSv4.1 FSLI4BX_CLREADDIR
[RFC5661] value. A fedfsNfsClassReaddir MUST be encoded as an [RFC5661] value. A fedfsNfsClassReaddir MUST be encoded as an
Integer syntax value [RFC4517] in the range [0, 255]. Integer syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.113 NAME 'fedfsNfsClassReaddir' /// 1.3.6.1.4.1.31103.1.113 NAME 'fedfsNfsClassReaddir'
/// DESC 'The readdir class of the filesystem' /// DESC 'The readdir class of the filesystem'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.28. fedfsNfsReadRank 4.2.1.20. fedfsNfsReadRank
A fedfsNfsReadRank contains the FSL's NFSv4.1 FSLI4BX_READRANK A fedfsNfsReadRank contains the FSL's NFSv4.1 FSLI4BX_READRANK
[RFC5661] value. A fedfsNfsReadRank MUST be encoded as an Integer [RFC5661] value. A fedfsNfsReadRank MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255]. syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.114 NAME 'fedfsNfsReadRank' /// 1.3.6.1.4.1.31103.1.114 NAME 'fedfsNfsReadRank'
skipping to change at page 34, line 40 skipping to change at page 34, line 40
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.29. fedfsNfsReadOrder 4.2.1.21. fedfsNfsReadOrder
A fedfsNfsReadOrder contains the FSL's NFSv4.1 FSLI4BX_READORDER A fedfsNfsReadOrder contains the FSL's NFSv4.1 FSLI4BX_READORDER
[RFC5661] value. A fedfsNfsReadOrder MUST be encoded as an Integer [RFC5661] value. A fedfsNfsReadOrder MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255]. syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.115 NAME 'fedfsNfsReadOrder' /// 1.3.6.1.4.1.31103.1.115 NAME 'fedfsNfsReadOrder'
/// DESC 'The read order of the filesystem' /// DESC 'The read order of the filesystem'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.30. fedfsNfsWriteRank 4.2.1.22. fedfsNfsWriteRank
A fedfsNfsWriteRank contains the FSL's FSLI4BX_WRITERANK [RFC5661] A fedfsNfsWriteRank contains the FSL's FSLI4BX_WRITERANK [RFC5661]
value. A fedfsNfsWriteRank MUST be encoded as an Integer syntax value. A fedfsNfsWriteRank MUST be encoded as an Integer syntax
value [RFC4517] in the range [0, 255]. value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.116 NAME 'fedfsNfsWriteRank' /// 1.3.6.1.4.1.31103.1.116 NAME 'fedfsNfsWriteRank'
skipping to change at page 35, line 40 skipping to change at page 35, line 40
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.31. fedfsNfsWriteOrder 4.2.1.23. fedfsNfsWriteOrder
A fedfsNfsWriteOrder contains the FSL's FSLI4BX_WRITEORDER [RFC5661] A fedfsNfsWriteOrder contains the FSL's FSLI4BX_WRITEORDER [RFC5661]
value. A fedfsNfsWriteOrder MUST be encoded as an Integer syntax value. A fedfsNfsWriteOrder MUST be encoded as an Integer syntax
value [RFC4517] in the range [0, 255]. value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.117 NAME 'fedfsNfsWriteOrder' /// 1.3.6.1.4.1.31103.1.117 NAME 'fedfsNfsWriteOrder'
/// DESC 'The write order of the filesystem' /// DESC 'The write order of the filesystem'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.32. fedfsNfsVarSub 4.2.1.24. fedfsNfsVarSub
A fedfsNfsVarSub stores the value of an FSL's NFSv4.1 FSLI4F_VAR_SUB A fedfsNfsVarSub stores the value of an FSL's NFSv4.1 FSLI4F_VAR_SUB
bit [RFC5661]. A value of "TRUE" indicates the bit is true. A value bit [RFC5661]. A value of "TRUE" indicates the bit is true. A value
of "FALSE" indicates the bit is false. of "FALSE" indicates the bit is false.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.118 NAME 'fedfsNfsVarSub' /// 1.3.6.1.4.1.31103.1.118 NAME 'fedfsNfsVarSub'
skipping to change at page 36, line 40 skipping to change at page 36, line 40
/// EQUALITY booleanMatch /// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
4.2.1.33. fedfsNfsValidFor 4.2.1.25. fedfsNfsValidFor
A fedfsNfsValidFor stores an FSL's NFSv4.1 fs_locations_info A fedfsNfsValidFor stores an FSL's NFSv4.1 fs_locations_info
fli_valid_for value [RFC5661]. A fedfsNfsValidFor MUST be encoded as fli_valid_for value [RFC5661]. A fedfsNfsValidFor MUST be encoded as
an Integer syntax value [RFC4517] in the range [-2147483648, an Integer syntax value [RFC4517] in the range [-2147483648,
2147483647]. 2147483647].
An FSL's fedfsFslTTL value and fedfsNfsValidFor value MAY be An FSL's parent's fedfsFsnTTL value and its fedfsNfsValidFor value
different. MAY be different.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.19 NAME 'fedfsNfsValidFor' /// 1.3.6.1.4.1.31103.1.19 NAME 'fedfsNfsValidFor'
/// DESC 'Valid for time' /// DESC 'Valid for time'
/// EQUALITY integerMatch /// EQUALITY integerMatch
skipping to change at page 37, line 27 skipping to change at page 37, line 27
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
<CODE ENDS> <CODE ENDS>
4.2.2. LDAP Objects 4.2.2. LDAP Objects
4.2.2.1. fedfsNsdbContainerInfo 4.2.2.1. fedfsNsdbContainerInfo
A fedfsNsdbContainerInfo describes the location of the NCE. A fedfsNsdbContainerInfo describes the location of the NCE.
A fedfsFsn's fedfsNcePrefix attribute is REQUIRED. A fedfsFsn's fedfsNceDN attribute is REQUIRED.
A fedfsFsn's fedfsAnnotation and fedfsDescr attributes are OPTIONAL. A fedfsFsn's fedfsAnnotation and fedfsDescr attributes are OPTIONAL.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// objectclass ( /// objectclass (
/// 1.3.6.1.4.1.31103.1.1001 NAME 'fedfsNsdbContainerInfo' /// 1.3.6.1.4.1.31103.1.1001 NAME 'fedfsNsdbContainerInfo'
/// DESC 'Describes NCE location' /// DESC 'Describes NCE location'
/// SUP top AUXILIARY /// SUP top AUXILIARY
/// MUST ( /// MUST (
/// fedfsNcePrefix /// fedfsNceDN
/// ) /// )
/// MAY ( /// MAY (
/// fedfsAnnotation /// fedfsAnnotation
/// $ fedfsDescr /// $ fedfsDescr
/// )) /// ))
/// ///
<CODE ENDS> <CODE ENDS>
4.2.2.2. fedfsFsn 4.2.2.2. fedfsFsn
A fedfsFsn represents an FSN. A fedfsFsn represents an FSN.
A fedfsFsn's fedfsNsdbName and fedfsFsnUuid attributes are REQUIRED. A fedfsFsn's fedfsFsnUuid and fedfsFsnTTL attributes are REQUIRED.
A fedfsFsn's fedfsNsdbPort, fedfsAnnotation, and fedfsDescr
attributes are OPTIONAL.
If the fedfsNsdbPort is omitted, the standard LDAP port number, 389, A fedfsFsn's fedfsAnnotation and fedfsDescr attributes are OPTIONAL.
SHOULD be assumed.
The DN of an FSN is REQUIRED to take the following form: The DN of an FSN is REQUIRED to take the following form:
"fedfsFsnUuid=$FSNUUID,$NCE", where $FSNUUID is the UUID of the FSN "fedfsFsnUuid=$FSNUUID,$NCE", where $FSNUUID is the UUID of the FSN
and $NCE is the DN of the NCE ("o=fedfs" by default). Since LDAP and $NCE is the DN of the NCE. Since LDAP requires a DN to be
requires a DN to be unique, this ensures that each FSN entry has a unique, this ensures that each FSN entry has a unique UUID value
unique UUID value within the LDAP directory. within the LDAP directory.
A fedfsFsn MAY also have additional attributes, but these attributes A fedfsFsn MAY also have additional attributes, but these attributes
MUST NOT be referenced by any part of this document. MUST NOT be referenced by any part of this document.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// objectclass ( /// objectclass (
/// 1.3.6.1.4.1.31103.1.1002 NAME 'fedfsFsn' /// 1.3.6.1.4.1.31103.1.1002 NAME 'fedfsFsn'
/// DESC 'Represents a fileset' /// DESC 'Represents a fileset'
/// SUP top STRUCTURAL /// SUP top STRUCTURAL
/// MUST ( /// MUST (
/// fedfsFsnUuid /// fedfsFsnUuid
/// $ fedfsNsdbName /// $ fedfsFsnTTL
/// ) /// )
/// MAY ( /// MAY (
/// fedfsNsdbPort /// fedfsAnnotation
/// $ fedfsAnnotation
/// $ fedfsDescr /// $ fedfsDescr
/// )) /// ))
/// ///
<CODE ENDS> <CODE ENDS>
4.2.2.3. fedfsFsl 4.2.2.3. fedfsFsl
The fedfsFsl object class represents an FSL. The fedfsFsl object class represents an FSL.
The fedfsFsl is an abstract object class. Protocol specific subtypes The fedfsFsl is an abstract object class. Protocol specific subtypes
of this object class are used to store FSL information. The of this object class are used to store FSL information. The
fedfsNfsFsl object class defined below is used to record an NFS FSL's fedfsNfsFsl object class defined below is used to record an NFS FSL's
location. Other subtypes MAY be defined for other protocols (e.g. location. Other subtypes MAY be defined for other protocols (e.g.,
CIFS). CIFS).
A fedfsFsl's fedfsFslUuid, fedfsFsnUuid, fedfsNsdbName, fedfsFslHost, A fedfsFsl's fedfsFslUuid and fedfsFsnUuid attributes are REQUIRED.
and fedfsFslTTL attributes are REQUIRED.
A fedfsFsl's fedfsNsdbPort, fedfsFslPort, fedfsAnnotation, and
fedfsDescr attributes are OPTIONAL.
If the fedfsNsdbPort is omitted, the standard LDAP port number, 389,
SHOULD be assumed.
If the fedfsFslPort is omitted, a standard port number based on the A fedfsFsl's fedfsAnnotation, and fedfsDescr attributes are OPTIONAL.
type of FSL should be assumed. For an NFS FSL, the standard NFS port
number, 2049, SHOULD be assumed.
The DN of an FSL is REQUIRED to take the following form: The DN of an FSL is REQUIRED to take the following form:
"fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is "fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is
the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the
NCE ("o=fedfs" by default). Since LDAP requires a DN to be unique, NCE. Since LDAP requires a DN to be unique, this ensures that each
this ensures that each FSL entry has a unique UUID value within the FSL entry has a unique UUID value within the LDAP directory.
LDAP directory.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// objectclass ( /// objectclass (
/// 1.3.6.1.4.1.31103.1.1003 NAME 'fedfsFsl' /// 1.3.6.1.4.1.31103.1.1003 NAME 'fedfsFsl'
/// DESC 'A physical location of a fileset' /// DESC 'A physical location of a fileset'
/// SUP top ABSTRACT /// SUP top ABSTRACT
/// MUST ( /// MUST (
/// fedfsFslUuid /// fedfsFslUuid
/// $ fedfsFsnUuid /// $ fedfsFsnUuid
/// $ fedfsNsdbName
/// $ fedfsFslHost
/// $ fedfsFslTTL
/// ) /// )
/// MAY ( /// MAY (
/// fedfsNsdbPort /// fedfsAnnotation
/// $ fedfsFslPort
/// $ fedfsAnnotation
/// $ fedfsDescr /// $ fedfsDescr
/// )) /// ))
/// ///
<CODE ENDS> <CODE ENDS>
4.2.2.4. fedfsNfsFsl 4.2.2.4. fedfsNfsFsl
A fedfsNfsFsl is used to represent an NFS FSL. The fedfsNfsFsl A fedfsNfsFsl is used to represent an NFS FSL. The fedfsNfsFsl
inherits all of the attributes of the fedfsFsl and extends the inherits all of the attributes of the fedfsFsl and extends the
fedfsFsl with information specific to the NFS protocol. fedfsFsl with information specific to the NFS protocol.
The DN of an NFS FSL is REQUIRED to take the following form: The DN of an NFS FSL is REQUIRED to take the following form:
"fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is "fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is
the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the
NCE ("o=fedfs" by default). Since LDAP requires a DN to be unique, NCE. Since LDAP requires a DN to be unique, this ensures that each
this ensures that each NFS FSL entry has a unique UUID value within NFS FSL entry has a unique UUID value within the LDAP directory.
the LDAP directory.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// objectclass ( /// objectclass (
/// 1.3.6.1.4.1.31103.1.1004 NAME 'fedfsNfsFsl' /// 1.3.6.1.4.1.31103.1.1004 NAME 'fedfsNfsFsl'
/// DESC 'An NFS location of a fileset' /// DESC 'An NFS location of a fileset'
/// SUP fedfsFsl STRUCTURAL /// SUP fedfsFsl STRUCTURAL
/// MUST ( /// MUST (
/// fedfsNfsPath /// fedfsNfsURI
/// $ fedfsNfsMajorVer
/// $ fedfsNfsMinorVer
/// $ fedfsNfsCurrency /// $ fedfsNfsCurrency
/// $ fedfsNfsGenFlagWritable /// $ fedfsNfsGenFlagWritable
/// $ fedfsNfsGenFlagGoing /// $ fedfsNfsGenFlagGoing
/// $ fedfsNfsGenFlagSplit /// $ fedfsNfsGenFlagSplit
/// $ fedfsNfsTransFlagRdma /// $ fedfsNfsTransFlagRdma
/// $ fedfsNfsClassSimul /// $ fedfsNfsClassSimul
/// $ fedfsNfsClassHandle /// $ fedfsNfsClassHandle
/// $ fedfsNfsClassFileid /// $ fedfsNfsClassFileid
/// $ fedfsNfsClassWritever /// $ fedfsNfsClassWritever
/// $ fedfsNfsClassChange /// $ fedfsNfsClassChange
skipping to change at page 40, line 48 skipping to change at page 40, line 36
/// $ fedfsNfsVarSub /// $ fedfsNfsVarSub
/// $ fedfsNfsValidFor /// $ fedfsNfsValidFor
/// )) /// ))
/// ///
<CODE ENDS> <CODE ENDS>
5. NSDB Operations 5. NSDB Operations
The operations defined by the protocol can be described as several The operations defined by the protocol can be described as several
sub-protocols that are used by entities within the federation to sub-protocols that are used by entities within a federation to
perform different roles. perform different roles.
The first of these sub-protocols defines how the state of an NSDB The first of these sub-protocols defines how the state of an NSDB
node can be initialized and updated. The primary use of this sub- node can be initialized and updated. The primary use of this sub-
protocol is by an administrator to add, edit, or delete filesets, protocol is by an administrator to add, edit, or delete filesets,
their properties, and their fileset locations. their properties, and their fileset locations.
The second of these sub-protocols defines the queries that are sent The second of these sub-protocols defines the queries that are sent
to an NSDB node in order to perform resolution (or to find other to an NSDB node in order to perform resolution (or to find other
information about the data stored within that NSDB node) and the information about the data stored within that NSDB node) and the
skipping to change at page 41, line 33 skipping to change at page 41, line 22
functionality required to implement an NSDB node. functionality required to implement an NSDB node.
The NSDB sub-protocols are defined in the next two sub-sections. The The NSDB sub-protocols are defined in the next two sub-sections. The
descriptions of LDAP messages in these sections use the LDAP Data descriptions of LDAP messages in these sections use the LDAP Data
Interchange Format (LDIF) [RFC2849]. In order to differentiate Interchange Format (LDIF) [RFC2849]. In order to differentiate
constant and variable strings in the LDIF specifications, variables constant and variable strings in the LDIF specifications, variables
are prefixed by a $ character and use all upper case characters. For are prefixed by a $ character and use all upper case characters. For
example, a variable named FOO would be specified as $FOO. example, a variable named FOO would be specified as $FOO.
This document uses the term NSDB client to refer to an LDAP client This document uses the term NSDB client to refer to an LDAP client
that uses either of the NSDB sub-protocols that uses either of the NSDB sub-protocols.
The third sub-protocol defines the queries and other requests that The third sub-protocol defines the queries and other requests that
are sent to a fileserver in order to get information from it or to are sent to a fileserver in order to get information from it or to
modify the state of the fileserver in a manner related to the modify the state of the fileserver in a manner related to the
federation protocols. The primary purpose of this protocol is for an federation protocols. The primary purpose of this protocol is for an
administrator to create or delete a junction or discover related administrator to create or delete a junction or discover related
information about a particular fileserver. information about a particular fileserver.
The third sub-protocol is defined as an ONC RPC protocols. The The third sub-protocol is defined as an ONC RPC protocol. The reason
reason for using ONC RPC instead of LDAP is that all fileservers for using ONC RPC instead of LDAP is that all fileservers support ONC
support ONC RPC but some do not support an LDAP Directory server. RPC but some do not support an LDAP Directory server.
The ONC RPC administration protocol is defined in [FEDFS-ADMIN]. The ONC RPC administration protocol is defined in [FEDFS-ADMIN].
5.1. NSDB Operations for Administrators 5.1. NSDB Operations for Administrators
The admin entity initiates and controls the commands to manage The admin entity initiates and controls the commands to manage
fileset and namespace information. The admin entity, however, is fileset and namespace information. The protocol used for
stateless. All state is maintained at the NSDB nodes or at the communicating between the admin entity and each NSDB node MUST be the
fileserver. LDAPv3 [RFC4510] protocol.
We require that each NSDB node be able to act as an LDAP server and
that the protocol used for communicating between the admin entity and
each NSDB node is LDAP.
The names we assign to these operations are entirely for the purpose The names we assign to these operations are entirely for the purpose
of exposition in this document, and are not part of the LDAP dialogs. of exposition in this document, and are not part of the LDAP dialogs.
5.1.1. Create an FSN 5.1.1. Create an FSN
This operation creates a new FSN in the NSDB by adding a new fedfsFsn This operation creates a new FSN in the NSDB by adding a new fedfsFsn
entry in the NSDB's LDAP directory. entry in the NSDB's LDAP directory.
A fedfsFsn entry contains a fedfsFsnUuid and fedfsNsdbName. The A fedfsFsn entry contains a fedfsFsnUuid. The administrator chooses
administrator chooses the fedfsFsnUuid and fedfsNsdbName. The the fedfsFsnUuid by a process described in Section 2.12). A fedfsFsn
process for choosing the fedfsFsnUuid is described in entry also contains a fedfsFsnTTL. The fedfsFsnTTL is chosen by the
Section 4.2.1.1). The fedfsNsdbName is the name of the NSDB node administrator as described in Section 2.8.3.
that will serve as the source of definitive information about the FSN
for the life of the FSN.
The NSDB node that receives the request SHOULD check that
fedfsNsdbName value matches its own value and return an error if it
does not. This is to ensure that an FSN is always created by the
NSDB node encoded within the FSN as its owner.
The NSDB node that receives the request SHOULD check all of the The NSDB node that receives the request SHOULD check all of the
attributes for validity and consistency, but this is not generally attributes for validity and consistency, but this is not generally
possible for LDAP servers because the consistency requirements cannot possible for LDAP servers because the consistency requirements cannot
be expressed in the LDAP schema (although many LDAP servers can be be expressed in the LDAP schema (although many LDAP servers can be
extended, via plug-ins or other mechanisms, to add functionality extended, via plug-ins or other mechanisms, to add functionality
beyond the strict definition of LDAP). beyond the strict definition of LDAP).
5.1.1.1. LDAP Request 5.1.1.1. LDAP Request
This operation is implemented using the LDAP ADD request described by This operation is implemented using the LDAP ADD request described by
the LDIF below. the LDIF below.
dn: fedfsFsnUuid=$FSNUUID,$NCE dn: fedfsFsnUuid=$FSNUUID,$NCE
changeType: add changeType: add
objectClass: fedfsFsn objectClass: fedfsFsn
fedfsFsnUuid: $FSNUUID fedfsFsnUuid: $FSNUUID
fedfsNsdbName: $NSDBNAME fedfsFsnTTL: $TTL
For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- For example, if the $FSNUUID is "e8c4761c-eb3b-4307-86fc-
00a0c91e6bf6", the $NSDBNAME is "nsdb.example.com", and the $NCE is f702da197966", the $TTL is "300" seconds, and the $NCE is "o=fedfs"
"o=fedfs" the operation would be: the operation would be:
dn: fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs dn: fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
changeType: add changeType: add
objectClass: fedfsFsn objectClass: fedfsFsn
fedfsFsnUuid: f81d4fae-7dec-11d0-a765-00a0c91e6bf6 fedfsFsnUuid: e8c4761c-eb3b-4307-86fc-f702da197966
fedfsNsdbName: nsdb.example.com fedfsFsnTTL: 300
5.1.2. Delete an FSN 5.1.2. Delete an FSN
This operation deletes an FSN by removing a fedfsFsn entry in the This operation deletes an FSN by removing a fedfsFsn entry in the
NSDB's LDAP directory. NSDB's LDAP directory.
If the FSN entry being deleted has child FSL entries, this function If the FSN entry being deleted has child FSL entries, this function
MUST return an error. This ensures that the NSDB will not contain MUST return an error. This ensures that the NSDB will not contain
any orphaned FSL entries. A compliant LDAP implementation will meet any orphaned FSL entries. A compliant LDAP implementation will meet
this requirement since Section 4.8 of [RFC4511] defines the LDAP this requirement since Section 4.8 of [RFC4511] defines the LDAP
delete operation to only be capable of removing leaf entries. delete operation to only be capable of removing leaf entries.
Note that the FSN delete function only removes the fileset from the Note that the FSN delete function removes the fileset only from a
namespace (by removing the records for that FSN from the NSDB node federation namespace (by removing the records for that FSN from the
that receives this request). The fileset and its data are not NSDB node that receives this request). The fileset and its data are
deleted. Any junction that has this FSN as its target may continue not deleted. Any junction that has this FSN as its target may
to point to this non-existent FSN. A dangling reference may be continue to point to this non-existent FSN. A dangling reference may
detected when a client tries to resolve the target of a junction that be detected when a fileserver tries to resolve a junction that refers
refers to the deleted FSN and the NSDB returns an error. to the deleted FSN.
5.1.2.1. LDAP Request 5.1.2.1. LDAP Request
This operation is implemented using the LDAP DELETE request described This operation is implemented using the LDAP DELETE request described
by the LDIF below. by the LDIF below.
dn: fedfsFsnUuid=$FSNUUID,$NCE dn: fedfsFsnUuid=$FSNUUID,$NCE
changeType: delete changeType: delete
For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- For example, if the $FSNUUID is "e8c4761c-eb3b-4307-86fc-
00a0c91e6bf6" and $NCE is "o=fedfs", the operation would be: f702da197966" and $NCE is "o=fedfs", the operation would be:
dn: fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs dn: fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
changeType: delete changeType: delete
5.1.3. Create an FSL 5.1.3. Create an FSL
This operation creates a new FSL for the given FSN by adding a new This operation creates a new FSL for the given FSN by adding a new
fedfsFsl entry in the NSDB's LDAP directory. fedfsFsl entry in the NSDB's LDAP directory.
A fedfsFsl entry contains a fedfsFslUuid, fedfsFsnUuid, A fedfsFsl entry contains a fedfsFslUuid and fedfsFsnUuid. The
fedfsNsdbName, fedfsFslHost, and fedfsFslTTL. The administrator administrator chooses the fedfsFslUuid. The process for choosing the
chooses the fedfsFslUuid. The process for choosing the fedfsFslUuid fedfsFslUuid is described in Section 2.12. The fedfsFsnUuid is the
is described in Section 4.2.1.1. The fedfsFsnUuid is the UUID of the UUID of the FSL's FSN.
FSL's FSN. The fedfsNsdbName is the name of the NSDB node that
stores definitive information about the FSL's FSN. The fedfsFslHost
value is the network location of the fileserver that stores the FSL.
The fedfsFslTTL is chosen by the administrator as described in
Section 2.8.2.
The administrator will also set additional attributes depending on The administrator will also set additional attributes depending on
the FSL type. the FSL type.
5.1.3.1. LDAP Request 5.1.3.1. LDAP Request
This operation is implemented using the LDAP ADD request described by This operation is implemented using the LDAP ADD request described by
the LDIF below (NOTE: the LDIF shows the creation of an NFS FSL) the LDIF below (NOTE: the LDIF shows the creation of an NFS FSL)
dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE
dn:fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE
changeType: add changeType: add
objectClass: fedfsNfsFsl objectClass: fedfsNfsFsl
fedfsFslUuid: $FSLUUID fedfsFslUuid: $FSLUUID
fedfsFsnUuid: $FSNUUID fedfsFsnUuid: $FSNUUID
fedfsNsdbName: $NSDBNAME fedfsNfsURI: nfs://$HOST:$PORT//$PATH
fedfsFslHost: $HOST
fedfsFslPort: $PORT
fedfsFslTTL: $TTL
fedfsNfsPath: $PATH
fedfsNfsMajorVer: $MAJOR
fedfsNfsMinorVer: $MINOR
fedfsNfsCurrency: $CURRENCY fedfsNfsCurrency: $CURRENCY
fedfsNfsGenFlagWritable: $WRITABLE fedfsNfsGenFlagWritable: $WRITABLE
fedfsNfsGenFlagGoing: $GOING fedfsNfsGenFlagGoing: $GOING
fedfsNfsGenFlagSplit: $SPLIT fedfsNfsGenFlagSplit: $SPLIT
fedfsNfsTransFlagRdma: $RDMA fedfsNfsTransFlagRdma: $RDMA
fedfsNfsClassSimul: $CLASS_SIMUL fedfsNfsClassSimul: $CLASS_SIMUL
fedfsNfsClassHandle:$CLASS_HANDLE fedfsNfsClassHandle:$CLASS_HANDLE
fedfsNfsClassFileid:$CLASS_FILEID fedfsNfsClassFileid:$CLASS_FILEID
fedfsNfsClassWritever:$CLASS_WRITEVER fedfsNfsClassWritever:$CLASS_WRITEVER
fedfsNfsClassChange: $CLASS_CHANGE fedfsNfsClassChange: $CLASS_CHANGE
fedfsNfsClassReaddir: $CLASS_READDIR fedfsNfsClassReaddir: $CLASS_READDIR
fedfsNfsReadRank: $READ_RANK fedfsNfsReadRank: $READ_RANK
fedfsNfsReadOrder: $READ_ORDER fedfsNfsReadOrder: $READ_ORDER
fedfsNfsWriteRank: $WRITE_RANK fedfsNfsWriteRank: $WRITE_RANK
fedfsNfsWriteOrder: $WRITE_ORDER fedfsNfsWriteOrder: $WRITE_ORDER
fedfsNfsVarSub: $VAR_SUB fedfsNfsVarSub: $VAR_SUB
fedfsNfsValidFor: $TIME fedfsNfsValidFor: $TIME
fedfsAnnotation: $ANNOTATION fedfsAnnotation: $ANNOTATION
fedfsDescr: $DESCR fedfsDescr: $DESCR
For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- For example, if the $FSNUUID is "e8c4761c-eb3b-4307-86fc-
00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d- f702da197966", the $FSLUUID is "ba89a802-41a9-44cf-8447-
10eeee060d2c", the $NSDBNAME is "nsdb.example.com", the $HOST is dda367590eb3", the $HOST is "server.example.com", $PORT is "2049",
"server.example.com", $PORT is "2049", the $TTL is "300" seconds, the the $PATH is stored in the file "/tmp/fsl_path", $CURRENCY is "0" (an
$PATH is stored in the file "/tmp/fsl_path", fileset is exported via up to date copy), the FSL is writable, but not going, split, or
NFSv4.1 ($MAJOR is "4" and $MINOR is "1"), $CURRENCY is "0" (an up to accessible via RDMA, the simultaneous-use class is "1", the handle
date copy), the FSL is writable, but not going, split, or accessible class is "0", the fileid class is "1", the write-verifier class is
via RDMA, the simultaneous-use class is "1", the handle class is "0", "1", the change class is "1", the readdir class is "9", the read rank
the fileid class is "1", the write-verifier class is "1", the change is "7", the read order is "8", the write rank is "5", the write order
class is "1", the readdir class is "9", the read rank is "7", the is "6", variable substitution is false, $TIME is "300" seconds,
read order is "8", the write rank is "5", the write order is "6", $ANNOTATION is ""foo" = "bar"", $DESC is "This is a description.",
variable substitution is false, $TIME is "300" seconds, $ANNOTATION and the $NCE is "o=fedfs", the operation would be (for readability
is ""foo" = "bar"", $DESC is "This is a description.", and the $NCE the DN is split into two lines):
is "o=fedfs", the operation would be (for readability the DN is split
into two lines):
dn:fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c, dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3,
fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
changeType: add changeType: add
objectClass: fedfsNfsFsl objectClass: fedfsNfsFsl
fedfsFslUuid: 84f775a7-8e31-14ae-b39d-10eeee060d2c fedfsFslUuid: ba89a802-41a9-44cf-8447-dda367590eb3
fedfsFsnUuid: f81d4fae-7dec-11d0-a765-00a0c91e6bf6 fedfsFsnUuid: e8c4761c-eb3b-4307-86fc-f702da197966
fedfsNsdbName: nsdb.example.com fedfsNfsURI: nfs://server.example.com//tmp/fsl_path
fedfsFslHost: server.example.com
fedfsFslPort: 2049
fedfsFslTTL: 300
fedfsNfsPath:< file:///tmp/fsl_path
fedfsNfsMajorVer: 4
fedfsNfsMinorVer: 1
fedfsNfsCurrency: 0 fedfsNfsCurrency: 0
fedfsNfsGenFlagWritable: TRUE fedfsNfsGenFlagWritable: TRUE
fedfsNfsGenFlagGoing: FALSE fedfsNfsGenFlagGoing: FALSE
fedfsNfsGenFlagSplit: FALSE fedfsNfsGenFlagSplit: FALSE
fedfsNfsTransFlagRdma: FALSE fedfsNfsTransFlagRdma: FALSE
fedfsNfsClassSimul: 1 fedfsNfsClassSimul: 1
fedfsNfsClassHandle: 0 fedfsNfsClassHandle: 0
fedfsNfsClassFileid: 1 fedfsNfsClassFileid: 1
fedfsNfsClassWritever: 1 fedfsNfsClassWritever: 1
fedfsNfsClassChange: 1 fedfsNfsClassChange: 1
skipping to change at page 46, line 8 skipping to change at page 45, line 34
fedfsNfsReadOrder: 8 fedfsNfsReadOrder: 8
fedfsNfsWriteRank: 5 fedfsNfsWriteRank: 5
fedfsNfsWriteOrder: 6 fedfsNfsWriteOrder: 6
fedfsNfsVarSub: FALSE fedfsNfsVarSub: FALSE
fedfsNfsValidFor: 300 fedfsNfsValidFor: 300
fedfsAnnotation: "foo" = "bar" fedfsAnnotation: "foo" = "bar"
fedfsDescr: This is a description. fedfsDescr: This is a description.
5.1.3.2. Selecting fedfsNfsFsl Values 5.1.3.2. Selecting fedfsNfsFsl Values
The fedfsNfsFSl object class is used to describe NFSv4 and NFSv4.1 The fedfsNfsFSl object class is used to describe NFSv4 accessible
accessible filesets. For the reasons described in Section 2.8.3, filesets. For the reasons described in Section 2.8.4, administrators
administrators SHOULD choose reasonable values for all LDAP SHOULD choose reasonable values for all LDAP attributes of an NFSv4
attributes of an NFSv4 accessible fedfsNfsFsl even though some of accessible fedfsNfsFsl even though some of these LDAP attributes are
these LDAP attributes are not explicitly contained in the NFSv4 not explicitly contained in an NFSv4 fs_locations attribute.
fs_locations attribute returned to an NFSv4 client.
When the administrator is unable to choose reasonable values for the When the administrator is unable to choose reasonable values for the
LDAP attributes not explicitly contained in a NFSv4 fs_locations LDAP attributes not explicitly contained in a NFSv4 fs_locations
attribute, the values in the following table are RECOMMENDED. attribute, the values in the following table are RECOMMENDED.
+-------------------------+----------+------------------------------+ +-------------------------+----------+------------------------------+
| LDAP attribute | LDAP | Notes | | LDAP attribute | LDAP | Notes |
| | value | | | | value | |
+-------------------------+----------+------------------------------+ +-------------------------+----------+------------------------------+
| fedfsNfsCurrency | negative | Indicates that the server | | fedfsNfsCurrency | negative | Indicates that the server |
skipping to change at page 46, line 35 skipping to change at page 46, line 21
| | | (see 11.10.1 of [RFC5661]). | | | | (see 11.10.1 of [RFC5661]). |
| fedfsNfsGenFlagWritable | FALSE | Leaving unset is not harmful | | fedfsNfsGenFlagWritable | FALSE | Leaving unset is not harmful |
| | | (see 11.10.1 of [RFC5661]). | | | | (see 11.10.1 of [RFC5661]). |
| fedfsNfsGenFlagGoing | FALSE | NFS client will detect a | | fedfsNfsGenFlagGoing | FALSE | NFS client will detect a |
| | | migration event if the FSL | | | | migration event if the FSL |
| | | becomes unavailable. | | | | becomes unavailable. |
| fedfsNfsGenFlagSplit | TRUE | Safe to assume that the FSL | | fedfsNfsGenFlagSplit | TRUE | Safe to assume that the FSL |
| | | is split. | | | | is split. |
| fedfsNfsTransFlagRdma | TRUE | NFS client will detect if | | fedfsNfsTransFlagRdma | TRUE | NFS client will detect if |
| | | RDMA access is available. | | | | RDMA access is available. |
| fedfsNfsClassSimul | 0 | 0 (zero) is treated as | | fedfsNfsClassSimul | 0 | 0 is treated as non-matching |
| | | non-matching (see 11.10.1 of | | | | (see 11.10.1 of [RFC5661]). |
| | | [RFC5661]). |
| fedfsNfsClassHandle | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassHandle | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsClassFileid | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassFileid | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsClassWritever | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassWritever | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsClassChange | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassChange | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsClassReaddir | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassReaddir | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsReadRank | 0 | Highest value ensures FSL | | fedfsNfsReadRank | 0 | Highest value ensures FSL |
| | | will be tried. | | | | will be tried. |
| fedfsNfsReadOrder | 0 | See fedfsNfsReadRank note. | | fedfsNfsReadOrder | 0 | See fedfsNfsReadRank note. |
| fedfsNfsWriteRank | 0 | See fedfsNfsReadRank note. | | fedfsNfsWriteRank | 0 | See fedfsNfsReadRank note. |
| fedfsNfsWriteOrder | 0 | See fedfsNfsReadRank note. | | fedfsNfsWriteOrder | 0 | See fedfsNfsReadRank note. |
| fedfsNfsVarSub | FALSE | NFSv4 does not define | | fedfsNfsVarSub | FALSE | NFSv4 does not define |
| | | variable substituion in | | | | variable substituion in |
| | | paths. | | | | paths. |
| fedfsNfsValidFor | 0 | Indicates no appropriate | | fedfsNfsValidFor | 0 | Indicates no appropriate |
| | | refetch interval (see | | | | refetch interval (see |
| | | 11.10.2 of [RFC5661]). | | | | 11.10.2 of [RFC5661]). |
+-------------------------+----------+------------------------------+ +-------------------------+----------+------------------------------+
5.1.4. Delete an FSL 5.1.4. Delete an FSL
This operation deletes the given Fileset location. The admin This operation deletes a Fileset location record. The admin requests
requests the NSDB node storing the fedfsFsl to delete it from its the NSDB node storing the fedfsFsl to delete it from its database.
database. This operation does not result in the fileset location's This operation does not result in fileset data being deleted on any
data being deleted at the fileserver. fileserver.
5.1.4.1. LDAP Request 5.1.4.1. LDAP Request
The admin sends an LDAP DELETE request to the NSDB node to remove the The admin sends an LDAP DELETE request to the NSDB node to remove the
FSL. FSL.
dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE
changeType: delete changeType: delete
For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- For example, if the $FSNUUID is "e8c4761c-eb3b-4307-86fc-
00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d- f702da197966", the $FSLUUID is "ba89a802-41a9-44cf-8447-
10eeee060d2c", and the $NCE is "o=fedfs", the operation would be (for dda367590eb3", and the $NCE is "o=fedfs", the operation would be (for
readability the DN is split into two lines): readability the DN is split into two lines):
dn: fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c, dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3,
fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
changeType: delete changeType: delete
5.1.5. Update an FSL 5.1.5. Update an FSL
This operation updates the attributes of a given FSL. This command This operation updates the attributes of a given FSL. This command
results in a change in the attributes of the fedfsFsl at the NSDB results in a change in the attributes of the fedfsFsl at the NSDB
node maintaining this FSL. The attributes that must not change are node maintaining this FSL. The attributes that must not change are
the fedfsFslUuid and the fedfsFsnUuid of the fileset this FSL the fedfsFslUuid and the fedfsFsnUuid of the fileset this FSL
implements. implements.
5.1.5.1. LDAP Request 5.1.5.1. LDAP Request
The admin sends an LDAP MODIFY request to the NSDB node to update the The admin sends an LDAP MODIFY request to the NSDB node to update the
FSL. FSL.
dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE
changeType: modify changeType: modify
replace: $ATTRIBUTE-TYPE replace: $ATTRIBUTE-TYPE
For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- For example, if the $FSNUUID is "e8c4761c-eb3b-4307-86fc-
00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d- f702da197966", the $FSLUUID is "ba89a802-41a9-44cf-8447-
10eeee060d2c", the $NCE is "o=fedfs", and the administrator wished to dda367590eb3", the $NCE is "o=fedfs", and the administrator wished to
change the TTL to 10 minutes, the operation would be (for readability change the NFS read rank to 10, the operation would be (for
the DN is split into two lines): readability the DN is split into two lines):
dn: fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c, dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3,
fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
changeType: modify changeType: modify
replace: fedfsFslTTL replace: fedfsNfsReadClass
fedfsFslTTL: 600 fedfsNfsReadRank: 10
5.2. NSDB Operations for Fileservers 5.2. NSDB Operations for Fileservers
5.2.1. NSDB Container Entry (NCE) Enumeration 5.2.1. NSDB Container Entry (NCE) Enumeration
To find the NCEs for the NSDB foo.example.com, a fileserver would do To find the NCEs for the NSDB nsdb.example.com, a fileserver would do
the following: the following:
nce_list = empty nce_list = empty
connect to the LDAP directory at foo.example.com connect to the LDAP directory at nsdb.example.com
for each namingContext value $BAR in the root DSE for each namingContext value $BAR in the root DSE
/* $BAR is a DN */ /* $BAR is a DN */
query for a fedfsNcePrefix value at $BAR query for a fedfsNceDN value at $BAR
/* /*
* The LDAP URL for this search would be * The RFC 4516 LDAP URL for this search would be
* *
* ldap://foo.example.com:389/$BAR?fedfsNcePrefix?? * ldap://nsdb.example.com:389/$BAR?fedfsNceDN??
* (objectClass=fedfsNsdbContainerInfo) * (objectClass=fedfsNsdbContainerInfo)
* *
*/ */
if a fedfsNcePrefix value is found if a fedfsNceDN value is found
nce = prepend the fedfsNcePrefix value to $BAR add the value to the nce_list
add nce to the nce_list
5.2.2. Lookup FSLs for an FSN 5.2.2. Lookup FSLs for an FSN
Using an LDAP search, the fileserver can obtain all of the FSLs for a Using an LDAP search, the fileserver can obtain all of the FSLs for a
given FSN. The FSN's fedfsFsnUuid is used as the search key. The given FSN. The FSN's fedfsFsnUuid is used as the search key. The
following examples use the LDAP Universal Resource Identifier (URI) following examples use the LDAP Universal Resource Identifier (URI)
format defined in [RFC4516]. format defined in [RFC4516].
To obtain a list of all FSLs for $FSNUUID on the NSDB named To obtain a list of all FSLs for $FSNUUID on the NSDB named
$NSDBNAME, the following search can be used (for readability the URI $NSDBNAME, the following search can be used (for readability the URI
skipping to change at page 49, line 20 skipping to change at page 48, line 49
ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one? ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one?
(objectClass=fedfsFsl) (objectClass=fedfsFsl)
This search is for the children of the object with DN This search is for the children of the object with DN
"fedfsFsnUuid=$FSNUUID,$NCE" with a filter for "fedfsFsnUuid=$FSNUUID,$NCE" with a filter for
"objectClass=fedfsFsl". The scope value of "one" restricts the "objectClass=fedfsFsl". The scope value of "one" restricts the
search to the entry's children (rather than the entire subtree below search to the entry's children (rather than the entire subtree below
the entry) and the filter ensures that only FSL entries are returned. the entry) and the filter ensures that only FSL entries are returned.
For example if $NSDBNAME is "nsdb.example.com", $FSNUUID is For example if $NSDBNAME is "nsdb.example.com", $FSNUUID is
"f81d4fae-7dec-11d0-a765-00a0c91e6bf6", and $NCE is "o=fedfs", the "e8c4761c-eb3b-4307-86fc-f702da197966", and $NCE is "o=fedfs", the
search would be (for readability the URI is split into three lines): search would be (for readability the URI is split into three lines):
ldap://nsdb.example.com/ ldap://nsdb.example.com/
fsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs fsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
??one?(objectClass=fedfsFsl) ??one?(objectClass=fedfsFsl)
The following search can be used to obtain only the NFS FSLs for The following search can be used to obtain only the NFS FSLs for
$FSNUUID on the NSDB named $NSDBNAME (for readability the URI is $FSNUUID on the NSDB named $NSDBNAME (for readability the URI is
split into two lines): split into two lines):
for each $NCE in nce_list for each $NCE in nce_list
ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one? ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one?
(objectClass=fedfsNfsFsl) (objectClass=fedfsNfsFsl)
This also searches for the children of the object with DN This also searches for the children of the object with DN
"fedfsFsnUuid=$FSNUUID,$NCE", but the filter for "objectClass = "fedfsFsnUuid=$FSNUUID,$NCE", but the filter for "objectClass =
fedfsNfsFsl" restricts the results to only NFS FSLs. fedfsNfsFsl" restricts the results to only NFS FSLs.
For example if $NSDBNAME is nsdb.example.com, $FSNUUID is f81d4fae- For example if $NSDBNAME is nsdb.example.com, $FSNUUID is "e8c4761c-
7dec-11d0-a765-00a0c91e6bf6, and $NCE is "o=fedfs",the search would eb3b-4307-86fc-f702da197966", and $NCE is "o=fedfs",the search would
be (for readability the URI is split into three lines): be (for readability the URI is split into three lines):
ldap://nsdb.example.com/ ldap://nsdb.example.com/
fsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs fsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
??one?(objectClass=fedfsNfsFsl) ??one?(objectClass=fedfsNfsFsl)
The fileserver will generate a referral based on the set of FSLs The fileserver will generate a referral based on the set of FSLs
returned by these queries using the process described in returned by these queries using the process described in
Section 2.8.3. Section 2.8.4.
5.3. NSDB Operations and LDAP Referrals 5.3. NSDB Operations and LDAP Referrals
The LDAPv3 protocol defines an LDAP referral mechanism that allows an The LDAPv3 protocol defines an LDAP referral mechanism that allows an
LDAP server to redirect an LDAP client. LDAPv3 defines two types of LDAP server to redirect an LDAP client. LDAPv3 defines two types of
LDAP referrals: the Referral type defined in Section 4.1.10 of LDAP referrals: the Referral type defined in Section 4.1.10 of
[RFC4511] and the SearchResultReference type defined in Section 4.5.3 [RFC4511] and the SearchResultReference type defined in Section 4.5.3
of [RFC4511]. In both cases, the LDAP referral lists one or more of [RFC4511]. In both cases, the LDAP referral lists one or more
URIs for services that can be used to complete the operation. In the URIs for services that can be used to complete the operation. In the
remainder of this document, the term LDAP referral is used to remainder of this document, the term LDAP referral is used to
skipping to change at page 50, line 32 skipping to change at page 50, line 12
LDAP referral is implementation and configuration dependent. For LDAP referral is implementation and configuration dependent. For
example, an NSDB client might be configured to follow only those LDAP example, an NSDB client might be configured to follow only those LDAP
referrals that were received over a secure channel, or only those referrals that were received over a secure channel, or only those
that target an NSDB that supports encrypted communication. If an that target an NSDB that supports encrypted communication. If an
NSDB client chooses to follow an LDAP referral, the NSDB client MUST NSDB client chooses to follow an LDAP referral, the NSDB client MUST
process the LDAP referral and prevent looping as described in Section process the LDAP referral and prevent looping as described in Section
4.1.10 of [RFC4511]. 4.1.10 of [RFC4511].
6. Security Considerations 6. Security Considerations
Both NFSv4/NFSv4.1 and LDAP provide security mechanisms. When used Both the NFSv4 and LDAPv3 protocols provide security mechanisms.
in conjunction with the federated filesystem protocols described in When used in conjunction with the federated filesystem protocols
this document, the use of these mechanisms is RECOMMENDED. described in this document, the use of these mechanisms is
Specifically, the use of RPCSEC_GSS [RFC2203], which is built on the RECOMMENDED. Specifically, the use of RPCSEC_GSS [RFC2203], which is
GSS-API [RFC2743], is RECOMMENDED on all NFS connections between a built on the GSS-API [RFC2743], is RECOMMENDED on all NFS connections
client and fileserver. The "Security Considerations" sections of the between a file-access client and fileserver. The "Security
the NFSv4 [3530bis] and NFSv4.1 [RFC5661] specifications contain Considerations" sections of the NFSv4.0 [3530bis] and NFSv4.1
special considerations for the handling of GETATTR operations for the [RFC5661] specifications contain special considerations for the
fs_locations and fs_locations_info attributes. For all LDAP handling of GETATTR operations for the fs_locations and
connections established by the federated filesystem protocols, the fs_locations_info attributes. For all LDAP connections established
use of TLS [RFC5246], as described in [RFC4513], is RECOMMENDED. by the federated filesystem protocols, the use of TLS [RFC5246], as
described in [RFC4513], is RECOMMENDED.
If an NSDB client chooses to follow an LDAP referral, the NSDB client If an NSDB client chooses to follow an LDAP referral, the NSDB client
SHOULD authenticate the LDAP referral's target NSDB using the target SHOULD authenticate the LDAP referral's target NSDB using the target
NSDB's credentials (not the credentials of the NSDB that generated NSDB's credentials (not the credentials of the NSDB that generated
the LDAP referral). The NSDB client SHOULD NOT follow an LDAP the LDAP referral). The NSDB client SHOULD NOT follow an LDAP
referral that targets an NSDB for which it does not know the NSDB's referral that targets an NSDB for which it does not know the NSDB's
credentials. credentials.
Within a federation, there are two types of components an attacker Within a federation, there are two types of components an attacker
may compromise: a fileserver and an NSDB. may compromise: a fileserver and an NSDB.
If an attacker compromises a fileserver, the attacker can interfere If an attacker compromises a fileserver, the attacker can interfere
with the client's filesystem I/O operations (e.g. by returning with a file-access client's filesystem I/O operations (e.g., by
fictitious data in the response to a read request) or fabricating a returning fictitious data in the response to a read request) or
referral. The attacker's abilities are the same regardless of fabricating a referral. The attacker's abilities are the same
whether or not the federation protocols are in use. While the regardless of whether or not the federation protocols are in use.
federation protocols do not give the attacker additional While the federation protocols do not give the attacker additional
capabilities, they are additional targets for attack. The LDAP capabilities, they are additional targets for attack. The LDAP
protocol described in Section 5.2 SHOULD be secured using the methods protocol described in Section 5.2 SHOULD be secured using the methods
described above to defeat attacks on a fileserver via this channel. described above to defeat attacks on a fileserver via this channel.
If an attacker compromises an NSDB, the attacker will be able to If an attacker compromises an NSDB, the attacker will be able to
forge FSL information and thus poison the fileserver's referral forge FSL information and thus poison the fileserver's referral
information. Therefore an NSDB should be as secure as the information. Therefore an NSDB should be as secure as the
fileservers which query it. The LDAP operations described in fileservers which query it. The LDAP operations described in
Section 5 SHOULD be secured using the methods described above to Section 5 SHOULD be secured using the methods described above to
defeat attacks on an NSDB via this channel. defeat attacks on an NSDB via this channel.
A fileserver binds anonymously when performing NSDB operations. Thus
the contents and distinguished names of FSN and FSL records are
required to be readable by anyone who can bind anonymously to an NSDB
service. Section 2.12 presents the security considerations in the
choice of the type of UUID used in these records.
It should be noted that the federation protocols do not directly It should be noted that the federation protocols do not directly
provide access to filesystem data. The federation protocols only provide access to filesystem data. The federation protocols only
provide a mechanism for building a namespace. All data transfers provide a mechanism for building a namespace. All data transfers
occur between a client and server just as they would if the occur between a file-access client and fileserver just as they would
federation protocols were not in use. As a result, the federation if the federation protocols were not in use. As a result, the
protocols do not require new user authentication and authorization federation protocols do not require new user authentication and
mechanisms or require a fileserver to act as a proxy for a client. authorization mechanisms or require a fileserver to act as a proxy
for a client.
7. IANA Considerations 7. IANA Considerations
7.1. Registry for the fedfsAnnotation Key Namespace 7.1. Registry for the fedfsAnnotation Key Namespace
This document defines the fedfsAnnotation key in Section 4.2.1.12. This document defines the fedfsAnnotation key in Section 4.2.1.6.
The fedfsAnnotation key namespace is to be managed by IANA. IANA is The fedfsAnnotation key namespace is to be managed by IANA. IANA is
to create and maintain a new registry entitled "FedFS Annotation to create and maintain a new registry entitled "FedFS Annotation
Keys". Future registrations are to be administered by IANA using the Keys". Future registrations are to be administered by IANA using the
"First Come First Served" policy defined in [RFC5226]. Registration "First Come First Served" policy defined in [RFC5226]. Registration
requests MUST include the key (a valid UTF-8 string of any length), a requests MUST include the key (a valid UTF-8 string of any length), a
brief description of the key's purpose, and an email contact for the brief description of the key's purpose, and an email contact for the
registration. For viewing, the registry should be sorted registration. For viewing, the registry should be sorted
lexicographically by key. There are no initial assignments for this lexicographically by key. There are no initial assignments for this
registry. registry.
skipping to change at page 53, line 5 skipping to change at page 52, line 6
Identifiers" for the purpose of administering the FedFS Object Identifiers" for the purpose of administering the FedFS Object
Identifier (OID) range. Future allocations from the Identifier (OID) range. Future allocations from the
1.3.6.1.4.1.31103.1.x range are to be assigned by IANA using the "RFC 1.3.6.1.4.1.31103.1.x range are to be assigned by IANA using the "RFC
Required" policy defined in [RFC5226]. Registration requests MUST Required" policy defined in [RFC5226]. Registration requests MUST
include an OID value from the 1.3.6.1.4.1.31103.1.x range, a short include an OID value from the 1.3.6.1.4.1.31103.1.x range, a short
description of the OID, and a reference to the specification that description of the OID, and a reference to the specification that
defines the OID's usage. For viewing, the registry should be sorted defines the OID's usage. For viewing, the registry should be sorted
numerically by OID value. The initial contents of the FedFS Object numerically by OID value. The initial contents of the FedFS Object
Identifiers registry are given in Table 1. Identifiers registry are given in Table 1.
+--------------------------+-------------------------+-----------+ +--------------------------+-------------------------+------------+
| OID | Description | Reference | | OID | Description | Reference |
+--------------------------+-------------------------+-----------+ +--------------------------+-------------------------+------------+
| 1.3.6.1.4.1.31103.1.1 | fedfsUuid | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.1 | fedfsUuid | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.2 | fedfsNetAddr | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.2 | fedfsNetAddr | deprecated |
| 1.3.6.1.4.1.31103.1.3 | fedfsNetPort | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.3 | fedfsNetPort | deprecated |
| 1.3.6.1.4.1.31103.1.4 | fedfsFsnUuid | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.4 | fedfsFsnUuid | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.5 | fedfsNsdbName | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.5 | fedfsNsdbName | deprecated |
| 1.3.6.1.4.1.31103.1.6 | fedfsNsdbPort | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.6 | fedfsNsdbPort | deprecated |
| 1.3.6.1.4.1.31103.1.7 | fedfsNcePrefix | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.7 | fedfsNcePrefix | deprecated |
| 1.3.6.1.4.1.31103.1.8 | fedfsFslUuid | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.8 | fedfsFslUuid | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.9 | fedfsFslHost | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.9 | fedfsFslHost | deprecated |
| 1.3.6.1.4.1.31103.1.10 | fedfsFslPort | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.10 | fedfsFslPort | deprecated |
| 1.3.6.1.4.1.31103.1.11 | fedfsFslTTL | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.11 | fedfsFslTTL | deprecated |
| 1.3.6.1.4.1.31103.1.12 | fedfsAnnotation | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.12 | fedfsAnnotation | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.13 | fedfsDescr | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.13 | fedfsDescr | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.100 | fedfsNfsPath | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.14 | fedfsNceDN | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.101 | fedfsNfsMajorVer | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.15 | fedfsFsnTTL | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.102 | fedfsNfsMinorVer | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.100 | fedfsNfsPath | deprecated |
| 1.3.6.1.4.1.31103.1.103 | fedfsNfsCurrency | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.101 | fedfsNfsMajorVer | deprecated |
| 1.3.6.1.4.1.31103.1.104 | fedfsNfsGenFlagWritable | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.102 | fedfsNfsMinorVer | deprecated |
| 1.3.6.1.4.1.31103.1.105 | fedfsNfsGenFlagGoing | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.103 | fedfsNfsCurrency | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.106 | fedfsNfsGenFlagSplit | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.104 | fedfsNfsGenFlagWritable | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.107 | fedfsNfsTransFlagRdma | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.105 | fedfsNfsGenFlagGoing | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.108 | fedfsNfsClassSimul | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.106 | fedfsNfsGenFlagSplit | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.109 | fedfsNfsClassHandle | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.107 | fedfsNfsTransFlagRdma | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.110 | fedfsNfsClassFileid | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.108 | fedfsNfsClassSimul | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.111 | fedfsNfsClassWritever | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.109 | fedfsNfsClassHandle | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.112 | fedfsNfsClassChange | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.110 | fedfsNfsClassFileid | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.113 | fedfsNfsClassReaddir | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.111 | fedfsNfsClassWritever | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.114 | fedfsNfsReadRank | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.112 | fedfsNfsClassChange | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.115 | fedfsNfsReadOrder | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.113 | fedfsNfsClassReaddir | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.116 | fedfsNfsWriteRank | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.114 | fedfsNfsReadRank | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.117 | fedfsNfsWriteOrder | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.115 | fedfsNfsReadOrder | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.118 | fedfsNfsVarSub | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.116 | fedfsNfsWriteRank | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.119 | fedfsNfsValidFor | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.117 | fedfsNfsWriteOrder | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.1001 | fedfsNsdbContainerInfo | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.118 | fedfsNfsVarSub | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.1002 | fedfsFsn | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.119 | fedfsNfsValidFor | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.1003 | fedfsFsl | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.120 | fedfsNfsURI | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.1004 | fedfsNfsFsl | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.1001 | fedfsNsdbContainerInfo | RFC-TBD1 |
+--------------------------+-------------------------+-----------+ | 1.3.6.1.4.1.31103.1.1002 | fedfsFsn | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.1003 | fedfsFsl | RFC-TBD1 |
| 1.3.6.1.4.1.31103.1.1004 | fedfsNfsFsl | RFC-TBD1 |
+--------------------------+-------------------------+------------+
Table 1 Table 1
7.3. LDAP Descriptor Registration 7.3. LDAP Descriptor Registration
In accordance with Section 3.4 and Section 4 of [RFC4520], the object In accordance with Section 3.4 and Section 4 of [RFC4520], the object
identifier descriptors defined in this document (listed below) will identifier descriptors defined in this document (listed below) will
be registered via the Expert Review process. be registered via the Expert Review process.
Subject: Request for LDAP Descriptor Registration Subject: Request for LDAP Descriptor Registration
skipping to change at page 54, line 23 skipping to change at page 53, line 23
"Author/Change Controller" "Author/Change Controller"
Specification: draft-ietf-nfsv4-federated-fs-protocol Specification: draft-ietf-nfsv4-federated-fs-protocol
Author/Change Controller: [document authors] Author/Change Controller: [document authors]
Object Identifier: 1.3.6.1.4.1.31103.1.1 Object Identifier: 1.3.6.1.4.1.31103.1.1
Descriptor (short name): fedfsUuid Descriptor (short name): fedfsUuid
Usage: attribute type Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.2 Object Identifier: 1.3.6.1.4.1.31103.1.2
Descriptor (short name): fedfsNetAddr Descriptor (short name): fedfsNetAddr
Usage: attribute type Usage: attribute type, deprecated
Object Identifier: 1.3.6.1.4.1.31103.1.3 Object Identifier: 1.3.6.1.4.1.31103.1.3
Descriptor (short name): fedfsNetPort Descriptor (short name): fedfsNetPort
Usage: attribute type Usage: attribute type, deprecated
Object Identifier: 1.3.6.1.4.1.31103.1.4 Object Identifier: 1.3.6.1.4.1.31103.1.4
Descriptor (short name): fedfsFsnUuid Descriptor (short name): fedfsFsnUuid
Usage: attribute type Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.5 Object Identifier: 1.3.6.1.4.1.31103.1.5
Descriptor (short name): fedfsNsdbName Descriptor (short name): fedfsNsdbName
Usage: attribute type Usage: attribute type, deprecated
Object Identifier: 1.3.6.1.4.1.31103.1.6 Object Identifier: 1.3.6.1.4.1.31103.1.6
Descriptor (short name): fedfsNsdbPort Descriptor (short name): fedfsNsdbPort
Usage: attribute type Usage: attribute type, deprecated
Object Identifier: 1.3.6.1.4.1.31103.1.7 Object Identifier: 1.3.6.1.4.1.31103.1.7
Descriptor (short name): fedfsNcePrefix Descriptor (short name): fedfsNcePrefix
Usage: attribute type Usage: attribute type, deprecated
Object Identifier: 1.3.6.1.4.1.31103.1.8 Object Identifier: 1.3.6.1.4.1.31103.1.8
Descriptor (short name): fedfsFslUuid Descriptor (short name): fedfsFslUuid
Usage: attribute type Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.9 Object Identifier: 1.3.6.1.4.1.31103.1.9
Descriptor (short name): fedfsFslHost Descriptor (short name): fedfsFslHost
Usage: attribute type Usage: attribute type, deprecated
Object Identifier: 1.3.6.1.4.1.31103.1.10 Object Identifier: 1.3.6.1.4.1.31103.1.10
Descriptor (short name): fedfsFslPort Descriptor (short name): fedfsFslPort
Usage: attribute type Usage: attribute type, deprecated
Object Identifier: 1.3.6.1.4.1.31103.1.11 Object Identifier: 1.3.6.1.4.1.31103.1.11
Descriptor (short name): fedfsFslTTL Descriptor (short name): fedfsFslTTL
Usage: attribute type Usage: attribute type, deprecated
Object Identifier: 1.3.6.1.4.1.31103.1.12 Object Identifier: 1.3.6.1.4.1.31103.1.12
Descriptor (short name): fedfsAnnotation Descriptor (short name): fedfsAnnotation
Usage: attribute type Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.13 Object Identifier: 1.3.6.1.4.1.31103.1.13
Descriptor (short name): fedfsDescr Descriptor (short name): fedfsDescr
Usage: attribute type Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.14
Descriptor (short name): fedfsNceDN
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.15
Descriptor (short name): fedfsFsnTTL
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.100 Object Identifier: 1.3.6.1.4.1.31103.1.100
Descriptor (short name): fedfsNfsPath Descriptor (short name): fedfsNfsPath
Usage: attribute type Usage: attribute type, deprecated
Object Identifier: 1.3.6.1.4.1.31103.1.101 Object Identifier: 1.3.6.1.4.1.31103.1.101
Descriptor (short name): fedfsNfsMajorVer Descriptor (short name): fedfsNfsMajorVer
Usage: attribute type Usage: attribute type, deprecated
Object Identifier: 1.3.6.1.4.1.31103.1.102 Object Identifier: 1.3.6.1.4.1.31103.1.102
Descriptor (short name): fedfsNfsMinorVer Descriptor (short name): fedfsNfsMinorVer
Usage: attribute type Usage: attribute type, deprecated
Object Identifier: 1.3.6.1.4.1.31103.1.103 Object Identifier: 1.3.6.1.4.1.31103.1.103
Descriptor (short name): fedfsNfsCurrency Descriptor (short name): fedfsNfsCurrency
Usage: attribute type Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.104 Object Identifier: 1.3.6.1.4.1.31103.1.104
Descriptor (short name): fedfsNfsGenFlagWritable Descriptor (short name): fedfsNfsGenFlagWritable
Usage: attribute type Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.105 Object Identifier: 1.3.6.1.4.1.31103.1.105
Descriptor (short name): fedfsNfsGenFlagGoing Descriptor (short name): fedfsNfsGenFlagGoing
Usage: attribute type Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.106 Object Identifier: 1.3.6.1.4.1.31103.1.106
Descriptor (short name): fedfsNfsGenFlagSplit Descriptor (short name): fedfsNfsGenFlagSplit
Usage: attribute type Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.107 Object Identifier: 1.3.6.1.4.1.31103.1.107
Descriptor (short name): fedfsNfsTransFlagRdma Descriptor (short name): fedfsNfsTransFlagRdma
Usage: attribute type Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.108 Object Identifier: 1.3.6.1.4.1.31103.1.108
Descriptor (short name): fedfsNfsClassSimul Descriptor (short name): fedfsNfsClassSimul
skipping to change at page 57, line 16 skipping to change at page 56, line 24
Usage: attribute type Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.118 Object Identifier: 1.3.6.1.4.1.31103.1.118
Descriptor (short name): fedfsNfsVarSub Descriptor (short name): fedfsNfsVarSub
Usage: attribute type Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.119 Object Identifier: 1.3.6.1.4.1.31103.1.119
Descriptor (short name): fedfsNfsValidFor Descriptor (short name): fedfsNfsValidFor
Usage: attribute type Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.120
Descriptor (short name): fedfsNfsURI
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.1001 Object Identifier: 1.3.6.1.4.1.31103.1.1001
Descriptor (short name): fedfsNsdbContainerInfo Descriptor (short name): fedfsNsdbContainerInfo
Usage: object class Usage: object class
Object Identifier: 1.3.6.1.4.1.31103.1.1002 Object Identifier: 1.3.6.1.4.1.31103.1.1002
Descriptor (short name): fedfsFsn Descriptor (short name): fedfsFsn
Usage: object class Usage: object class
Object Identifier: 1.3.6.1.4.1.31103.1.1003 Object Identifier: 1.3.6.1.4.1.31103.1.1003
Descriptor (short name): fedfsFsl Descriptor (short name): fedfsFsl
Usage: object class Usage: object class
Object Identifier: 1.3.6.1.4.1.31103.1.1004 Object Identifier: 1.3.6.1.4.1.31103.1.1004
Descriptor (short name): fedfsNfsFsl Descriptor (short name): fedfsNfsFsl
Usage: object class Usage: object class
8. Glossary 8. Glossary
Administrator: user with the necessary authority to initiate Administrator: An 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.
Federation: A set of server collections and singleton servers that Federation: A set of server collections and singleton servers that
use a common set of interfaces and protocols in order to provide use a common set of interfaces and protocols in order to provide
skipping to change at page 58, line 24 skipping to change at page 57, line 35
Filesystem: A self-contained unit of export for a fileserver, and Filesystem: A self-contained unit of export for a fileserver, and
the mechanism used to implement filesets. The fileset does not the mechanism used to implement filesets. The fileset does not
need to be rooted at the root of the filesystem, nor at the export need to be rooted at the root of the filesystem, nor at the export
point for the filesystem. point for the filesystem.
A single filesystem MAY implement more than one fileset, if the A single filesystem MAY implement more than one fileset, if the
client protocol and the fileserver permit this. client protocol and the fileserver permit this.
Filesystem Access Protocol: A network filesystem access protocol Filesystem Access Protocol: A network filesystem access protocol
such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [3530bis], or CIFS such as NFSv3 [RFC1813], NFSv4 [3530bis], or CIFS (Common Internet
(Common Internet File System) [MS-SMB] [MS-SMB2] [MS-CIFS]. File System) [MS-SMB] [MS-SMB2] [MS-CIFS].
FSL (Fileset Location): The location of the implementation of a FSL (Fileset Location): The location of the implementation of a
fileset at a particular moment in time. An FSL MUST be something fileset at a particular moment in time. An FSL MUST be something
that can be translated into a protocol-specific description of a that can be translated into a protocol-specific description of a
resource that a client can access directly, such as an fs_location resource that a client can access directly, such as an fs_location
(for NFSv4), or share name (for CIFS). Note that not all FSLs (for NFSv4), or share name (for CIFS). Note that not all FSLs
need to be explicitly exported as long as they are contained need to be explicitly exported as long as they are contained
within an exported path on the fileserver. within an exported path on the fileserver.
FSN (Fileset Name): A platform-independent and globally unique name FSN (Fileset Name): A platform-independent and globally unique name
skipping to change at page 59, line 38 skipping to change at page 59, line 4
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.
9. References 9. References
9.1. Normative References 9.1. Normative References
[3530bis] Haynes, T. and D. Noveck, "NFS Version 4 Protocol", [3530bis] Haynes, T. and D. Noveck, "NFS Version 4 Protocol",
draft-ietf-nfsv4-rfc3530bis (Work In Progress), 2010. draft-ietf-nfsv4-rfc3530bis (Work In Progress), 2010.
[RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers (URIs)",
RFC 2079, January 1997.
[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.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
skipping to change at page 60, line 20 skipping to change at page 59, line 37
Technical Specification", RFC 2849, June 2000. Technical Specification", RFC 2849, June 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, (LDAP): Technical Specification Road Map", RFC 4510,
June 2006. June 2006.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006. (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, (LDAP): Directory Information Models", RFC 4512,
June 2006. June 2006.
skipping to change at page 61, line 5 skipping to change at page 60, line 20
Syntaxes and Matching Rules", RFC 4517, June 2006. Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519, (LDAP): Schema for User Applications", RFC 4519,
June 2006. June 2006.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 4520, June 2006. Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) entryUUID Operational Attribute", RFC 4530,
June 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[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.
skipping to change at page 61, line 31 skipping to change at page 60, line 50
[AFS] Howard, J., "An Overview of the Andrew File System", [AFS] Howard, J., "An Overview of the Andrew File System",
Proceeding of the USENIX Winter Technical Conference , Proceeding of the USENIX Winter Technical Conference ,
1988. 1988.
[FEDFS-ADMIN] [FEDFS-ADMIN]
Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Administration Protocol for Federated Filesystems", Naik, "Administration Protocol for Federated Filesystems",
draft-ietf-nfsv4-federated-fs-admin (Work In Progress), draft-ietf-nfsv4-federated-fs-admin (Work In Progress),
2010. 2010.
[FEDFS-DNS-SRV]
Everhart, C., Adamson, W., and J. Zhang, "Using DNS SRV to
Specify a Global File Name Space with NFS version 4",
draft-ietf-nfsv4-federated-fs-dns-srv-namespace (Work In
Progress), 2010.
[MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS) [MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS)
Protocol Specification", MS-CIFS 2.0, November 2009. Protocol Specification", MS-CIFS 2.0, November 2009.
[MS-SMB] Microsoft Corporation, "Server Message Block (SMB) [MS-SMB] Microsoft Corporation, "Server Message Block (SMB)
Protocol Specification", MS-SMB 17.0, November 2009. Protocol Specification", MS-SMB 17.0, November 2009.
[MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version [MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version
2 Protocol Specification", MS-SMB2 19.0, November 2009. 2 Protocol Specification", MS-SMB2 19.0, November 2009.
[RFC1094] Nowicki, B., "NFS: Network File System Protocol
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.
[RFC2224] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
[RFC3254] Alvestrand, H., "Definitions for talking about [RFC3254] Alvestrand, H., "Definitions for talking about
directories", RFC 3254, April 2002. directories", RFC 3254, April 2002.
[RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 External Data System (NFS) Version 4 Minor Version 1 External Data
Representation Standard (XDR) Description", RFC 5662, Representation Standard (XDR) Description", RFC 5662,
January 2010. January 2010.
[RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Requirements for Federated File Systems", RFC 5716, Naik, "Requirements for Federated File Systems", RFC 5716,
January 2010. January 2010.
[RFC6641] Everhart, C., Adamson, W., and J. Zhang, "Using DNS SRV to
Specify a Global File Namespace with NFS Version 4",
RFC 6641, June 2012.
Appendix A. Acknowledgments Appendix A. Acknowledgments
We would like to thank Andy Adamson of NetApp, Paul Lemahieu of EMC, We would like to thank Andy Adamson of NetApp, Paul Lemahieu of EMC,
Robert Thurlow of Sun Microsystems, and Mario Wurzl of EMC for Robert Thurlow of Oracle, and Mario Wurzl of EMC for helping to
helping to author this document. author this document.
We would like to thank Craig Everhart and Manoj Naik, who were co-
authors of an earlier version of this document.
We would also like to thank George Amvrosiadis, Chuck Lever, Trond We would also like to thank George Amvrosiadis, Chuck Lever, Trond
Myklebust, and Nicolas Williams for their comments. Myklebust, Howard Chu, and Nicolas Williams for their comments.
Finally, we would also like to thank Andy Adamson, Rob Thurlow, Tom
Haynes, and Chuck Lever for the editing effort to get this document
out the door.
The extract.sh shell script and formatting conventions were first The extract.sh shell script and formatting conventions were first
described by the authors of the NFSv4.1 XDR specification [RFC5662]. described by the authors of the NFSv4.1 XDR specification [RFC5662].
Authors' Addresses Authors' Addresses
James Lentini James Lentini
NetApp NetApp
1601 Trapelo Rd, Suite 16 1601 Trapelo Rd, Suite 16
Waltham, MA 02451 Waltham, MA 02451
US US
Phone: +1 781-768-5359 Phone: +1 781-768-5359
Email: jlentini@netapp.com Email: jlentini@netapp.com
Craig Everhart
NetApp
800 Cranberry Woods Drive
Cranberry Township, PA 16066
US
Phone: +1 724-741-5101
Email: Craig.Everhart@netapp.com
Daniel Ellard Daniel Ellard
Raytheon BBN Technologies Raytheon BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge, MA 02138 Cambridge, MA 02138
US US
Phone: +1 617-873-8004 Phone: +1 617-873-8004
Email: dellard@bbn.com Email: dellard@bbn.com
Renu Tewari Renu Tewari
IBM Almaden IBM Almaden
650 Harry Rd 650 Harry Rd
San Jose, CA 95120 San Jose, CA 95120
US US
Email: tewarir@us.ibm.com Email: tewarir@us.ibm.com
Manoj Naik Charles Lever (editor)
IBM Almaden Oracle Corporation
650 Harry Rd 1015 Granger Avenue
San Jose, CA 95120 Ann Arbor, MI 48104
US US
Email: manoj@almaden.ibm.com Phone: +1 248-614-5091
Email: chuck.lever@oracle.com
 End of changes. 198 change blocks. 
800 lines changed or deleted 746 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/