Subject: [nfsv4] [PATCH 1/5] Use the term "file-access client" consistently

From: Chuck Lever <[email-masked]>
Date: Tue, 11 Sep 2012 10:07:51 -0400

My experience trying to explain FedFS to newcomers suggests we
should be more careful to disambiguate the use of the term "client."

The draft is already careful to use the term "NSDB client" or "LDAP
client" in all the appropriate places.  The term "file-access
client" is defined in the forward glossary, so let's use that term
consistently when referring to clients of fileservers.

Replace wholesale a couple of paragraphs due to inaccuracies or
other problems in the existing text.
---

 nsdb-proto.xml |  156 +++++++++++++++++++++++++++++---------------------------
 1 files changed, 80 insertions(+), 76 deletions(-)

diff --git a/nsdb-proto.xml b/nsdb-proto.xml
index c7f4b0e..3694c51 100644
--- a/nsdb-proto.xml
+++ b/nsdb-proto.xml
@@ -131,10 +131,10 @@
 
     <section title="Fileserver">
 
-        <t> Fileservers are servers that store the physical fileset
-        data or refer the client to other fileservers. A fileserver
-        can be implemented in a number of different ways, including
-        a single system, a cluster of systems, or some other
+        <t> Fileservers are servers that store physical fileset
+        data, or refer file-access clients to other fileservers. A
+        fileserver can be implemented in a number of different ways,
+        including a single system, a cluster of systems, or some other
         configuration. A fileserver provides access to a federated
         filesystem via NFSv4, NFSv4.1, or some other file-access
         protocol. </t>
@@ -144,7 +144,7 @@
     <section title="Referral">
 
         <t> A referral is a mechanism by which a fileserver
-        redirects a file-access protocol client to a different
+        redirects a file-access client to a different
         fileserver. The exact information contained in a referral
         varies from one file-access protocol to another. The NFSv4
         protocol defines the fs_locations attribute for
@@ -156,23 +156,26 @@
     <section title="Namespace">
 
         <t> 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 namespace.  This should be
-        achieved with minimal or zero client configuration.  In
-        particular, updates to the common namespace should not
-        require configuration changes at the client.  Filesets,
-        which are the unit of data management, are a set of
-        files and directories.  From the perspective of the
-        clients, the common namespace is constructed by mounting
-        filesets that are physically located on different
+        managed data available to any file-access client via the
+        same path in a common filesystem namespace.  This should
+        be achieved with minimal or zero configuration on file-access
+        clients.  In particular, updates to the common namespace
+        should not require configuration changes to any file-access
+        client. </t>
+
+        <t> Filesets, which are the unit of data management, are
+        a set of files and directories.  From the perspective of
+        file-access clients, the common namespace is constructed by
+        mounting filesets that are physically located on different
         fileservers.  The namespace, which is defined in terms
         of fileset definitions, fileset identifiers, the
         location of each fileset in the namespace, and the
         physical location of the implementation(s) of each
         fileset, is stored in a set of namespace repositories,
-        each managed by an administrative entity.  The namespace
-        schema defines the model used for populating, modifying,
-        and querying the namespace repositories.  It is not
+        each managed by an administrative entity. </t>
+
+        <t> The namespace schema defines the model used for populating,
+        modifying, and querying the namespace repositories.  It is not
         required by the federation that the namespace be common
         across all fileservers.  It should be possible to have
         several independently rooted namespaces. </t>
@@ -253,12 +256,12 @@
 
     <section title="Fileset Location (FSL)">
 
-        <t> An FSL describes the location where the fileset
-        data resides.  An FSL contains generic and type specific
-        information which together describe how to access the fileset.
-        An FSL's type indicates which protocol(s) may be used
-        to access its data. An FSL's attributes can be used by a fileserver
-        to decide which locations it will return to a client. </t>
+        <t> An FSL describes one physical location where a complete
+        copy of the fileset's data resides.  An FSL contains generic
+        and type specific information which together describe how to
+        access the fileset data at this location.  An FSL's attributes
+        can be used by a fileserver to decide which locations it will
+        return to a file-access client. </t>
 
         <t> An FSL consists of: </t>
 
