Root DSA

[[e-mail]]

Folks

Here is a draft proposal for the upcoming DANTE Nameflow meeting in Holland.

Comments appreciated, so that I can update it if needs be before then

David

                   Phasing Out 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.

2. The X.500 standard 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.


Proposed Transition Plan

6. The first phase is to ensure that ALL First Level DSAs are based on
implementations (Quipu or otherwise) that can hold subordinate references
that are conformant to the standard. Until this is achieved the root DSA
will continue to be necessary.

(Note. If one or more of the First Level DSAs are capable of holding cross
references instead of subordinate references, this should be sufficient.)

7. Once this has been achieved each master First Level DSA can be
configured with the root context, i.e. a full set of subordinate
references, and the root DSA can then be discontinued (since calls will no
longer need to be routed via it).

8. The next question to arise, is how is the root context to be managed and
distributed. Two alternative solution are proposed, one for the short term
(May 1995 for one or two years) and one for the longer term. In neither
case is it proposed that any special software need be implemented.

9. Given that the root context data management requirements are small, in
the short term it will be cheapest and easiest to have a human controlled
central coordinating point. (DANTE are probably the most suitable
organisation in Europe to offer this service.) The coordinating person will
receive subordinate reference details from all master First Level DSA
managers, either by Email, FTP or phone or fax, and will keep this
information in a computer file. This file can then be Emailed or FTPed to
each master First Level DSA manager every time it is updated. The file
should also be FTPable on demand by any manager. The file should be ASCII
format, similar to configuration lines from the Quipu tailor file (exact
details to be specified later). 

There would seem to be little point in specifying and procuring custom
built software for this purpose, given that 1993 conformant systems,
supporting shadowing, will be available within the next year or two. The
only 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).

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.

The European coordinating point 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 coordinating point.

10. 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.

11. 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. 

12. Every master First Level DSA will shadow the root context from the 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 manufacterer, 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.

13. 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, and to only use the
standard shadowing protocol for propagating the changes to the other First
Level DSAs. 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.)

14. 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.
 
15. 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 Chadwick
                                                28 October 1994