--- 1/draft-ietf-nfsv4-federated-fs-reqts-02.txt	2009-05-18 17:12:06.000000000 +0200
+++ 2/draft-ietf-nfsv4-federated-fs-reqts-03.txt	2009-05-18 17:12:06.000000000 +0200
@@ -1,23 +1,23 @@
 
 NFSv4 Working Group                                           J. Lentini
 Internet-Draft                                               C. Everhart
 Intended status: Informational                                    NetApp
-Expires: October 22, 2009                                      D. Ellard
+Expires: November 19, 2009                                     D. Ellard
                                                         BBN Technologies
                                                                R. Tewari
                                                                  M. Naik
                                                              IBM Almaden
-                                                          April 20, 2009
+                                                            May 18, 2009
 
                 Requirements for Federated File Systems
-                 draft-ietf-nfsv4-federated-fs-reqts-02
+                 draft-ietf-nfsv4-federated-fs-reqts-03
 
 Status of this Memo
 
    This Internet-Draft is submitted to IETF in full conformance with the
    provisions of BCP 78 and BCP 79.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.
@@ -26,21 +26,21 @@
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on October 22, 2009.
+   This Internet-Draft will expire on November 19, 2009.
 
 Copyright Notice
 
    Copyright (c) 2009 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents in effect on the date of
    publication of this document (http://trustee.ietf.org/license-info).
    Please review these documents carefully, as they describe your rights
@@ -120,21 +120,21 @@
    that can be used to look up the location information.  The service
    that can be used to map from FSN to FSL(s) is called a namespace
    database (NSDB) service.  The NSDB provides a level of indirection
    from the virtual paths in the uniform namespace to the actual
    locations of files.
 
    The servers direct clients to the proper locations by existing
    mechanisms (e.g. the referrals mechanism within [RFC3530] and
    [NFSv4.1]).  Updates to the locations make it possible to support
    migration and replication of physical filesystems that comprise the
-   namespace, in a way that is transparent to filesystem clients.
+   namespace, in a way that is transparent to filesystem applications.
 
    Figure 1 shows an example of a federation.  This federation has two
    members, named ALPHA and BETA.  Federation members may contain an
    arbitrary number of file servers and NSDB nodes; in this illustration
    ALPHA and BETA each have three servers and one NSDB node.
 
       +----------------------+       +----------------------+
       |  Federation Member   |       |  Federation Member   |
       |        ALPHA         |       |         BETA         |
       |                      |       |                      |
@@ -345,36 +345,35 @@
       |   |   Server X    |   |      |   |   Server Y    |   |
       |   |               |   |      |   |               |   |
       |   +---------------+   |      |   +---------------+   |
       |                       |      |                       |
       +-----------------------+      +-----------------------+
 
                                  Figure 2
 
 4.3.  Junction Creation
 
-   Given a local path, a remote export and a path relative to that
-   export, create a junction from the local path to the path within the
-   remote export.
+   Given a local path and the FSN of a remote fileset, an administrator
+   can create a junction from the local path to the remote fileset.
 
    There are many possible variations to this procedure, depending on
    how the junctions are represented and how the information necessary
    to perform resolution is represented by the server.
 
    Step 1 is the only step that uses the federation interfaces.  The
-   rest of the steps may use platform-specific interfaces.
+   remaining step may use platform-specific interfaces.
 
-   1.  Contact the server named by the export and ask for the FSN for
-       the fileset, given its path relative to that export.
+   1.  The administrator requests the server create a junction to the
+       FSN of the remote fileset at the given path.
 
-   2.  Insert the junction to the FSN, at the given path, into the local
-       filesystem.
+   2.  The server inserts the junction to the FSN, at the given path,
+       into the local filesystem.
 
 5.  Glossary
 
    Administrator:  user with the necessary authority to initiate
       administrative tasks on one or more servers.
 
    Admin entity:  A server or agent that administers a collection of
       fileservers and persistently stores the namespace information.
 
    Client:  Any client that accesses the fileserver data using a