@@ -390,8 +393,8 @@
 
         <t> 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; the different
-        locations of a fileset represent the same data,
+        point of view of access by a file-access client.  Different
+        fileset locations for an FSN represent the same data,
         though potentially at different points in time.
         Fileset locations are equivalent but not identical.
         Locations may either be read-only or read-write.
@@ -414,17 +417,17 @@
         responsibility of administrators to guarantee the
         functional equivalence of the data.  </t>
 
-        <t> The federation protocol does not guarantee that
-        the different locations are mutually consistent in
-        terms of the currency of the data.  It relies on the
-        file-access protocol to contain
-        sufficient information to help clients determine
-        the currency of the data at each location in order
-        to ensure that the clients do not revert back in
-        time when switching locations. NFSv4.1 provides
-        guidance on how replication can be handled in such a
-        manner, in particular see Section 11.7 of
-        <xref target='RFC5661' />.   </t>
+        <t> The federation protocols do not guarantee that
+        different fileset locations are mutually consistent in
+        terms of the currency of their data.  However, they provide
+        a means to publish currency information so that all
+        fileservers in a federation can convey the same information
+        to file-access clients during referrals.  Clients use 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 <xref target="RFC5661"/>.  </t>
 
         </section>
 
@@ -459,9 +462,9 @@
         SHOULD create a junction at the fileset's old location referring
         back to the NSDB 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. </t>
+        Thus, in the above example, fileserver A would direct file-access
+        clients to fileserver B, but fileserver B would direct file-access
+        clients to fileserver C. </t>
 
         <t> Such supplemental junctions (on fileserver B in the example)
         would not be required to be in place forever. They need to stay
@@ -481,13 +484,14 @@
         <section title="Generating A Referral from Fileset Locations" anchor="fsl_referral">
 
         <t> After resolving an FSN to a set of FSL records, the
-        fileserver can generate a referral to redirect the
-        client to one or more of the FSLs. The fileserver will
-        convert the FSL records to a referral format understood
-        by the client, such as an NFSv4 fs_locations attribute
-        or NFSv4.1 fs_locations_info attribute. </t>
-
-        <t> In order to give the client as many options as
+        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 attribute or NFSv4.1 fs_locations_info
+        attribute. </t>
+
+        <t> To give file-access clients as many options as
         possible, the fileserver SHOULD include the maximum
         possible number of FSL records in a referral. However,
         the fileserver MAY omit some of the FSL records
@@ -575,11 +579,11 @@
     <section title="Mount Points, Junctions and Referrals">
 
         <t> 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).  </t>
+        where a target fileset may be attached.  If a file-access
+        client traverses the path leading from the root of the
+        namespace to the mount point of a target fileset, it
+        should be able to mount and access the data in that
+        target fileset (assuming appropriate permissions).  </t>
 
         <t> The directory where a fileset is mounted is
         represented by a junction in the underlying filesystem.
@@ -599,13 +603,12 @@
         (as described earlier) contains the authoritative
         NSDB node, and the FsnUuid (a UUID for the fileset).  </t>
 
-        <t> When a client traversal reaches a junction, the
-        client is referred to a list of FSLs associated with the
-        FSN targeted by the junction.  The client can then redirect
-        its connection to one of the FSLs.  This act 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.  </t>
+        <t> When a file-access client reaches a junction, the
+        fileserver refers the client to a list of FSLs associated
+        with the FSN targeted by the junction.  The client can then
+        mount one of the associated FSLs.  For NFSv4 and NFSv4.1
+        clients, the FSL information is returned in the fs_locations
+        and fs_locations_info attributes respectively.  </t>
 
         <t> The federation protocols do not limit where and
         how many times a fileset is mounted in the namespace.
