Node names contain addressing data that is used when an application on
 one node needs to connect to an application on another named node.
 These names must be unique within the directory service.

 Some directory services support hierarchical naming.  The names at the
 various levels of the hierarchy, except for the lowest level, are
 commonly referred to as "directories".  The names at the lowest level
 identify the specific node within that part of the hierarchy, and
 contain the node's addressing information.  For these directory
 services, it is the entire hierarchical name that must be unique.

1  –  DECdns

 This is a global directory service, where names are assigned within a
 naming hierarchy.  The entire name, including all of its hierarchical
 levels, makes up the "full name".  One possible format for a full name
 is:

   <ns>:.<dir>.<dir>.<node-name>

 Where:

   <ns>:        is the name of the namespace for this naming hierarchy.
                For example, this could represent the organization.

   .<dir>       is some directory name used to break the namespace down
                into smaller, more manageable segments.  For example,
                this could represent an organization, an organizational
                unit, or a location within an organization.  There can
                be as many levels of directory as needed.

   .<node-name> is the terminating name for some node.

 The actual name structure can be defined to suit the name usage of
 the organization.  If the above structure is used, an example of a
 complete full name might be:

   MYCO:.TOPEKA.MYNODE

2  –  Local

 The Local Naming Database uses flat naming, rather than hierarchical
 naming.  Names can consist of any text string.  Because long names are
 allowed, up to 100 characters for any name, a naming hierarchy can be
 simulated by using common name prefixes for related names.

 The Local Naming Database is private to a particular node or cluster.
 As such, it must be manually kept up to date on all nodes if they are
 to share the same set of names.  This can be done by exporting the
 contents of a master copy of the Local Naming Database to a text file,
 copying the text file to other nodes as required, and importing the
 text file into the Local Naming Database for each such node.

 An example of a Local Naming Database name might be:

   TOPEKA.MYNODE

3  –  Phase IV

 The Phase IV Database uses flat naming, rather than hierarchical
 naming.  Names can consist of up to 6 letters (A to Z) and decimal
 digits (0 to 9), with at least one letter.

 The Phase IV Database is private to a particular node or cluster.  As
 such, it must be manually kept up to date on all nodes if they are to
 share the same set of names.  This can be done by exporting the
 contents of a master copy of the Phase IV Database to a text file,
 copying the text file to other nodes as required, and importing the
 text file into the Phase IV Database for each such node.

 An example of a Phase IV Database name might be:

   MYNODE

 The Phase IV Database is supported primarily to allow the simple
 migration from DECnet Phase IV to DECnet-Plus and some other directory
 service.