Managing the root context

[[e-mail]]

Below is the paper that I presented at the Nameflow-Paradise meeting the other
week. I am still to edit it before circulating it to the IDS list, by adding a
method based totally on shadowing instead of DOP and DISP. But seeing as some
people were interested in the current version, here it is
David

IDS Working Group                             David Chadwick
Request for Comments: nn                      University of Salford
Category: Standards Track                     Sept 16 1995
                                              Expires: yesterday!


                 Managing the X.500 Root Naming Context


Status of this Memo

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet Official
Protocol Standards" for the standardisation state and status of this
protocol. Distribution of this memo is unlimited.


Abstact

The X.500 Standard [X.500 93] has the concept of first level DSAs, whose
administrators must collectively manage the root naming context through bi-
lateral agreements or other private means which are outside the scope of
the Standard.

The Paradise-Nameflow X.500 service has an established procedure for
managing the root naming context, which currently uses Quipu proprietary
replication mechanisms and a root DSA. The benefits that derive from this
are twofold:

      - firstly it is much easier to co-ordinate the management of the root
      context information, when there is a central point of administration,

      - secondly the performance of one-level Search operations is greatly
      improved because the Quipu distribution and replication mechanism
      does not have a restriction that exists in the 1988 and 1993
      Standard.

The Paradise-Nameflow project is moving towards 1993 Standard replication
protocols and wants to standardise the protocol and procedure for managing
the root naming context which will be based on 1993 Standard protocols.
Such a protocol and procedure will be useful to private X.500 domains as
well as to the Internet X.500 public domain. It is imperative that overall
system performance is not degraded by this transistion.

This document describes the use of 1993 Standard protocols for managing the
root context. Whilst the ASN.1 is compatible with that of the Standard, the
actual settings of the parameters are supplementary to that of the
Standard.


Table of Contents

1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . .  2

2 Migration Plan. . . . . . . . . . . . . . . . . . . . . . . . . . .  2

3 Technical Solution. . . . . . . . . . . . . . . . . . . . . . . . .  2

4 Security Considerations . . . . . . . . . . . . . . . . . . . . . .  4

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4

Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . . .  4

Annex 1 Solution Text of Defect Reports submitted to ISO/ITU-T by the
      UK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5

1 Introduction

The Paradise-Nameflow service has a novel way of managing the set of first
level DSAs and the root naming context. There is a single root DSA (Giant
Tortoise) which holds all of the country entries, and the country entries
are then replicated to every country (first level) DSA by Quipu replication
[RFC 1276] from the root DSA. The root DSA is not a feature of the X.500
Standard [X.500 93]. It was introduced because of the non-standard nature
of the original Quipu knowledge model (also described in RFC 1276).
However, it does have significant advantages both in managing the root
naming context and in the performance of one-level Searches of the root.
Performance is increased because each country DSA holds all the entry
information of every country. 

By comparison, the 1988 Standard root context which is replicated to all
the country DSAs, only holds knowledge information and a boolean (to say if
the entry is an alias or not) for each country entry. This is sufficient to
perform a List operation, but not a one-level Search operation. When access
controls were added to the 1993 Standard, the root context information was
increased (erroneously as it happens - this is the subject of defect report
140 - see Annex 1) to hold the access controls for each country entry, but
a note in the Standard restricted its use to the List operation, in order
to remain compatible with the 1988 edition of the Standard.


2 Migration Plan

The Paradise-Nameflow service is now migrating to 1993 Standard [X.500 93]
conforming products, and it is essential to replace the Quipu replication
protocol with the 1993 shadowing and operational binding protocols, but
without losing the performance impovement that has been gained for one-
level Searches.

It is still the intention of the Paradise-Nameflow service to have one
master root DSA, and for each country (first level) DSA to shadow the root
context from the root DSA. Each first level DSA then only needs to have one
bi-lateral agreement, between itself and the root DSA. This agreement
ensures that the first level DSA keeps the root DSA up to date with its
country level information, and in turn, the root DSA keeps the first level
DSA up to date with the complete root naming context. When a new first
level DSA comes on line, it only needs to establish a bi-lateral agreement
with the root DSA, in order to obtain the complete root context.

This is a much easier configuration to manage than simply a set of first
level DSAs without a root DSA, as suggested in the Standard. In this case
each first level DSA must have bi-lateral agreements with all of the other
first level DSAs. When a new first level DSA comes on line, it must
establish agreements with all the existing first level DSAs. As the number
of first level DSAs grows, the process becomes unmanageable.

However, it is also important to increase the amount of information that is
held about every country entry, so that a one-level Search operation can be
performed in each first level DSA, without it needing to chain or refer the
operation to all the other first level DSAs (as is currently the case with
a Standard conformant system.)


3 Technical Solution

3.1 The solution is three-fold. Firstly, create a root DSA, using
hierarchical operational bindings between it and each master first level
DSA (3.2). Secondly, the Standard is enhanced to allow extra information to
be carried to the root DSA via the HOB, and for this information to be used
for one-level Search operations (3.3). Thirdly, each master first level DSA
enters into a shadowing agreement with the root DSA, to shadow the enlarged
root context information. In this way each first level DSA is then capable
of independently performing List and one-level Search operations, and name
resolving to all other first level DSAs (3.4).

(Note. It is strongly recommended that non-specific subordinate references
should not be allowed in the root context for efficiency reasons. This is
directed by the European functional standard [ENV 41215] and the NADF
standing document [NADF 7]. It is also preferred by the International
Standardized Profile [ISP 10615-6].)


3.2 Each master first level DSA will have a hierarchical operational
binding with the root DSA of the domain. Each master first level DSA will
master one or more first level entries. The hierarchical operational
binding will keep the appropriate subordinate reference(s) (of catagory
shadow and master) up to date, as well as the other entry information that
is needed for one-level Search operations (such as access controls, and
attributes used in filtering).