@@ -621,8 +624,9 @@
         namespace is the top level directory of this fileset. A set of
         designated fileservers in the federation can export the root
         fileset to render the federation-wide unified namespace. When
-        a client mounts the root fileset from any of these designated
-        fileservers it can view a common federation-wide namespace.  </t>
+        a file-access client mounts the root fileset from any of these
+        designated fileservers it can view a common federation-wide
+        namespace.  </t>
 
         <t> The root fileset could be implemented either as an exported
         NFS file system or as data in the NSDB itself. The properties
@@ -777,9 +781,10 @@
 
         <t> A fileset may contain references to other filesets.
         These references are represented by junctions.  If a
-        client requests access to a fileset object that is a
-        junction, the fileserver resolves the junction to discover
-        one or more FSLs that implement the referenced fileset. </t>
+        file-access client requests access to a fileset object that
+        is a junction, the fileserver resolves the junction to
+        discover one or more FSLs that implement the referenced
+        fileset. </t>
 
         <t> There are many possible variations to this
         procedure, depending on how the junctions are
@@ -808,7 +813,7 @@
             empty) set of FSLs.  </t>
 
             <t> The fileserver converts one or more of the FSLs to
-            the location type used by the client (e.g.,
+            the location type used by the file-access client (e.g.,
             a Network File System (NFSv4) fs_location,
             as described in <xref target="3530bis"/>).  </t>
 
@@ -2187,9 +2192,8 @@
         are not deleted.  Any junction that has this FSN as
         its target may continue to point to this
         non-existent FSN.  A dangling reference may be
-        detected when a client tries to resolve the target
-        of a junction that refers to the deleted FSN and the
-        NSDB returns an error.  </t>
+        detected when a fileserver tries to resolve a junction
+        that refers to the deleted FSN.  </t>
 
         <section title="LDAP Request">
 
@@ -2612,8 +2616,8 @@
     this document, the use of these mechanisms is RECOMMENDED. Specifically,
     the use of RPCSEC_GSS <xref target="RFC2203"/>, which is built on the
     GSS-API <xref target="RFC2743"/>, is RECOMMENDED on all NFS connections
-    between a client and fileserver. The "Security Considerations" sections of
-    the NFSv4 <xref target="3530bis"/> and NFSv4.1 <xref target="RFC5661"/>
+    between a file-access client and fileserver. The "Security Considerations"
+    sections of the NFSv4 <xref target="3530bis"/> and NFSv4.1 <xref target="RFC5661"/>
     specifications contain special considerations for the handling of GETATTR
     operations for the fs_locations and fs_locations_info attributes. For all
     LDAP connections established by the federated filesystem protocols, the
@@ -2631,9 +2635,9 @@
     may compromise: a fileserver and an NSDB. </t>
 
     <t> If an attacker compromises a fileserver, the attacker can interfere
-    with the client's filesystem I/O operations (e.g., by returning fictitious
-    data in the response to a read request) or fabricating a referral. The
-    attacker's abilities are the same regardless of whether or not the
+    with a file-access client's filesystem I/O operations (e.g., by returning
+    fictitious data in the response to a read request) or fabricating a referral.
+    The attacker's abilities are the same regardless of whether or not the
     federation protocols are in use. While the federation protocols do not
     give the attacker additional capabilities, they are additional targets for
     attack. The LDAP protocol described in <xref target="nsdb-ops-fileservers"/>
@@ -2656,10 +2660,10 @@
     <t> It should be noted that the federation protocols do not directly
     provide access to filesystem data. The federation protocols only
     provide a mechanism for building a namespace. All data transfers
-    occur between a client and server just as they would if the federation
-    protocols were not in use. As a result, the federation protocols do not
-    require new user authentication and authorization mechanisms or require
-    a fileserver to act as a proxy for a client. </t>
+    occur between a file-access client and fileserver just as they would if
+    the federation protocols were not in use. As a result, the federation
+    protocols do not require new user authentication and authorization
+    mechanisms or require a fileserver to act as a proxy for a client. </t>
 
     </section>

