Network Working Group S.E. Kille
INTERNET--DRAFT University College London
March 1991
DSA Naming
Status of this Memo
This INTERNET--DRAFT describes a few problems with DSA Naming as
currently deployed in pilot exercises, and suggests a new approach.
This approach is suggested for use in the Internet Directory Pilot.
I believe this note to be an important step forward, as it begins
to evolve a clear model of a Directory Management Domain.
This draft document will be submitted to the RFC editor as a
protocol specification. Distribution of this memo is unlimited.
Please send comments to the author or to the discussion group
<osi-ds@CS.UCL.AC.UK>.
INTERNET--DRAFT DSA Naming March 1991
1 Problem Statement
There are a number of difficulties with the approach being used in
QUIPU based pilots, which is described in the original QUIPU Design
and in the QUIPU documentation. The problems are:
1. It is hard to achieve very high replication of knowledge
information, as this is very widely spread. This is
particularly true of secondary DSAs, which are named inside an
organisation. Due to the sensitivity of sibling information,
replication of this data outside the organisation is less
likely.
2. There is a need to give DSAs more reasonable names. The
current names are too high up the tree to indicate the role of
the DSA. This can lead to management confusion.
3. There is too much DIT clutter --- more endangered South
American animals than organisations!
4. There is no real concept of DMD (Directory Management Domain)
authority. This needs to be introduced, in order to allow DSAs
to be named by the authority that runs them.
The following are good properties of the current approach, which
must not be lost in any changes.
1. The directory should be used to look up the presentation
addresses of DSAs as described in [Kil91] and not require them
to be manually associated with all knowledge references as
implied in X.500.
2. The approach must be deadlock free. This will not be the case
if DSAs named in a careless manner, and 1. is followed.
3. There should be no manual replication of information, which is
implied by the presentation address configuration approach of
the standard.
2 What is a DMD
A DMD is a special type of Organisation, which has two roles.
Kille Page 1
INTERNET--DRAFT DSA Naming March 1991
1. Managing directory configuration information.
2. Operating one or more DSAs (A DSA belongs to the DMD that
operates it)
A common case is for an Organisation (or Organisational Unit) to
operate its own DSAs. In this case the Organisation has a dual
role as both a DMD and an Organisation. Such a DMD is primarily
responsible for operating a number of DSAs, and some minimal
configuration information associated with those DSAs. For most
organisations, the number of DSAs will be small, although a large
organisation may run quite a large number.
Another common case is for for a DMD to be primarily concerned with
managing configuration information between a large number of DSAs,
and perhaps operating a small number of DSAs in order to achieve
this. A research network pilot is an example of such a DMD. Such a
DMD will:
o Collect and distribute configuration information
o Collect and distribute user data (replication)
An Administrative DMD (as distinct from a Private DMD) is one which
systematically maintains knowledge of the root configuration within
the DMD. This will only be a useful distinction if this knowledge
is restricted (it is not in the current pilot environment). For
now it should be assumed that this information is widely
replicated, as adequate performance of the global directory depends
on it.
A DMD may have a peer relationship with other DMDs. There may also
be a hierarchical relationship. This is appropriate for a DMD
which wishes to obtain all of its configuration information and
replicated from a parent DMD. A hierarchical relationship does not
preclude other relationships between DMDs (e.g., to mutually
replicate data).
A DMD has the following responsibilities:
o It must operate at least one DSA, to manage the information
associated with the DMD.
Kille Page 2
INTERNET--DRAFT DSA Naming March 1991
!!!a aa a
! !! ! a aa
! ! !
Root DMD UK AC DMD
! !! !! bb b |
! ! bb Cambrid|ge University
Giant Tortoise UK AC j jjb b
jj j bb bb
Vicuna b
Screeching Cayman Banana Sloth
Figure 1: Example DMD Hierarchy
o It may operate DSAs to store information for Organisations
supported by the DMD. These DSAs are named within the DMD
o Allocate sub-DMDs. The EDB for such a DMD should be mastered
in the DMD DSA
o Manage the replication of knowledge information within the DMD,
and make it available for external replication.
3 Naming DMDs and DSAs
An example is given in Figure 1.
A basic decision is to name DSAs as entries beneath the associated
DMD. DMDs are arranged in a separate hierarchy.
Deadlock due to needing to locate a DSA to determine its own
presentation address is prevented, because of the following
conditions:
o DSAs are named in a separate DMD hierarchy. This groups
configuration information in one area, which will facilitate
replicating it widely.
o For information not in the DMD hierarchy, this separation
prevents deadlock
o Within the DMD hierarchy, special rules apply to prevent
deadlock. This often leads to configuration information being
mastered remotely.
Kille Page 3
INTERNET--DRAFT DSA Naming March 1991
DMDs will be subclasses of Organisation or Organisational Unit (the
latter will be used when the parent of a DMD is another DMD). This
will be defined formally by making the DMD object class subclass of
top, as neither Organisation or Organisational Unit is required.
There is an optional attribute to indicate organisations associated
with the DMD. Object Identifiers will be defined in the COSINE and
Internet Naming Architecture [BK90].
AssociatedOrganisation ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DistinguishedNameSyntax
AssociatedDMD ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DistinguishedNameSyntax
DMD OBJECT-CLASS
SUBCLASS OF top
MAY CONTAIN -associatedOrganisation,
associatedDMD"
There will be a number of top level DMDs. In the longer term,
there will be a small number of nationally allocated DMDs, probably
allocated under the country level. This will lead to many DMD
trees, and not just one. This will raise more problems for the
support of multinational organisation. For now, we will avoid this
complexity, and resist the temptation to introduce it too early.
To avoid deadlock in looking up DSAs, the DSA which masters an
Entry Data Block (as defined in [Kil91]) should have a name which
has the same number of components as or less components than the
EDB name, or the DSA should be in the Root DMD.
There will be a special top level DMD, with the name ``Root DMD''.
This DMD will contain the names of DSAs which master top level
DMDs. The well known DSA: ``Giant Tortoise, Root DMD'' will hold
the master EDBs for the root and for ``Root DMD''. This will allow
a way in to the system, in the same manner as at present.
Typical top level DMDs will correspond to national pilots. That
is, there will be a small number for each country. For example:
``Internet Pilot DMD'; ``UK AC Pilot DMD''; ``Paradise DMD''. Each
node of the DIT, and in particular each country, will need to be
mastered by a single DMD(1).
___________________________
(1)The introduction of real NSSRs would be a way around this, but
there would need to be significant additional machinery in place.
Kille Page 4
INTERNET--DRAFT DSA Naming March 1991
Where a DMD allocates (a large number) of sub-DMDs, it is important
that this is done in a separate branch of the tree(2). Such a DMD
will have two entries in the DIT. The part of the tree which
contains the DSAs will either be a sub-DMD of the root DMD or have
the string DSAs at the end. The two parts of the DMD will be
linked by the AssociatedDMD Attribute. For top level DMDs, the
part of the DMD which names its DSAs should be under the Root DMD.
An example use of the hierarchy might be to name a DSA:
Screeching Cayman, Cambridge University DMD,
UK AC Pilot DMD
Note that although DMDs are named hierarchically, individual DMDs
are autonomous. The naming of DSAs within a DMD is up to the DMD.
The QUIPU guideline of using South American Wildlife will remain
(for the QUIPU implementation), but this may be inappropriate for
some DMDs.
In many cases, there will be a 1:1 mapping between an Organisation
and DMD. In this case, it is recommended that the DMD is named by
appending DMD to the organisation name if it is a top level DMD or
by using the organisation name if it is a sub-DMD.
References
[BK90] P. Barker and S.E. Kille. The COSINE and Internet X.500
naming architecture, December 1990. Internet Draft:
draft-ietf-osids-cosinex500-02.txt.
[Kil91] S.E. Kille. Replication requirement to provide an internet
directory using X.500, January 1991. Internet Draft:
draft-ietf-osids-replsoln-01.txt, ps.
___________________________
(2)This is so
that a DMD can manage is own sub-DMDs in one of its own DSAs. This
separation is forced by the approach taken to replication. Another
consequence is that a DMDs (usually small number of) DSAs will have
their entries mastered in the DSA of another DMD. They will still
be managed by the DMD which owns them.
Kille Page 5
INTERNET--DRAFT DSA Naming March 1991
4 Security Considerations
Security issues are not considered in this INTERNET--DRAFT .
5 Author's Address
Steve Kille
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK
Kille Page 6