Phasing out/opening up the root DSA

[[e-mail]]

Here is a revised version of the previous document, after taking into account
all the comments that were received. Further comments welcome.
David


                       Phasing Out/Opening Up The Root DSA


Background Information

1. The Root DSA is not a feature of the X.500 standard. It was
introduced because of the non-standard nature of the original
Quipu knowledge model (described in RFC 1276 [1]).

2. The X.500 standard [3] recognises First Level DSAs as being
the DSAs at the 'top' of the X.500 hierarchy. First Level DSAs
are DSAs that hold an entry immediately subordinate to the
root entry. 

3. The 1993 edition of the standard explicitly recognises that
there can be master and shadow First Level DSAs. (The 1988
edition of the standard does not explicitly recognise this,
since it does not recognise shadowing.) A shadow First Level
DSA holds a copy of the root context, provided by a master
First Level DSA.

4. There is some confusion over the exact definition of the
'root context' as specified in the 1988 standard. Root naming
context is also mentioned. For the purpose of this paper, root
context and root naming context will be taken to be synonymous
terms, and will be defined as:

      the root entry and the complete set of subordinate
      references of the root entry.

In line with accepted practice, (e.g. functional standards and
NADF documentation) NSSRs will not be allowed in the root
context. To allow them will cause great inefficiencies in name
resolution.

(Note that whether a particular DSA holds a root subordinate
reference as a subordinate reference or as a cross reference
is largely immaterial to this paper and to the external
world.)

5. In the current Paradise service, the root context is very
small, less than 50 subordinate references. In other words
there are less than 50 country and top level locality and
organisational entries. It can be expected to remain this
small for the next few years, at least until 1993 products
come on stream. Furthermore, changes to the root context
information happen relatively infrequently. We are thus not
talking about a large data management issue, since each
subordinate reference only consists of 3 pieces of
information: the distinguished name of the first level entry,
the distinguished name of its master DSA, and the later's
presentation address. It is also possible, as an aid to
performance, and to build in redundancy, to hold the access
points of shadow DSAs along with that of the master DSA, but
this is only expected to cause at most a trebling of the root
context information.


Requirements

6. Different organisations have different requirements from
the root DSA (or the removal of it). However, the following
points seem to have common consensus amongst all the Internet
respondents to the initial draft of this paper:

      i) the root of the Paradise DIT needs to be 'open', so
      that any implementation can easily act as a First Level
      DSA;

      ii) it would be advantageous to define the root context
      in an open manner, so that electronic transmission of the
      root context, by any implementation, becomes possible;

      iii) the existing root DSA should not be used for name
      resolution of queries as it would be a bottleneck;

      iv) the existing root DSA serves the very useful purpose
      of distributing top level knowledge and data amongst
      Quipu DSAs, and this should not be lost in the short
      term, and it may be desirable to keep it in the longer
      term.


Proposed Transition Plan

7. The proposed transition plan has two phases. Phase one
opens up the root context so that any implementation can
easily act as a First Level DSA. Quipu DSAs will still be able
to use the existing root DSA as a source of first level
knowledge information, but should stop using it for name
resolution. Phase two replaces the existing root DSA by a 1993
conformant DSA, so that automatic replication of the root
context is enabled for all First Level DSA implementations.

Phase One

8. Each First Level DSA administrator is encouraged to
register (and update) his/her first level information with the
European root context administrator, by using either Email,
FTP or phone or fax. (There is no charge for this.) An
organisation such as DANTE can act as the European root
context administrator. The root context administrator will
then charge organisations an appropriate fee for retrieval of
the root context information. (An appropriate fee may in fact
be nothing.)

9. The root context is defined in ASN.1 (see Appendix 1) using
the '93 definitions for shadowing and subordinate references.
This information is made available on a file server so that
First Level DSA administrators can retrieve it on demand via
FTP or a mail responder. The root context administrator could
also offer an 'on change' service, whereby updates are
automatically forwarded to First Level Administrators as soon
as they arrive. An appropriate textual representation of this
information will need to be defined, based on existing texts
such as 'A string encoding of presentation addresses'.

The only special software that may be needed is a bulk loading
tool to load the root context information into each First
Level DSA (although this should be provided by the
manufacturer as part of their product range).

10. The Quipu root DSA will still exist alongside the file
version of the root context, but the Quipu root DSA should be
regarded as holding a copy of the file based information. (In
fact, the Quipu DSA may only be capable of holding a subset of
the file based information if its knowledge model is not
comprehensive enough to hold the complete set of information
given in Appendix 1. Note - this still needs to be determined
by Quipu experts.) 

11. Quipu DSAs have the following problems to solve:

      - they want to automatically obtain the root context
      information from the root DSA,

      - they do not want to route queries via the root DSA,

      - they need to inter-work with other implementations.

The author is unclear as to why a Quipu First Level DSA needs
to route queries via the root DSA just because it obtains its
root EDB file from the root DSA (as suggested by S.Kille).
Once it has a copy of the root EDB file, it knows the country
entries, and has master references to subordinates of each
country entry. So it should not need to use the root DSA for
name resolution, should it?

However, if each First Level Quipu DSA says (incorrectly) that
it holds the MASTER copy of the root EDB file, then it should
never need to contact the root DSA at all. Whenever one of
these DSAs needs to update its root EDB file, it can switch
the configuration back to SLAVE, and obtain an update from the
root DSA.

