[Federated-fs] Diffs for latest reqts draft

[Ellard, Daniel]

As suggested during the conf call, here are the diffs (for the XML
source, unfortunately) between the most recently posted draft and the
prior version.

< is the old version

> is the newer version


Requirement 1 has the first set of changes, but the context overlaps
with requirement 2, so I'm using the comment <<REQUIREMENT 2>> to note
the transition.

-Dan

***************
*** 677,789 ****
  		</t>
  	    </list>
  	</t>
      </section>
  
      <section title="Requirements">
  
  	<t>
  	    <list style="format R%d:">
  
! 		<t> USING THE FEDERATION INTERFACES, and given an FSL,
! 		    it MUST be possible for an entity to discover,
! 		    from the server specified in the FSL, the globally
! 		    unique and platform-independent name (FSN) of the
! 		    fileset, if any, associated with that FSL at that
! 		    time.
  
  		    <list style="format %c.">
  
  			<t> Each FSN MUST be globally unique.  </t>
  
  			<t> The FSN MUST be sufficiently descriptive
  			    to locate an instance of the fileset it
  			    names within the federation at any time. 
  			    </t>
  
! 			<t> The FSN is the name of the fileset, not
! 			    the FSLs. 
  
  			    <list style="symbols">
  
  				<t> If a fileset instance is moved to
  				    a new location, it will have a new
! 				    FSL but the same FSN in the new
! 				    location.  </t>
  
! 				<t> If an instance of a different
! 				    fileset is placed at the old
! 				    location, and that fileset has an
! 				    FSN, then the FSL will be
! 				    associated with a different FSN
! 				    from the previous.  </t>
  
  			    </list> </t>
  
! 			<t> If a FSL is migrated to another server
! 			    using the federation interfaces, the FSN
! 			    remains the same in the new location. 
! 			    </t>
  
  			<t> If the fileset is replicated using the
  			    federation interfaces, then all of the
  			    replicas have the same FSN.  </t>
  
  		    </list>
  
  		    Not all filesets in the federation are required to
  		    have a FSN or be reachable by a FSL.  Only those
  		    filesets that are the target of a junction (as
  		    described in R3) are required to have an FSN.
  
  		    <vspace blankLines="1" />
  
  		    NOTE:  this requirement has been called into
  		    question.
  
  		</t>

<<REQUIREMENT 2>>
  
  		<t> USING THE FEDERATION INTERFACES, it MUST be
! 		    possible to "promote" a fileset exported by a
! 		    federation server to become an FSL, and bind that
! 		    FSL to a FSN.
  
  		    <vspace blankLines="1" />
  
! 		    The presumption is that the local administrator of
! 		    a server performs this process by creating a local
! 		    fileset and then makes this fileset accessible to
! 		    the federation via an FSL, and create a mapping to
! 		    this FSL from a new or existing FSN.  It MAY also
! 		    be possible to create an fileset, assign it an
! 		    FSL, and add a binding from an FSN to that FSL,
! 		    all a single operation, but to an external
! 		    observer this is indistinguishable from the
! 		    "promotion" of a local fileset.
  
  		    <vspace blankLines="1" />
  
! 		    Note that it is the responsibility of the entity
! 		    performing the promotion to ensure that the
! 		    fileset can, indeed, be used as an FSL (and remove
! 		    the mapping from the FSN to this FSL if or when
! 		    this becomes untrue).
  
  		    <list style="format %c.">
  
- 			<t> USING THE FEDERATION INTERFACES, the
- 			    administrator MUST specify the identity of
- 			    the NSDB node responsible for managing the
- 			    mappings between the FSN and the FSL
- 			    before the FSL can be bound to a FSN. 
- 			    </t>
- 
  			<t> An administrator MAY specify the entire
  			    FSN (including both the NSDB node location
  			    and the junction key) of the newly-created
  			    FSL, or the administrator MAY specify only
  			    the NSDB node and have the system choose
  			    the junction key.
  
  			    <vspace blankLines="1" />
  
  			    The admin can choose to specify the FSN
--- 677,791 ----
  		</t>
  	    </list>
  	</t>
      </section>
  
      <section title="Requirements">
  
  	<t>
  	    <list style="format R%d:">
  
! 		<t> Requirements of each FSN:
  
  		    <list style="format %c.">
  
  			<t> Each FSN MUST be globally unique.  </t>
  
  			<t> The FSN MUST be sufficiently descriptive
  			    to locate an instance of the fileset it
  			    names within the federation at any time. 
  			    </t>
  
! 			<t> An FSN is a name of a fileset.  (An FSL is
! 			    not the name of a fileset, but only a
! 			    locator of an instance of a fileset at
! 			    some point in time.  For example, the same
! 			    FSL may implement different filesets at
! 			    different times.)
  
  			    <list style="symbols">
  
  				<t> If a fileset instance is moved to
  				    a new location, it will have a new
! 				    FSL, but its FSN is unchanged. 
! 				    </t>
  
! 				<t> An instance of a different fileset
! 				    may be placed at a FSL previously
! 				    occupied by an instance of a
! 				    different fileset.  </t>
  
  			    </list> </t>
  