---

From: Chuck Lever <[email-masked]>
Date: Tue, 11 Sep 2012 10:08:02 -0400

Currently the NSDB protocol draft text uses the term "NFSv4" to mean
NFS version 4 minor version 0, but "NFSv4.1" to mean NFS version 4
minor version 1.

Note also that NFSv4.1 fileservers can return referrals via either
an fs_locations or an fs_locations_info attribute.  Most current
NFSv4.1 fileserver implementations continue to use fs_locations
for now.  In fact, we already know that, for example, minor version
2 continues to support both attributes.

For consistency and clarity, use the term "NFSv4" to mean any minor
version of NFS version 4, and "NFSv4.0" to mean specifically minor
version 0 (as specified in RFC 3530 and bis).  Make the text less
dependent on specific NFS minor versions.  Specific language
claiming that NFSv4.1 fileservers return only fs_locations_info is
inaccurate and is replaced or removed.
---

 nsdb-proto.xml |   83 ++++++++++++++++++++++++++++----------------------------
 1 files changed, 41 insertions(+), 42 deletions(-)

diff --git a/nsdb-proto.xml b/nsdb-proto.xml
index 3694c51..2f6a5f8 100644
--- a/nsdb-proto.xml
+++ b/nsdb-proto.xml
@@ -95,9 +95,10 @@
     mechanism to manage the namespace or exchange namespace information. </t>
 
     <t> The federated filesystem protocols in this document define
-    how to construct a namespace accessible by an NFSv4 <xref target="3530bis"/>
-    or NFSv4.1 <xref target="RFC5661"/> client and have been designed
-    to accommodate other file access protocols in the future. </t>
+    how to construct a namespace accessible by an NFSv4.0
+    <xref target="3530bis"/>, NFSv4.1 <xref target="RFC5661"/> or newer
+    client and have been designed to accommodate other file access
+    protocols in the future. </t>
 
     <t> The requirements for federated filesystems are described
     in <xref target="RFC5716"/>. A protocol for administering
@@ -115,8 +116,8 @@
     <section title="File-access Protocol">
 
         <t> 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-access protocol. </t>
+        accessing data. The NFSv4.0 protocol <xref target="3530bis"/>
+        is an example of a file-access protocol. </t>
 
     </section>
 
@@ -124,20 +125,19 @@
 
         <t> File-access clients are standard off-the-shelf network
         attached storage (NAS) clients that communicate with
-        fileservers using the NFSv4 protocol, the NFSv4.1 protocol,
-        or some other file-access protocol. </t>
+        fileservers using a standard file-access protocol. </t>
 
     </section>

         <t> Fileservers are servers that store physical fileset
-        data, or refer file-access clients to other fileservers. A
-        fileserver can be implemented in a number of different ways,
-        including a single system, a cluster of systems, or some other
-        configuration. A fileserver provides access to a federated
-        filesystem via NFSv4, NFSv4.1, or some other file-access
-        protocol. </t>
+        data, or refer file-access clients to other fileservers.
+        A fileserver provides access to its shared filesystem
+        data via a file-access protocol.  A fileserver may be
+        implemented in a number of different ways, including a
+        single system, a cluster of systems, or some other
+        configuration. </t>
 
     </section>
 
@@ -145,11 +145,15 @@
 
         <t> A referral is a mechanism by which a fileserver
         redirects a file-access client to a different
-        fileserver. The exact information contained in a referral
-        varies from one file-access protocol to another. The NFSv4
-        protocol defines the fs_locations attribute for
-        referral information. The NFSv4.1 protocol defines the
-        fs_locations_info attribute for referral information. </t>
+        fileserver or export. The exact information contained in a
+        referral varies from one file-access protocol to another.
+        The NFSv4.0 protocol, for example, defines the fs_locations
+        attribute for returning referral information to NFSv4.0
+        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 <xref target="RFC5661"/>. </t>
 
     </section>
 
