Subject: [nfsv4] Proposal for issue 46

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 5 Oct 2006 16:46:58 -0400

This is a proposal based on the presentation that I made at the
interim working group as modified by some of the ensuing discussion.
A pdf of the powerpoint I used is available at 
http://www.nfsv4-editor.org/06interim/files/namespace-noveck.pdf

The proposal is to deal with the requirement for some degree of
namespace non-uniformity within what would otherwise be a uniform
enterprise-wide namespace.  A typical example where a non-uniform
client-specific namespace mapping might be required is for 
"/usr/bin" where clients would like the binaries appropriate
to their particular CPU architecture and OS type and version. 

The proposal would be to address this by specifying within the
returned pathname, variables that are to be substituted for
by the client, to determine the appropriate filesystem pathname,
as described in the following XML section.  In order to allow
us to avoid a nightmare of escapes if we should happen to need
to use filenames which match the variable structure, variable
interpretation is made condition on a flag in the location4_info
structure.

    <section anchor="location4_item" 
             title="The location4_item Structure">
      <t>
        The location4_item structure contains a pathname 
        (in the variable "rootpath") which encodes
        the path of the target filesystem replicas on the set of 
        server designated by the included location4_server entries.
        The precise manner in which in which this target location
        is specified depends on the value of the LIIF_VAR_SUB
        flag within the associated location4_info structure. 
      </t>
      <t>
        If this flag is not set, then rootpath simply designates
        the location of the target filesystem within each server's
        single-server namespace just as it does for the rootpath
        within the fs_location structure.  When this bit is set,
        however, components entries of a certain form are subject
        to client-specific variable substitution so as to allow
        a degree of namespace non-uniformity so as to accommodate
        the selection of client specific filesystem targets to
        accommodate different client architectures or other
        characteristics.
      </t>
      <t>
        When such substitution is in effect a variable beginning
        with the string "${" and ending with the string "}",
        and containing a colon is, to be
        replaced by the client-specific value associated with
        that variable.  The string "unknown" should be used by
        by the client when it has no value for such a variable.
        The pathname resulting from such
        substitutions is used to designate the target filesystem,
        so that different clients may have different filesystems,
        corresponding to that location in the multi-sever namespace.
      </t>
      <t>
        As mentioned above, such substituted pathname variables
        contain a colon.  The part before the colon is to be a
        DNS domain name with the part after being a case-insensitive
        alphanumeric string.
      </t>
      <t>
        Where the domain is "ietf.org", only variable names defined
        in this document or subsequent standards-track RFC's
        are subject to such substitution.  Organizations are
        free to use their domain names to create their own sets
        of client-specific variables, to be subject to such
        substitution.  In case where such variables are intended
        to be used more broadly than a single organization, 
        publication of an informational RFC defining such variables
        is recommended. 
      <t>
        The variable ${ietf.org:CPU_ARCH} is used to denote the
        CPU architecture object files are compiled.  This specification
        does not limit the acceptable values (except that they must be
        valid UTF-8 strings) but such values as "x86", "x86_64" and
"sparc"
        would be expected to be used in line with industry practice.
      </t>
      <t>
        The variable ${ietf.org:OS_TYPE} is used to denote the 
        operating system and thus the kernel and library API's
        for which code might be compiled.  This specification does
        not limit the acceptable values (except that they must be
        valid UTF-8 strings) but such values as "linux" and "freebsd"
        would be expected to be used in line with industry practice.
      </t>
        The variable ${ietf.org:OS_VERSION} is used to denote the 
        operating system version and the thus the specific details
        of versioned interfaces 
        for which code might be compiled.  This specification does
        not limit the acceptable values (except that they must be
        valid UTF-8 strings) but combinations of numbers and 
        letters with interspersed dots would be expected to be used
        in line with industry practice, with the details of the 
        version format depending on the specific value of
        the value of the variable ${ietf.org:OS_TYPE} with which
        it is used.
      </t>
      <t>
        Use of these variable could result in direction of different
        clients to different file systems on the same server, as
        appropriate to particular clients.  In cases in which the
        target filesystems are located on different servers, a single
        server could serve as a referral point so that each valid
        combination of variable values would designate a referral
        hosted on a single server, with the targets of those referrals
on
        a number of different servers.
      </t>
      <t>
        Note that when "rootpath" is a null pathname (that is, one
        with zero components), the file system designated is at the
        root of the specified server, whether the LIIF_VAR_SUB
        flag within the associated location4_info structure is 
        set or not. 
      </t>
    </section>

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Benny Halevy <[email-masked]>
Date: Mon, 09 Oct 2006 16:42:43 +0200

Dave, a couple of minor comments below.

Benny

>         The precise manner in which in which this target location
one too many "in which"s...
>         and containing a colon is, to be
The commas surrounding "and containing a colon is" seem a bit redundant, no?
>         that variable.  
I like this approach.
> The string "unknown" should be used by