Re: Root DSA

[[e-mail]]

> Date: 28 Oct 94 22:57:00+0000
> From: [e-mail]
> Message-ID: <"5296 Fri Oct 28 22:03:04 1994"@cs.ucl.ac.uk>
> To: [e-mail]
> Subject: Root DSA
> Importance: Normal
> Reply-To: [e-mail]


What is this [e-mail] ?????

  Am I the only one to receive this buggy Reply-to address?
  If not, please correct this!


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


I will not attend the meeting but here are some comments

-- PAP


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

Important that everyone is really aware of this crucial point!

> 
> (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
> 

1. Whoever manages this context the service has to be "open"
  to any F L dsa manager.

2. I am not sure FTP is needed desirable (to send info to the
  coordination service)

> each master First Level DSA manager every time it is updated. The file

I don't think that the info itsel has to be emailed.
It is enough to notify that a change has occured.

> should also be FTPable on demand by any manager. The file should be ASCII

I would say retrievable (eg. FTP or mail responders)
and particularly by automated tools
  (cf. what exist for mapping and routing info for X.400
  coordination)

> format, similar to configuration lines from the Quipu tailor file (exact
> details to be specified later). 

I understand the pragmatic importance to have the Quipu format
available, but I would suggest to have this in addition to a
commonly accepted format (a textual representation of the knowledge
not tied to any specific implementation).
  The deinition of such a format has been envisaged many times.
  It is a good and important work item for this group,
    and for sake of eficiency I would suggest to limit
    the specification to "knowledge"
  hint: I believe that Nexor and TS-E3X have some commitment to produce
   such a representation, it might be usefull to consider what
   they have prodcued (or are producing)

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

Right this is a supplier issue.

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

About shadowing  (and robustness)
  apart from the official shadowing it is IMHO extremely easy to
  improve the effective robustness today by using the following
  approach/technique/trick (already in use for the French master)
    - you set several physicaly different DSA (on separate
      machines and network attachment)
    - you set up whatever suitable solution to have each of these DSA
      to be a perfect "replication" (I avoid "shadow") of each other,
      same content, same knowledge, same admin limits, same
      chaining/referal policy, same TSEL...
    - you advertise a single PSAP which contains ALL NSAPs
  It is perfectly transparent to "outsiders", it just requires
   that DSA are able to make use of more of one NSAP and in case
   of failure with a given NSAP value another one is tried/used.
   This is no new requirment, just conformance! 
  It gives extremely good results here.

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