@@ -308,9 +312,8 @@
         </t>
 
         <t> This document defines an FSL subtype for NFS. An NFS FSL
-        contains information suitable for use in an NFSv4
-        fs_locations <xref target="3530bis"/> or NFSv4.1
-        fs_locations_info attribute <xref target="RFC5661"/>. </t>
+        contains information suitable for use in one of the NFSv4
+        referral attributes (e.g., fs_locations or fs_locations_info). </t>
 
         <t> A fileset MAY be accessible by protocols other than NFS. For
         each such protocol, a corresponding FSL subtype SHOULD be defined.
@@ -488,8 +491,7 @@
         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 attribute or NFSv4.1 fs_locations_info
-        attribute. </t>
+        fs_locations or fs_locations_info attribute. </t>
 
         <t> To give file-access clients as many options as
         possible, the fileserver SHOULD include the maximum
@@ -503,24 +505,23 @@
         convert or reduce the FSL record's contents in a manner
         appropriate to the referral format. For example,
         an NFS FSL record contains all the data necessary to
-        construct an NFSv4.1 fs_locations_info attribute,
-        but an NFSv4.1 fs_locations_info attribute contains
+        construct an fs_locations_info attribute,
+        but an fs_locations_info attribute contains
         several pieces of information that are not found
-        in an NFSv4 fs_locations attribute. A fileserver
-        will construct entries in an NFSv4 fs_locations
-        attribute using the relevant contents of an NFS FSL
-        record.  </t>
+        in the simpler fs_locations attribute.  A fileserver
+        constructs entries in an fs_locations attribute using
+        the relevant contents of an NFS FSL record.  </t>
 
         <t> Whenever the fileserver converts or reduces
         FSL data, the fileserver SHOULD attempt to maintain
         the original meaning where possible. For example, an
         NFS FSL record contains the rank and order information
-        that is included in an NFSv4.1 fs_locations_info attribute
+        that is included in an fs_locations_info attribute
         (see NFSv4.1's FSLI4BX_READRANK, FSLI4BX_READORDER,
         FSLI4BX_WRITERANK, and FSLI4BX_WRITEORDER). While
         this rank and order information is not explicitly
-        expressible in an NFSv4 fs_locations attribute, the
-        fileserver can arrange the NFSv4 fs_locations
+        expressible in an fs_locations attribute, the
+        fileserver can arrange the fs_locations
         attribute's locations list based on the rank and order
         values.  </t>
 
@@ -606,9 +607,7 @@
         <t> When a file-access client reaches a junction, the
         fileserver refers the client to a list of FSLs associated
         with the FSN targeted by the junction.  The client can then
-        mount one of the associated FSLs.  For NFSv4 and NFSv4.1
-        clients, the FSL information is returned in the fs_locations
-        and fs_locations_info attributes respectively.  </t>
+        mount one of the associated FSLs.  </t>
 
@@ -814,8 +813,8 @@
 
             <t> The fileserver converts one or more of the FSLs to
             the location type used by the file-access client (e.g.,
-            a Network File System (NFSv4) fs_location,
-            as described in <xref target="3530bis"/>).  </t>
+            an NFSv4 fs_location attribute as described in
+            <xref target="RFC5661"/>).  </t>
 
             <t> The fileserver redirects (in whatever manner is
             appropriate for the client) the client to the
@@ -2321,12 +2320,12 @@
         <section title="Selecting fedfsNfsFsl Values">
 
             <t> The fedfsNfsFSl object class is used to describe NFSv4
-            and NFSv4.1 accessible filesets. For the reasons described
+            accessible filesets. For the reasons described
             in <xref target="fsl_referral"/>, administrators SHOULD
             choose reasonable values for all LDAP attributes of an NFSv4
             accessible fedfsNfsFsl even though some of these LDAP