The OIFP reports [2] document various interworking problems,
and it is understood that Nexor (at least) have solved these
problems e.g. by allowing Quipu DSAs to hold standard
subordinate references to other DSA implementations.

12. Non-Quipu DSAs have the following problems to solve:

      - how to get hold of the root context information

      - how to participate in name resolution at the top of the
      DIT, without behaving in a non-standard Quipu manner.

The file version of the root context should solve the former
problem. Various aspects of the latter problem are documented
in the OIFP reports [2], and Nexor (at least) are reported to
have solved them with their Quipu implementation derivative.

13. Shadow First Level DSAs will make their own bilateral
arrangements for copying information from master First Level
DSAs. In the short term this might be by proprietary
replication protocols, and in the longer term by 1993 standard
replication protocol. How this is achieved is outside the
scope of this paper.

14. The European root context administrator will be
responsible for sharing information with the US (NADF in
particular), and with other similar points in Europe (if these
exist) such as Eurescom. Individual First Level DSA managers
do not need to worry about this, since this information will
be given to them automatically by the European root context
administrator.

Phase Two

15. In the longer term we can expect to see 1993 conformant
systems that support the standard shadowing and operational
binding protocols. It is hoped that the following scheme can
be supported by 1993 standard conformant systems. It is
similar to the NADF CAN scheme, but is based on the standard
1993 replication protocols, the DOP and the DISP, instead of
on a proprietary intercept protocol.

16. The European coordinating point can operate a (pseudo)
root DSA that enters into two bilateral agreements with every
master First Level DSA. One of these agreements will be a
shadowing agreement, the other a hierarchical agreement. 

17. The root DSA will enter into a hierarchical agreement with
every master First Level DSA, in order to obtain a subordinate
reference for each first level entry. Whilst hierarchical
agreements are standardised, this particular novel use of a
HOB is not specifically recognised in the standard so it may
cause hiccups with some implementations, although the ASN.1
will support it. 

(Note. If this HOB proves difficult to support in some
implementations, then it would be possible to continue to use
the previous manual method for updating the subordinate
references in the root DSA. For those implementations that do
not initially support the HOB, manual updates will need to
continue to be used. It will be quite acceptable for some
First Level DSAs to use HOBs and some to use manual methods.)

18. Every master First Level DSA will shadow the root context
from the pseudo root DSA. This will provide the complete set
of subordinate references. This is the shadowing agreement,
and should be completely standard (otherwise shadow First
Level DSAs could not be supported by the implementation). 

(Note. On talking to one manufacturer, the expert suggested
that a defect report might be needed to the standard to ensure
that this is the case. If so this will be done.)

The Update strategy should preferably be set to 'on change'
and will be supplier initiated, although the exact strategy
adopted by any one First Level DSA manager does not affect the
overall scheme of things.

19. When any of the master First Level DSAs change their
access points (names or addresses), they can notify the root
DSA via the DOP Modify Operational Binding message. Changes to
shadow access points and the name of the first level entries
will similarly be notified. The root DSA can subsequently
notify all the master First Level DSAs of all such changes via
the DISP. In this way it should be possible to propagate
changes from a First Level DSA to the root DSA, and from there
to all other First Level DSAs.
 
20. An alternative solution, which is much less manageable,
but that does without a pseudo root DSA, is for each master
First Level DSA to enter into bilateral agreements with every
other master First Level DSA, in order to shadow the first
level entries and access point operational attributes.
However, this solution is not seriously proposed, as the
management overheads are too great.

                                                                     D W Chadwic
k
                                                                 20 November 199
4

References

[1] Value X.500 Operational Interworking Forum and Platform,
Final Technical Report, INRIA, April 1994.

[2] Replication and Distributed Operations extensions to
provide an Internet Directory using X.500, S.E. Hardcastle-
Kille, RFC 1276, Nov 1991.

[3] The Directory, ISO/IEC 9594, ITU-T Recommendation X.500
(Edition 1 1989, Edition 2 1994)
Appendix 1. ASN.1 for the Root Context

The information that needs to be stored is the RDN of each
first level entry, and the master and shadow access points of
the DSAs that hold each of them.

The following ASN.1 is derived from the total refresh option
of the Update Shadow request (section 11.3.1.1 of X.525), plus
the specific knowledge attribute (section 20.2.1.3 of X.501).
All the optional elements have been removed, so that the ASN.1
is an exact subset of shadowed information.


RootContext               ::= SEQUENCE {

subordinates              SET OF SEQUENCE {

rdn                       RelativeDistinguishedName,
                          SEQUENCE {
sDSEType                  BITSTRING {(5)}, -- only subr is set
attributeComplete               [1]    BOOLEAN, -- must be set to FALSE
Attributes                      SET OF SEQUENCE {
knowledgeAttributeType          OBJECT IDENTIFIER, -- set to 2 5 12 3
knowledgeAttributeValue         SET OF SET OF SET {
-- first SET OF is for multi-valued attributes
-- second SET OF is for master and shadow access points
      dsaName                   [0] Name,
      presentationAddress       [1] PresentationAddress,
      protocolInformation       [2] SET OF SEQUENCE {
             nAddress             OCTET STRING,
             profiles             SET OF OBJECT IDENTIFIER} OPTIONAL,
      category                  [3] ENUMERATED {
             master                    (0),
             shadow                    (1) } } }
                          } } }