As per Relevance of the word managing, we have this rfc below:
Network Working Group D.
Request for Comments: 2120 University of
Category: Experimental March 1997
Managing the X.500 Root Naming
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
The X.500 Standard [X.500 93] has the concept of first level DSAs
whose administrators must collectively manage the root naming
through bi-lateral agreements or other private means which
outside the scope of the X.500 Standard
The NameFLOW-Paradise X.500 service has an established procedure
managing the root naming context, which currently uses
proprietary replication mechanisms and a root DSA. The benefits
derive from this are twofold
- firstly it is much easier to co-ordinate the management of
root context information, when there is a central point
administration
- secondly the performance of one-level Search operations
greatly improved because the Quipu distribution and
mechanism does not have a restriction that exists in the 1988
1993 X.500 Standard
The NameFLOW-Paradise project is moving towards 1993 ISO X.500
Standard replication protocols and wants to standardise the
and procedure for managing the root naming context which will
based on 1993 X.500 Standard protocols. Such a protocol and
will be useful to private X.500 domains as well as to the
X.500 public domain. It is imperative that overall system
is not degraded by this transition
This document describes the use of 1993 ISO X.500 Standard
for managing the root context. Whilst the ASN.1 is compatible
that of the X.500 Standard, the actual settings of the parameters
supplementary to that of the X.500 Standard
Chadwick Experimental [Page 1]
RFC 2120 Managing the X.500 Root Naming Context March 1997
Table of
1 Introduction............................................. 2
2 Migration Plan........................................... 3
3 Technical Solutions...................................... 3
4 The Fast Track Solution.................................. 4
5 The Slower Track Solution................................ 6
6 The Long Term Solution................................... 7
7 Security Considerations.................................. 8
8 Acknowledgments.......................................... 9
9 References............................................... 9
10 Author's Address........................................ 10
Annex 1 Solution Text of Defect Reports submitted to ISO/ITU
T by the UK........................................... 11
Annex 2 Defect Report on 1993 X.500 Standard for
full ACIs to DISP for Subordinate References, so
Secure List Operation can be performed in Shadow DSAs. 12
Annex 3 Defect Report on 1997 X.500 Standard
an Enhancement to the Shadowing Agreement in order
support 1 Level Searches in Shadow DSAs............... 14
1
The NameFLOW-Paradise service has a proprietary way of managing
set of first level DSAs and the root naming context. There is
single root DSA (Giant Tortoise) which holds all of the
entries, and the country entries are then replicated to every
(first level) DSA and other DSAs by Quipu replication [RFC 1276]
the root DSA. In June 1996 there were 770 DSAs replicating
information over the Internet. The root DSA is not a feature of
X.500 Standard [X.500 93]. It was introduced because of the non
standard nature of the original Quipu knowledge model (also
in RFC 1276). However, it does have significant advantages both
managing the root naming context and in the performance of one-
Searches of the root. Performance is increased because each
DSA holds all the entry information of every country
By comparison, the 1988 X.500 Standard root context which
replicated to all the country DSAs, only holds knowledge
and a boolean (to say if the entry is an alias or not) for
country entry. This is sufficient to perform an insecure
operation, but not a one-level Search operation. When access
were added to the 1993 X.500 Standard, the root context
was increased (erroneously as it happens - this is the subject
defect report 140 - see Annex 1) to hold the access controls for
country entry, but a note in the X.500 Standard restricted its use
the List operation, in order to remain compatible with the 1988
edition of the X.500 Standard
Chadwick Experimental [Page 2]
RFC 2120 Managing the X.500 Root Naming Context March 1997
2 Migration
The NameFLOW-Paradise service is now migrating to X.500
[X.500 93] conforming products, and it is essential to replace
Quipu replication protocol with the 1993 shadowing and
binding protocols, but without losing the performance
that has been gained for one-level Searches
It is still the intention of the NameFLOW-Paradise service to
one master root DSA. This root DSA will not support user
operations via the LDAP, the DAP or the DSP, but each country (
level) DSA will be able to shadow the root context from this
DSA, using the DISP. Each first level DSA then only needs to have
bi-lateral agreement, between itself and the root DSA. This
will ensure that the first level DSA keeps the root DSA up to
with its country level information, and in turn, that the root
keeps the first level DSA up to date with the complete root
context. When a new first level DSA comes on line, it only needs
establish a bi-lateral agreement with the root DSA, in order
obtain the complete root context
This is a much easier configuration to manage than simply a set
first level DSAs without a root DSA, as suggested in the ISO X.500
Standard. In the X.500 Standard case each first level DSA must
bi-lateral agreements with all of the other first level DSAs. When
new first level DSA comes on line, it must establish agreements
all the existing first level DSAs. As the number of first level
grows, the process becomes unmanageable
However, it is also important to increase the amount of
that is held about every country entry, so that a one-level
operation can be performed in each first level DSA, without
needing to chain or refer the operation to all the other first
DSAs (as is currently the case with a X.500 Standard
system.)
3 Technical
3.1 The solution at first appears to be relatively straight forward
and involves two steps. Firstly, create a root DSA, and
hierarchical operational bindings using the DOP, between it and
master first level DSA. Secondly, each master first level DSA
into a shadowing agreement with the root DSA, to shadow the
root context information. In this way each first level DSA is
capable of independently performing List and one-level
operations, and name resolving to all other first level DSAs
Chadwick Experimental [Page 3]
RFC 2120 Managing the X.500 Root Naming Context March 1997
3.2 Unfortunately there are a number of complications that inhibit
quick implementation of this solution. Firstly, few DSA
have implemented the DOP. Secondly there are several defects in
X.500 Standard that currently stop the above solution from working
3.3 At a meeting chaired by DANTE in the UK on 18 June 1996[Mins],
which several DSA suppliers were present, the following
technical solution was proposed. This comprises a fast track
solution and a slower track fuller solution. Both the fast and
tracks use the shadowing protocol (DISP) for both steps of
solution, and do not rely on the DOP to establish HOBs. The
track solution, described in section 4, will support
distribution of the root context, and the (insecure) List
of the root's subordinates. The List operation will be
because access control information will not be present in the
DSEs. (However, since it is generally thought that first
entries, in particular country entries, are publicly accessible,
is not considered to be a serious problem.) Suppliers expect to
the fast track solution available before the end of 1996. The
track solution, described in section 5, will in addition
fully secure one level Search and List operations of the
(without the need to chain to the master DSAs). Suppliers at
DANTE meeting did not realistically expect this to be in
products much sooner than mid 1998.
3.4 The long term solution, which relies on the DOP to
HOBs, is described in section 6 of this document
(Note. It is strongly recommended that non-specific
references should not be allowed in the root context for
reasons. This is directed by the European functional X.500
[ENV 41215] and the NADF standing document [NADF 7]. It is
preferred by the International X.500 Standardized Profile [
10615-6].)
4 The Fast Track
4.1 The fast track solution provides root knowledge collection
insecure List operations for first level DSAs, and will be of use
systems which do not yet support the DOP for managing
operational bindings. The fast track solution relies upon the
with very few changes to the 1993 edition of the X.500 Standard
Chadwick Experimental [Page 4]
RFC 2120 Managing the X.500 Root Naming Context March 1997
4.2 Each master first level DSA administrator will make available
the administrator of the root DSA, sufficient information to
the root DSA to configure a subordinate reference to their DSA.
the simplest case, this can be via a telephone call, and
information comprises the access point of their DSA and the RDNs
the first level entries that they master
4.3 Each master first level DSA enters into a shadowing
with the root DSA, for the purpose of shadowing the root
context
The 1993 edition of the X.500 Standard explicitly recognises
there can be master and shadow first level DSAs (X.501 Section 18.5).
(The 1988 edition of the X.500 Standard does not explicitly
this, since it does not recognise shadowing.) A shadow first
DSA holds a copy of the root context, provided by a master
level DSA. In addition it holds shadow copies of the (one or more
country entries that the master first level DSA holds. There
currently an outstanding defect report [UK 142] on the 1993 X.500
Standard to clarify how a shadowing agreement is established
first level DSAs. Once this has been ratified, the only
text needed in order to establish a shadowing agreement between
root DSA and a master first level DSA is as follows
"When clause 9.2 of ISO/IEC 9594-9:1993 is applied to
shadowing of the root context by a first level DSA from the
DSA of a domain, then UnitOfReplication shall be set as follows
contextPrefix of AreaSpecification shall be null
replicationArea of AreaSpecification shall be set
SEQUENCE {
specificExclusions [1] SET OF {
chopBefore [0] FirstLevelEntry},
maximum [3] 1 }
where FirstLevelEntry is the RDN of a first level entry (e.g
country, locality or international organisation) held by
master first level DSA. specificExclusions shall contain
FirstLevelEntry for each first level entry mastered by this DSA
attributes of UnitofReplication shall be an empty SET OF SEQUENCE
knowledge of UnitofReplication shall be set to both (shadow
master).
Chadwick Experimental [Page 5]
RFC 2120 Managing the X.500 Root Naming Context March 1997
In other words, the information that will be replicated will be
empty root entry plus all the attributes of the complete set
subordinate DSEs of the root that are held in the root DSA
the DSEs that the first level DSA already masters, plus a
set of subordinate reference."
Note that the maximum component of replicationArea, although
strictly necessary, is there for pragmatic reasons, for example
where a community of users wish to use the root DSA to hold
country specific entries
5 The Slower Track
5.1 The slower track solution provides support for fully secure
level Search and List operations of the root in first level DSAs,
comprises of two steps for HOB establishment between the root DSA
master first level DSAs, using the DISP instead of the DOP. Step one
described in 5.3, allows the root DSA to shadow first level
from a master first level DSA. Step two, described in 5.4,
either the root DSA administrator or the root DSA implementation
massage the shadow first level entries so that they appear to
been created by a HOB. Managing the root context then continues
in 4.3 above
5.2 This solution requires two significant defects in the ISO X.500
Standard to be corrected. Firstly, access control information
to be added to subordinate references in the DISP to allow the
operation to work securely in a shadowed DSA. (The ACI are held
both the subr DSE and in its subentry.) This requires a defect
on the 93 X.500 Standard to be submitted. The text of this
report (that has been submitted to ISO) is given in Annex 2.
Secondly, a new type of shadowing agreement will need to
established between the supplier and consumer DSAs, to
subordinate entries rather than simply subordinate references,
that one level Search operations can work in the shadowing DSA.
procedure should have been part of the 1997 edition of the X.500
Standard, but due to an omission is not. Consequently a
report on the 1997 X.500 Standard has been submitted. The text
this defect report is given in Annex 3.
Chadwick Experimental [Page 6]
RFC 2120 Managing the X.500 Root Naming Context March 1997
5.3 The hierarchical operational binding between the root DSA and
master first level DSA can be replaced by a set of "spot"
agreements, in which the first level DSA acts as the supplier,
the root DSA as the consumer. Each "spot" shadowing
replicates a first level entry which is mastered by the first
DSA. The UnitOfReplication shall be set as follows
contextPrefix of AreaSpecification shall be FirstLevelEntry
replicationArea of AreaSpecification shall be set
SEQUENCE {
specificExclusions [1] SET OF {
chopAfter [1] {null} } }
where FirstLevelEntry is the Distinguished Name of a first
entry (e.g. country, locality or international organisation) held
the master first level DSA
attributes of UnitofReplication shall be an empty SET OF SEQUENCE
knowledge of UnitofReplication shall be absent
5.4 The root DSA administrator, or the root DSA
(suitably tailored) must then administratively update each
first level entry, so that they appear to have been created by a HOB
i.e. it is necessary to add a subordinate reference to each one
them. The subordinate reference will point to the respective
first level DSA, and will comprise of a specific knowledge attribute
and the DSE bit of type subr being set. The contents of the
knowledge attribute can be created from the contents of the
knowledge attribute already present in the first level entry
created by the "spot" shadowing agreement
6 The Long Term
6.1 Each master first level DSA will have a hierarchical
binding with the root DSA of the domain. Each master first level
will master one or more first level entries. The
operational binding will keep the appropriate
reference(s) (of category shadow and master) up to date, as well
the other entry information that is needed for one-level
operations (such as access controls, and attributes used
filtering).
Chadwick Experimental [Page 7]
RFC 2120 Managing the X.500 Root Naming Context March 1997
Whilst hierarchical agreements are standardised, this
novel use of a HOB is not specifically recognised in the X.500
Standard. Although the ASN.1 will support it, there is no
text in the X.500 Standard. The following text supplements that
the X.500 Standard, and describes how a first level DSA may have
hierarchical operational binding with the root DSA of its domain
"Clause 24 of ISO/IEC 9594-4:1993 shall also apply when a first
DSA is a subordinate DSA, and the root DSA of the domain is
superior DSA. The naming context held by the superior (root) DSA
the root naming context (or root context - the terms are synonymous
of the domain. The root context consists of the root entry of the
(which is empty) plus a complete set of subordinate DSEs (i.e.
level DSEs), one for each first level naming context in the domain
and their corresponding subentries. The first level DSEs and
subentries will contain, in addition to specific knowledge
values of category master and shadow, sufficient attributes
collective attributes, including access control information, to
List and one-level Search operations to be performed on them
In clause 24.1.2, the DistinguishedName of the
component of HierarchicalAgreement shall be null."
6.2 The ASN.1 of hierarchical operational bindings already allows
attributes to be passed from the subordinate DSA to the superior
(SubordinateToSuperior parameter in clause 24.1.4.2 of X.518).
However, a note in the 1993 edition of the X.500 Standard limits
to those which are required to perform a List operation. In the 1997
edition of the X.500 Standard [DAM User] this restriction has
removed, so that the attributes may also be used for a one-
Search operation
1993 implementations of X.500 conforming to this RFC, shall
remove this restriction
7 Security
Security considerations are discussed in this memo in relation
List and one-level Search operations. Each DSE has access
information associated with it, and these must be adhered to when
operations are performed
Chadwick Experimental [Page 8]
RFC 2120 Managing the X.500 Root Naming Context March 1997
8
The author would like to thank DANTE, without whose funding this
would not have been possible
The author would also like to thank Nexor, who reviewed the
version of this document in detail and provided valuable comments
and who first suggested the use of the DISP as a pragmatic
for HOB establishment until the DOP becomes widely implemented
The author would also like to thank John Farrell from the
Consortium, Andrew Palk from Digital and Keith Richardson from
who attended the DANTE meeting, and contributed to the
contents of the defect reports in Annexes 2 and 3.
9
[DAM User] Draft Amendments on Minor Extensions to OSI
Service to support User Requirements, August 1995.
[ENV 41215] "Behaviour of DSAs for Distributed Operations",
European X.500 Pre-Standard, Dec 1992
[ISP 10615-6] "DSA Support of Distributed Operations", 5th
pDISP, Oct 1994
[Mins] "Notes of DANTE meeting to discuss Managing the Root
Context. 18 June 1996." D W Chadwick, circulated to IDS
[NADF 7] SD-7 "Mapping the North American DIT onto
Management Domains", North American Directory Forum, V 8.0,
1993
[RFC 1276] Kille, S., "Replication and Distributed
extensions to provide an Internet Directory using X.500", UCL
November 1991.
Chadwick Experimental [Page 9]
RFC 2120 Managing the X.500 Root Naming Context March 1997
[UK 142] Defect report number 142, submitted by the UK to ISO
March 1995. (Proposed solution text included in Annex 1)
[X.500 93] X.500 | 9594.Part 1 Overview of Concepts, Models
X.501 | 9594.Part 2
X.511 | 9594.Part 3 Abstract Service
X.518 | 9594.Part 4 Procedures for Distributed
X.519 | 9594.Part 5 Protocol
X.520 | 9594.Part 6 Selected Attribute
X.521 | 9594.Part 7 Selected Object
X.509 | 9594.Part 8 Authentication
X.525 | 9594.Part 9
10 Author's
D W
IT
University of
M5 4
Phone: +44 161 745 5351
Fax: +44 161 745 8169
E-mail: D.W.Chadwick@iti.salford.ac.
Chadwick Experimental [Page 10]
RFC 2120 Managing the X.500 Root Naming Context March 1997
Annex 1 Solution Text of Defect Reports submitted to ISO/ITU-T
the
Defect Report 140
Nature of
In section 24.1.4.2 it is defined that the
parameter of a HOB can pass an entryInfo parameter. This
contain entryACI which may be used in the resolution of the
operation
This is not correct as the prescriptive ACI from the
subentries is also required in the superior DSA
Solution Proposed by
It is proposed that the following is added to
SubordinateToSuperior SEQUENCE of section 24.1.4.2 of X.518:
subentries [2] SET OF SubentryInfo
This is used to pass the relevant subentries from the subordinate
the superior. This is similar to the way subentry information
passed in the SuperiorToSubordinate parameter defined in 24.1.4.1.
Defect Report 142
Nature of
The text which describes AreaSpecification in clause 9.2 of X.525
completely general. However, for the special case of
first level knowledge references between first level DSAs,
clarifying sentence should be added
Solution Proposed by
In Section 9.2, under the ASN.1, after the description of area,
before the description of SubtreeSpecification, add the sentence
"For the case where a DSA is shadowing first level knowledge
a first level DSA, the contextPrefix component is empty."
Chadwick Experimental [Page 11]
RFC 2120 Managing the X.500 Root Naming Context March 1997
Annex 2 Defect Report on 1993 X.500 Standard for Adding full ACIs
DISP for Subordinate References, so that Secure List Operation
be performed in Shadow
Nature of Defect
The List operation may be carried out in a superior DSA
subordinate reference information, providing that the fromEntry
is set to false in the response. However, in order to do
securely, complete access control information is needed for the
of the subordinate entry. The existing text assumes that this is
in entry ACI (e.g. see 9.2.4.1 c) or in prescriptive ACI held
subentries above the DSE (e.g. see 9.2.4.1 b). In the case of
subordinate reference, the prescriptive ACI may be held below
DSE, if the subordinate reference points to a new
point. The shadowing document needs to make it clear that this can
the case, and needs to allow for this additional access
information to be shadowed
A related defect report (140) has already suggested that this
omission should be added to operational bindings
Solution Proposed by the Source
All the following changes are to X.525|ISO 9594-9.
I) Insert the following text into 7.2.2.3, at the end of both
second paragraph and the first sentence of the third paragraph (
"appropriate knowledge"): "and access control information."
II) Insert a new third paragraph into 7.2.2.3: "If
knowledge is supplied, and the supplying DSE (of type subr) is
of type admPoint, then the SDSE shall additionally be of
admPoint and the administrativeRole attribute shall be supplied.
such a DSE has any immediately subordinate subentries
PrescriptiveACI relating to the administrative point, then they
also be supplied as SDSEs in the shadowed information
Note. A DSE can be of type subr and admPoint in a superior DSA,
the naming context in the subordinate DSA is the start of a
administrative area."
III) Update figure 3 to show a subentry immediately below
subordinate reference. The subentry contains prescriptiveACI and
part of the shadowed information
Chadwick Experimental [Page 12]
RFC 2120 Managing the X.500 Root Naming Context March 1997
.
Etc. / \
/ \
/ o \
/ / \ \
Replicated / / \ \
Area --------------/--/-> \ \
/ / \ \
/ / \ \
/ / \ \
Subordinate /__/_____________\__\
knowledge--------/-> o o o \
/ / \ \
Prescriptive---/-> o o \
ACI Subentries/ \
Unit of
Etc
/ \
/ \
/ \
/ \
/ \
/ \
/_____________\
o o
/ \
o
Shadowed
ADDITIONS TO FIGURE 3, SECTION 7.2, X.525
IV) Add supporting text to section 7.2 in the paragraph after
3. Insert after the sentence "Subordinate knowledge may also
replicated" the following sentences "Implicit in the Add
text to section 7.2 in the paragraph after Figure 3. Insert
the sentence subordinate knowledge is the access control
which governs access to the RDN of the subordinate knowledge.
the subordinate entry is an administrative point in another DSA,
part of this access control information may be held
prescriptiveACI subentries beneath the subordinate knowledge."
v) Add a new point d) to 9.2.4.1: "if subordinate knowledge (
extended knowledge) is shadowed then any prescriptiveACI
subordinate subentries shall also be copied."
Chadwick Experimental [Page 13]
RFC 2120 Managing the X.500 Root Naming Context March 1997
Annex 3 Defect Report on 1997 X.500 Standard Proposing an Enhancement
the Shadowing Agreement in order to support 1 Level Searches in
DSAs
Nature of Defect
The 1997 edition of the X.500 Standard has allowed, for reasons
operational efficiency, one level Searches to be carried out in
superior DSA, when the actual entries are context prefixes
subordinate DSAs. The HOBs have been extended to allow this
information to be carried up to the superior DSA. Unfortunately,
forgot to add the corresponding text to Part 9, so that shadow
are able to copy this additional information from the supplier DSA
This defect report proposes the additional text for Part 9.
Solution Proposed by the Source
All the following changes are to X.525|ISO 9594-9.
I) Section 9.2, add a new subordinates parameter
UnitOfReplication, viz
UnitOfReplication ::= SEQUENCE
area AreaSpecification
attributes AttributeSelection
knowledge Knowledge OPTIONAL
subordinates BOOLEAN DEFAULT FALSE }
subordinates is used to indicate that subordinate entries,
than simply subordinate references, are to be copied to
consumer DSA. subordinates may only be TRUE if knowledge
requested and extendedKnowledge is FALSE
II) Insert a new fourth paragraph (assuming previous defect
List was accepted) into 7.2.2.3:
"If subordinates is specified, then the supplier shall
subordinate entries rather than subordinate references, and
SDSEs will be of type subr, entry and cp. The subordinate
will contain attributes according to the attribute selection
In addition, if the supplying DSE is of type admPoint, then
SDSE shall additionally be of type admPoint and
administrativeRole attribute shall be supplied. All
subentries below the admPoint DSE shall also be supplied as
in the shadowed information."
Chadwick Experimental [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