-            attributes are not explicitly contained in the NFSv4
-            fs_locations attribute returned to an NFSv4 client. </t>
+            attributes are not explicitly contained in an NFSv4
+            fs_locations attribute. </t>
 
             <t> When the administrator is unable to choose reasonable
             values for the LDAP attributes not explicitly contained
@@ -2611,13 +2610,13 @@
 
     <section title="Security Considerations">
 
-    <t> Both NFSv4/NFSv4.1 and LDAP provide security mechanisms. When used in
+    <t> Both the NFSv4 and LDAPv3 protocols provide security mechanisms. When used in
     conjunction with the federated filesystem protocols described in
     this document, the use of these mechanisms is RECOMMENDED. Specifically,
     the use of RPCSEC_GSS <xref target="RFC2203"/>, which is built on the
     GSS-API <xref target="RFC2743"/>, is RECOMMENDED on all NFS connections
     between a file-access client and fileserver. The "Security Considerations"
-    sections of the NFSv4 <xref target="3530bis"/> and NFSv4.1 <xref target="RFC5661"/>
+    sections of the NFSv4.0 <xref target="3530bis"/> and NFSv4.1 <xref target="RFC5661"/>
     specifications contain special considerations for the handling of GETATTR
     operations for the fs_locations and fs_locations_info attributes. For all
     LDAP connections established by the federated filesystem protocols, the

---

From: Chuck Lever <[email-masked]>
Date: Tue, 11 Sep 2012 10:08:13 -0400

The glossary definition of a fileset in the NSDB protocol draft is
unclear.  It is easy to assume, from this definition, that a fileset
could be a single file, for instance.

Copy from the definition of an FSL, which is more crisp.
---

 nsdb-proto.xml |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/nsdb-proto.xml b/nsdb-proto.xml
index 2f6a5f8..fa3fc0d 100644
--- a/nsdb-proto.xml
+++ b/nsdb-proto.xml
@@ -188,11 +188,12 @@
 
     <section title="Fileset">
 
-        <t> A fileset is defined to be a container of data and
+        <t> A fileset is loosely defined as a set of files and the
+        directory tree that contains them.  The fileset abstraction
         is the basic unit of data management.  Depending on the
-        configuration, they may be anything between an individual
+        configuration, a fileset may be anything from an individual
         directory of an exported filesystem to an entire exported
-        filesystem at a fileserver. </t>
+        filesystem on a fileserver. </t>
 
     </section>

---

From: Chuck Lever <[email-masked]>
Date: Tue, 11 Sep 2012 10:08:22 -0400

On an NSDB that contains more than one NCE, LDAP does not
automatically protect against FSN UUID collision.  Refine
our description of the FSN UUID collision domain.
---

 nsdb-proto.xml |   16 ++++++++++------
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/nsdb-proto.xml b/nsdb-proto.xml
index fa3fc0d..b526285 100644
--- a/nsdb-proto.xml
+++ b/nsdb-proto.xml
@@ -645,12 +645,16 @@
 
         <t> 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.  The probability of two FSN
-        records sharing the same UUID on a single NSDB host is zero,
-        due to the way FSN distinguished names are formed.  An FSN
-        UUID collision can be detected immediately when an
-        administrator attempts to publish an FSN or FSL by storing
-        it on an appropriate NSDB host.  </t>
+        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.  </t>
+
+        <t> 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.  </t>
 
         <t> 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

---

From: Chuck Lever <[email-masked]>
Date: Tue, 11 Sep 2012 10:08:31 -0400

---

 nsdb-proto.xml |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/nsdb-proto.xml b/nsdb-proto.xml
index b526285..d5a80bb 100644
--- a/nsdb-proto.xml
+++ b/nsdb-proto.xml
@@ -758,8 +758,8 @@
                 fileset locations are unspecified. </t>
 
             <t> For the FSN created above, create an
-                FSL with the appropriate information in
-                the NSDB node. </t>
+                FSL in the NSDB node that describes the
+                physical location of the fileset data.  </t>
 
             </list>
         </t>