rfc2120.txt

RFC 的详细文档！

             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 the
   master first level DSA. specificExclusions shall contain one

   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 and
   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 an
   empty root entry plus all the attributes of the complete set of
   subordinate DSEs of the root that are held in the root DSA excluding
   the DSEs that the first level DSA already masters, plus a complete
   set of subordinate reference."

   Note that the maximum component of replicationArea, although not
   strictly necessary, is there for pragmatic reasons, for example,
   where a community of users wish to use the root DSA to hold some
   country specific entries.

5     The Slower Track Solution

   5.1 The slower track solution provides support for fully secure one
   level Search and List operations of the root in first level DSAs, and
   comprises of two steps for HOB establishment between the root DSA and
   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 entries
   from a master first level DSA. Step two, described in 5.4, requires
   either the root DSA administrator or the root DSA implementation to
   massage the shadow first level entries so that they appear to have
   been created by a HOB.  Managing the root context then continues as
   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 needs
   to be added to subordinate references in the DISP to allow the List
   operation to work securely in a shadowed DSA. (The ACI are held in
   both the subr DSE and in its subentry.) This requires a defect report
   on the 93 X.500 Standard to be submitted. The text of this defect
   report (that has been submitted to ISO) is given in Annex 2.

   Secondly, a new type of shadowing agreement will need to be
   established between the supplier and consumer DSAs, to copy
   subordinate entries rather than simply subordinate references, so
   that one level Search operations can work in the shadowing DSA.  This
   procedure should have been part of the 1997 edition of the X.500
   Standard, but due to an omission is not. Consequently  a defect
   report on the 1997 X.500 Standard has been submitted. The text of
   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 a
   master first level DSA can be replaced by a set of "spot" shadowing
   agreements, in which the first level DSA acts as the supplier, and
   the root DSA as the consumer. Each "spot" shadowing agreement
   replicates a first level entry which is mastered by the first level
   DSA. The UnitOfReplication shall be set as follows:

   contextPrefix of AreaSpecification shall be FirstLevelEntry,

   replicationArea of AreaSpecification shall be set to
                       SEQUENCE {
        specificExclusions  [1]  SET OF {
                       chopAfter [1]  {null} } }

   where FirstLevelEntry is the Distinguished Name of a first level
   entry (e.g. country, locality or international organisation) held by
   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 implementation
   (suitably tailored) must then administratively update each shadowed
   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 of
   them. The subordinate reference will point to the respective master
   first level DSA, and will comprise of a specific knowledge attribute,
   and the DSE bit of type subr being set. The contents of the specific
   knowledge attribute can be created from the contents of the supplier
   knowledge attribute already present in the first level entry and
   created by the "spot" shadowing agreement.

6     The Long Term Solution

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








Chadwick                      Experimental                      [Page 7]

RFC 2120         Managing the X.500 Root Naming Context       March 1997


   Whilst hierarchical agreements are standardised, this particular
   novel use of a HOB is not specifically recognised in the X.500
   Standard.  Although the ASN.1 will support it, there is no supporting
   text in the X.500 Standard. The following text supplements that in
   the X.500 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 (i.e. first
   level DSEs), one for each first level naming context in the domain,
   and their corresponding subentries.  The first level DSEs and their
   subentries will contain, in addition to specific knowledge attribute
   values of category master and shadow, sufficient attributes and
   collective 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."

   6.2 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 1993 edition of the X.500 Standard limits this
   to those which are required to perform a List operation. In the 1997
   edition of the X.500 Standard [DAM User] this restriction has been
   removed, so that the attributes may also be used for a one-level
   Search operation.

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

7     Security Considerations

   Security considerations are discussed in this memo in relation to
   List and one-level Search operations. Each DSE has access control
   information associated with it, and these must be adhered to when the
   operations are performed.










Chadwick                      Experimental                      [Page 8]

RFC 2120         Managing the X.500 Root Naming Context       March 1997


8     Acknowledgments

   The author would like to thank DANTE, without whose funding this work
   would not have been possible.

   The author would also like to thank Nexor, who reviewed the first
   version of this document in detail and provided valuable comments,
   and who first suggested the use of the DISP as a pragmatic solution
   for HOB establishment until the DOP becomes widely implemented.

   The author would also like to thank John Farrell from the ISODE
   Consortium, Andrew Palk   from Digital and Keith Richardson from ICL
   who attended the DANTE meeting, and contributed to the technical
   contents of the defect reports in Annexes 2 and 3.

9     References

   [DAM User] Draft Amendments on Minor Extensions to OSI Directory
   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 draft
   pDISP, Oct 1994

   [Mins] "Notes of DANTE meeting to discuss Managing the Root Naming
   Context. 18 June 1996." D W Chadwick, circulated to IDS mailing
   list

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

   [RFC 1276] Kille, S., "Replication and Distributed Operations
   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 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

10     Author's Address