! 			<t> If a fileset instance is migrated to
! 			    another location, the FSN remains the same
! 			    in the new location.  </t>
  
  			<t> If the fileset is replicated using the
  			    federation interfaces, then all of the
  			    replicas have the same FSN.  </t>
  
  		    </list>
  
  		    Not all filesets in the federation are required to
  		    have a FSN or be reachable by a FSL.  Only those
  		    filesets that are the target of a junction (as
  		    described in R3) are required to have an FSN.
  
  		    <vspace blankLines="1" />
  
  		    NOTE:  this requirement has been called into
  		    question.
  
  		</t>

<<REQUIREMENT 2>>
  
  		<t> USING THE FEDERATION INTERFACES, it MUST be
! 		    possible to create an FSN for a fileset, and
! 		    it must be possible to bind an FSL to that FSN.
! 		    These operations are NSDB operations and do
! 		    not require any action on the part of an NFS
! 		    server.
  
  		    <vspace blankLines="1" />
  
! 		    It is possible to create an FSN for a fileset that
! 		    has not actually been created.  It is also
! 		    possible to bind a nonexistant FSL to an FSN.  It
! 		    is also possible to create a fileset without
! 		    assigning it an FSN.  The binding between an FSN
! 		    and an FSL is defined entirely within the context
! 		    of the NSDB; the servers do not "know" whether the
! 		    filesets they host have been assigned FSNs (or, if
! 		    so, what those FSNs are).
  
  		    <vspace blankLines="1" />
  
! 		    The requirement that filesets can exist prior to
being
! 		    assigned an FSN, and the requirement that FSNs can
exist
! 		    independent of filesets are intended to simplify
! 		    the construction of the namespace in a convenient
! 		    manner.  For example, they permit an admin to
! 		    assign FSNs to existing filesets and thereby
incorporate
! 		    existing filesets into the namespace.  They also
! 		    permit the structure of the namespace to be defined
! 		    prior to creation of the component filesets.
! 		    In either case, 
! 		    it is the responsibility of the entity
! 		    updating the NSDB with FSNs and FSN-to-FSL mappings
! 		    to ensure that the namespace is constructed in
! 		    a consistent manner.  (The simplest way to
accomplish
! 		    this is to ensure that the FSN and FSN-to-FSL
mappings
! 		    are always recorded in the NSDB prior to the
creation
! 		    of any junctions that refer to that FSN.)
  
  		    <list style="format %c.">
  
  			<t> An administrator MAY specify the entire
  			    FSN (including both the NSDB node location
  			    and the junction key) of the newly-created
  			    FSL, or the administrator MAY specify only
  			    the NSDB node and have the system choose
  			    the junction key.
  
  			    <vspace blankLines="1" />
  
  			    The admin can choose to specify the FSN
***************
*** 932,983 ****
  		    -- it only changes the mappings from FSNs to FSLs on
  		    the NSDB.
  
  		</t>
  
  		<t> It MUST be possible for the federation of servers to
  		    provide multiple namespaces.  </t>
  
  		<t> USING THE FEDERATION INTERFACES, it MUST be possible
  		    to perform queries about the state of objects
relevant
! 		    to the implementation of the federation namespace:
! 
! 		    <list style="format %c.">
  
! 			<t> It SHOULD be possible to query a fileserver
to
! 			    get a list of exported filesets and the
export
! 			    paths.
! 
! 			    <vspace blankLines="1" />
! 
! 			    This information is necessary to bootstrap
the
! 			    namespace construction.
! 			    
! 			</t>
! 
! 			<t> It MUST be possible to query the fileserver
! 			    named in a FSL to get attributes, such as
the
! 			    appropriate mount options, for the
underlying
! 			    filesystem for that FSL.
! 
! 			    <vspace blankLines="1" />
! 
! 			    This information is necessary for the
! 			    client to properly access the FSL.
! 
! 			</t>
  
! 			<t> It MUST be possible to query the fileserver
! 			    named in an FSL to discover whether a
junction
! 			    exists at a given path within that FSL.
</t>
  
- 		    </list>
  		</t>
  
  		<t> The projected namespace (and the objects named by
the
  		    namespace) MUST be accessible to clients via at
least
  		    one standard filesystem access protocol.
  
  		    <list style="format %c.">
  
  			<t> The namespace SHOULD be accessible to
clients
  			    via the CIFS protocol.  </t>
--- 934,961 ----
  		    -- it only changes the mappings from FSNs to FSLs on
  		    the NSDB.
  
  		</t>
  
  		<t> It MUST be possible for the federation of servers to
  		    provide multiple namespaces.  </t>
  
  		<t> USING THE FEDERATION INTERFACES, it MUST be possible
  		    to perform queries about the state of objects
relevant
! 		    to the implementation of the federation namespace.
  
! 		    <vspace blankLines="1" />
  
! 		    It MUST be possible to query the fileserver
! 		    named in an FSL to discover whether a junction
! 		    exists at a given path within that FSL.
  
  		</t>
  
  		<t> The projected namespace (and the objects named by
the
  		    namespace) MUST be accessible to clients via at
least
  		    one standard filesystem access protocol.
  
  		    <list style="format %c.">
  
  			<t> The namespace SHOULD be accessible to
clients
  			    via the CIFS protocol.  </t>