Whilst hierarchical agreements are standardised, this particular novel use
of a HOB is not specifically recognised in the Standard. Although the ASN.1
will support it, there is no supporting text in the Standard. The following
text supplements that in the Standard, and describes how a first level DSA
may have a hierarchical operational binding with the root DSA of its
domain.

"Clause 24 of ISO/IEC 9594-4:1993 shall also apply when a first level DSA
is a subordinate DSA, and the root DSA of the domain is the superior DSA.
The naming context held by the superior (root) DSA is the root naming
context (or root context - the terms are synonymous) of the domain. The
root context consists of the root entry of the DIT (which is empty) plus a
complete set of subordinate DSEs, one for each first level naming context
in the domain. The subordinate DSEs will contain, in addition to specific
knowledge attribute values of catagory master and shadow, sufficient
attributes, including access control information, to allow List and one-
level Search operations to be performed on them.

In clause 24.1.2, the DistinguishedName of the immediateSuperior component
of HierarchicalAgreement shall be null."


3.3 The ASN.1 of hierarchical operational bindings already allows any
attributes to be passed from the subordinate DSA to the superior DSA
(SubordinateToSuperior parameter in clause 24.1.4.2 of X.518). However, a
note in the Standard limits this to those which are required to perform a
List operation. The UK submitted a ballot comment to the PDAM on Minor
Extensions to OSI Directory Service to support User Requirements, to remove
this restriction, so that the attributes may also be used for a one-level
Search operation. This ammendment has been accepted, and the restriction
has been removed in the current Draft Ammendment to the 1996 version of the
Standard [DAM User].

1993 implementations of X.500 conforming to this RFC, shall also remove
this restriction.


3.4 Each master first level DSA will enter into a shadowing agreement with
the root DSA, for the purpose of shadowing the root naming context.

The 1993 edition of the Standard explicitly recognises that there can be
master and shadow first level DSAs (X.501 Section 18.5). (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. In addition it holds shadow
copies of the (one or more) country entries that the master first level DSA
holds. There is currently an outstanding defect report [UK 142] on the 1993
Standard to clarify how a shadowing agreement is established between first
level DSAs. Once this has been ratified, the only additional text needed in
order to establish a shadowing agreement between the root DSA and a master
first level DSA is as follows:

"When clause 9.2 of ISO/IEC 9594-9:1993 is applied to the shadowing of the
root context by a first level DSA from the root DSA of a domain, then
UnitOfReplication shall be set as follows:

contextPrefix of AreaSpecification shall be null,
replicationArea of AreaSpecification shall be an empty SEQUENCE,
attributes of UnitofReplication shall be an empty SET OF SEQUENCE,
knowledge of UnitofReplication shall be set to both (shadow and master).

In other words, the information that will be replicated will be an empty
root entry plus all the attributes of the complete set of subordinate DSEs
of the root."


4 Security Considerations

Security considerations are not discussed in this memo.


References

[RFC 1276] Kille, S., "Replication and Distributed Operations extensions to
provide an Internet Directory using X.500", UCL, November 1991.

[X.500 93] X.500 | 9594.Part 1 Overview of Concepts, Models and Services
X.501 | 9594.Part 2 Models
X.511 | 9594.Part 3 Abstract Service Definition
X.518 | 9594.Part 4 Procedures for Distributed Operations
X.519 | 9594.Part 5 Protocol Specifications 
X.520 | 9594.Part 6 Selected Attribute Types
X.521 | 9594.Part 7 Selected Object Classes
X.509 | 9594.Part 8 Authentication Framework       
X.525 | 9594.Part 9 Replication

[ENV 41215] "Behaviour of DSAs for Distributed Operations", European Pre-
Standard, Dec 1992

[ISP 10615-6] "DSA Support of Distributed Operations", 5th draft pDISP, Oct
1994 

[NADF 7] SD-7 "Mapping the North American DIT onto Directory Management
Domains", North American Directory Forum, V 8.0, Jan 1993

[UK 142] Defect report number 142, submitted by the UK to ISO, March 1995.
(Proposed solution text included in Annex 1)

[DAM User] Draft Amendments on Minor Extensions to OSI Directory Service to
support User Requirements, August 1995.


Author's Address

D W Chadwick
IT Institute
University of Salford
Salford
M5 4WT
England
Phone: [phone]
Fax: [phone]
E-mail: [e-mail]
Annex 1 Solution Text of Defect Reports submitted to ISO/ITU-T by the UK


Defect Report 140

Nature of Defect

In section 24.1.4.2 it is defined that the SubordinateToSuperior parameter
of a HOB can pass an entryInfo parameter. This should contain entryACI
which may be used in the resolution of the List operation.

This is not correct as the prescriptive ACI from the relevant subentries is
also required in the superior DSA.

Solution Proposed by Source

It is proposed that the following is added to the SubordinateToSuperior
SEQUENCE of section 24.1.4.2 of X.518:

      subentries [2] SET OF SubentryInfo OPTIONAL

This is used to pass the revelant subentries from the subordinate to the
superior. This is similar to the way subentry information is passed in the
SuperiorToSubordinate parameter defined in 24.1.4.1.


Defect Report 142

Nature of Defect

The text which describes AreaSpecification in clause 9.2 of X.525 is
completely general. However, for the special case of replicating first
level knowledge references between first level DSAs, a clarifying sentence
should be added.

Solution Proposed by Source

In Section 9.2, under the ASN.1, after the description of area, and before
the description of SubtreeSpecification, add the sentence:

      "For the case where a DSA is shadowing first level knowledge from a
      first level DSA, the contextPrefix component is empty."