home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ids-root-naming-01.txt < prev    next >
Text File  |  1996-09-23  |  29KB  |  744 lines
  1. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  2.  
  3. IDS Working Group                            David Chadwick
  4. Internet-Draft                          University of Salford
  5. DANTE IN PRINT 18                            September 20 1996
  6. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1996
  7.  
  8.  
  9.             Managing the X.500 Root Naming Context
  10.  
  11.  
  12. Status of this Memo
  13.  
  14. This document is an Internet-Draft.  Internet-Drafts are working
  15. documents of the Internet Engineering Task Force (IETF), its
  16. areas, and its working groups.  Note that other groups may also
  17. distribute working documents as Internet-Drafts.
  18.  
  19. Internet-Drafts are draft documents valid for a maximum of six
  20. months.  Internet-Drafts may be updated, replaced, or obsoleted by
  21. other documents at any time.  It is not appropriate to use
  22. Internet-Drafts as reference material or to cite them other than
  23. as a "working draft" or "work in progress".
  24.  
  25. To learn the current status of any Internet-Draft, please check
  26. the 1id-abstracts.txt listing contained in the Internet-Drafts
  27. Shadow Directories on ds.internic.net, nic.nordu.net,
  28. ftp.nisc.sri.com, or munnari.oz.au.
  29.  
  30.  
  31. Abstract
  32.  
  33. The X.500 Standard [X.500 93] has the concept of first level DSAs,
  34. whose administrators must collectively manage the root naming
  35. context through bi-lateral agreements or other private means which
  36. are outside the scope of the Standard.
  37.  
  38. The NameFLOW-Paradise X.500 service has an established procedure
  39. for managing the root naming context, which currently uses Quipu
  40. proprietary replication mechanisms and a root DSA. The benefits
  41. that derive from this are twofold:
  42.  
  43.      - firstly it is much easier to co-ordinate the management of
  44.      the root context information, when there is a central point
  45.      of administration,
  46.  
  47.      - secondly the performance of one-level Search operations is
  48.      greatly improved because the Quipu distribution and
  49.      replication mechanism does not have a restriction that exists
  50.      in the 1988 and 1993 Standard.
  51.  
  52.                               Page 1
  53. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  54.  
  55. The NameFLOW-Paradise project is moving towards 1993 ISO Standard
  56. replication protocols and wants to standardise the protocol and
  57. procedure for managing the root naming context which will be based
  58. on 1993 Standard protocols. Such a protocol and procedure will be
  59. useful to private X.500 domains as well as to the Internet X.500
  60. public domain. It is imperative that overall system performance is
  61. not degraded by this transition.
  62.  
  63. This document describes the use of 1993 ISO Standard protocols for
  64. managing the root context. Whilst the ASN.1 is compatible with
  65. that of the Standard, the actual settings of the parameters are
  66. supplementary to that of the Standard.
  67.  
  68.  
  69. Table of Contents
  70.  
  71. 1 Introduction                                               2
  72. 2 Migration Plan                                             3
  73. 3 Technical Solutions                                        4
  74. 4 The Fast Track Solution                                    5
  75. 5 The Slower Track Solution                                  6
  76. 6 The Long Term Solution                                     7
  77. 7 Security Considerations                                    8
  78. 8 Acknowledgments                                            8
  79. 9 References                                                 9
  80. 10 Author's Address                                         10
  81. Annex 1 Solution Text of Defect Reports submitted to ISO/ITU-
  82.      T by the UK                                            10
  83. Annex  2  Defect Report on 1993 Standard for Adding full ACIs
  84.      to  DISP for Subordinate References, so that Secure List
  85.      Operation can be performed in Shadow DSAs              11
  86. Annex   3   Defect  Report  on  1997  Standard  Proposing  an
  87.      Enhancement  to  the  Shadowing Agreement  in  order  to
  88.      support 1 Level Searches in Shadow DSAs.               13
  89.  
  90.  
  91. 1     Introduction
  92.  
  93. The NameFLOW-Paradise service has a proprietary way of managing
  94. the set of first level DSAs and the root naming context. There is
  95. a single root DSA (Giant Tortoise) which holds all of the country
  96. entries, and the country entries are then replicated to every
  97. country (first level) DSA and other DSAs by Quipu replication [RFC
  98. 1276] from the root DSA. In June 1996 there were 770 DSAs
  99. replicating this information over the Internet. The root DSA is
  100. not a feature of the X.500 Standard [X.500 93]. It was introduced
  101. because of the non-standard nature of the original Quipu knowledge
  102. model (also described in RFC 1276). However, it does have
  103. significant advantages both in managing the root naming context
  104. and in the performance of one-level Searches of the root.
  105. Performance is increased because each country DSA holds all the
  106. entry information of every country.
  107.  
  108.                               Page 2
  109. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  110.  
  111. By comparison, the 1988 Standard root context which is replicated
  112. to all the country DSAs, only holds knowledge information and a
  113. boolean (to say if the entry is an alias or not) for each country
  114. entry. This is sufficient to perform an insecure List operation,
  115. but not a one-level Search operation. When access controls were
  116. added to the 1993 Standard, the root context information was
  117. increased (erroneously as it happens - this is the subject of
  118. defect report 140 - see Annex 1) to hold the access controls for
  119. each country entry, but a note in the Standard restricted its use
  120. to the List operation, in order to remain compatible with the 1988
  121. edition of the Standard.
  122.  
  123.  
  124. 2     Migration Plan
  125.  
  126. The NameFLOW-Paradise service is now migrating to 1993 Standard
  127. [X.500 93] conforming products, and it is essential to replace the
  128. Quipu replication protocol with the 1993 shadowing and operational
  129. binding protocols, but without losing the performance improvement
  130. that has been gained for one-level Searches.
  131.  
  132. It is still the intention of the NameFLOW-Paradise service to have
  133. one master root DSA. This root DSA will not support user Directory
  134. operations via the LDAP, the DAP or the DSP, but each country
  135. (first level) DSA will be able to shadow the root context from
  136. this root DSA, using the DISP. Each first level DSA then only
  137. needs to have one bi-lateral agreement, between itself and the
  138. root DSA. This agreement will ensure that the first level DSA
  139. keeps the root DSA up to date with its country level information,
  140. and in turn, that the root DSA keeps the first level DSA up to
  141. date with the complete root naming context. When a new first level
  142. DSA comes on line, it only needs to establish a bi-lateral
  143. agreement with the root DSA, in order to obtain the complete root
  144. context.
  145.  
  146. This is a much easier configuration to manage than simply a set of
  147. first level DSAs without a root DSA, as suggested in the ISO
  148. Standard. In the Standard case each first level DSA must have bi-
  149. lateral agreements with all of the other first level DSAs. When a
  150. new first level DSA comes on line, it must establish agreements
  151. with all the existing first level DSAs. As the number of first
  152. level DSAs grows, the process becomes unmanageable.
  153.  
  154. However, it is also important to increase the amount of
  155. information that is held about every country entry, so that a one-
  156. level Search operation can be performed in each first level DSA,
  157. without it needing to chain or refer the operation to all the
  158. other first level DSAs (as is currently the case with a Standard
  159. conforming system.)
  160.  
  161.                               Page 3
  162. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  163.  
  164.  
  165. 3     Technical Solutions
  166.  
  167. 0.1 The solution at first appears to be relatively straight
  168. forward, and involves two steps. Firstly, create a root DSA, and
  169. establish hierarchical operational bindings using the DOP, between
  170. it and each master first level DSA. Secondly, each master first
  171. level DSA enters into a shadowing agreement with the root DSA, to
  172. shadow the enlarged root context information. In this way each
  173. first level DSA is then capable of independently performing List
  174. and one-level Search operations, and name resolving to all other
  175. first level DSAs.
  176.  
  177. 3.2 Unfortunately there are a number of complications that inhibit
  178. a quick implementation of this solution. Firstly, few DSA
  179. suppliers have implemented the DOP. Secondly there are several
  180. defects in the Standard that currently stop the above solution
  181. from working.
  182.  
  183. 3.3 At a meeting chaired by DANTE in the UK on 18 June 1996[Mins],
  184. at which several DSA suppliers were present, the following
  185. pragmatic technical solution was proposed. This comprises a fast
  186. track partial solution and a slower track fuller solution. Both
  187. the fast and slower tracks use the shadowing protocol (DISP) for
  188. both steps of the solution, and do not rely on the DOP to
  189. establish HOBs. The fast track solution, described in section 4,
  190. will support knowledge distribution of the root context, and the
  191. (insecure) List operation of the root's subordinates. The List
  192. operation will be insecure because access control information will
  193. not be present in the shadow DSEs. (However, since it is generally
  194. thought that first level entries, in particular country entries,
  195. are publicly accessible, this is not considered to be a serious
  196. problem.) Suppliers expect to have the fast track solution
  197. available before the end of 1996. The slower track solution,
  198. described in section 5, will in addition support fully secure one
  199. level Search and List operations of the root (without the need to
  200. chain to the master DSAs). Suppliers at the DANTE meeting did not
  201. realistically expect this to be in their products much sooner than
  202. mid 1998.
  203.  
  204. 3.4 The long term solution, which relies on the DOP to establish
  205. HOBs, is described in section 6 of this document.
  206.  
  207. (Note. It is strongly recommended that non-specific subordinate
  208. references should not be allowed in the root context for
  209. efficiency reasons. This is directed by the European functional
  210. standard [ENV 41215] and the NADF standing document [NADF 7]. It
  211. is also preferred by the International Standardized Profile [ISP
  212. 10615-6].)
  213.  
  214.                               Page 4
  215. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  216.  
  217. 4     The Fast Track Solution
  218.  
  219. 4.1 The fast track solution provides root knowledge collection and
  220. insecure List operations for first level DSAs, and will be of use
  221. to systems which do not yet support the DOP for managing
  222. hierarchical operational bindings. The fast track solution relies
  223. upon the DISP with very few changes to the 1993 edition of the
  224. Standard.
  225.  
  226. 4.2 Each master first level DSA administrator will make available
  227. to the administrator of the root DSA, sufficient information to
  228. allow the root DSA to configure a subordinate reference to their
  229. DSA. In the simplest case, this can be via a telephone call, and
  230. the information comprises the access point of their DSA and the
  231. RDNs of the first level entries that they master.
  232.  
  233. 4.3 Each master first level DSA enters into a shadowing agreement
  234. with the root DSA, for the purpose of shadowing the root naming
  235. context.
  236.  
  237. The 1993 edition of the Standard explicitly recognises that there
  238. can be master and shadow first level DSAs (X.501 Section 18.5).
  239. (The 1988 edition of the standard does not explicitly recognise
  240. this, since it does not recognise shadowing.) A shadow first level
  241. DSA holds a copy of the root context, provided by a master first
  242. level DSA. In addition it holds shadow copies of the (one or more)
  243. country entries that the master first level DSA holds. There is
  244. currently an outstanding defect report [UK 142] on the 1993
  245. Standard to clarify how a shadowing agreement is established
  246. between first level DSAs. Once this has been ratified, the only
  247. additional text needed in order to establish a shadowing agreement
  248. between the root DSA and a master first level DSA is as follows:
  249.  
  250. "When clause 9.2 of ISO/IEC 9594-9:1993 is applied to the
  251. shadowing of the root context by a first level DSA from the root
  252. DSA of a domain, then UnitOfReplication shall be set as follows:
  253.  
  254. contextPrefix of AreaSpecification shall be null,
  255.  
  256. replicationArea of AreaSpecification shall be set to
  257.                     SEQUENCE {
  258.      specificExclusions  [1]  SET OF {
  259.           chopBefore          [0]  FirstLevelEntry},
  260.      maximum             [3]  1 }
  261.  
  262. where FirstLevelEntry is the RDN of a first level entry (e.g.
  263. country, locality or international organisation) held by the
  264. master first level DSA. specificExclusions shall contain one
  265.  
  266.                               Page 5
  267. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  268.  
  269. FirstLevelEntry for each first level entry mastered by this DSA,
  270.  
  271. attributes of UnitofReplication shall be an empty SET OF SEQUENCE,
  272.  
  273. knowledge of UnitofReplication shall be set to both (shadow and
  274. master).
  275.  
  276. In other words, the information that will be replicated will be an
  277. empty root entry plus all the attributes of the complete set of
  278. subordinate DSEs of the root that are held in the root DSA
  279. excluding the DSEs that the first level DSA already masters, plus
  280. a complete set of subordinate reference."
  281.  
  282. Note that the maximum component of replicationArea, although not
  283. strictly necessary, is there for pragmatic reasons, for example,
  284. where a community of users wish to use the root DSA to hold some
  285. country specific entries.
  286.  
  287.  
  288. 5     The Slower Track Solution
  289.  
  290. 5.1 The slower track solution provides support for fully secure
  291. one level Search and List operations of the root in first level
  292. DSAs, and comprises of two steps for HOB establishment between the
  293. root DSA and master first level DSAs, using the DISP instead of
  294. the DOP. Step one, described in 5.3, allows the root DSA to shadow
  295. first level entries from a master first level DSA. Step two,
  296. described in 5.4, requires either the root DSA administrator or
  297. the root DSA implementation to massage the shadow first level
  298. entries so that they appear to have been created by a HOB.
  299. Managing the root context then continues as in 4.3 above.
  300.  
  301. 5.2 This solution requires two significant defects in the ISO
  302. Standard to be corrected. Firstly, access control information
  303. needs to be added to subordinate references in the DISP to allow
  304. the List operation to work securely in a shadowed DSA. (The ACI
  305. are held in both the subr DSE and in its subentry.) This requires
  306. a defect report on the 93 standard to be submitted. The text of
  307. this defect report (that has been submitted to ISO) is given in
  308. Annex 2.
  309.  
  310. Secondly, a new type of shadowing agreement will need to be
  311. established between the supplier and consumer DSAs, to copy
  312. subordinate entries rather than simply subordinate references, so
  313. that one level Search operations can work in the shadowing DSA.
  314. This procedure should have been part of the 1997 edition of the
  315. standard, but due to an omission is not. Consequently  a defect
  316. report on the 1997 Standard has been submitted. The text of this
  317. defect report is given in Annex 3.
  318.  
  319.                               Page 6
  320. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  321.  
  322. 5.3 The hierarchical operational binding between the root DSA and
  323. a master first level DSA can be replaced by a set of "spot"
  324. shadowing agreements, in which the first level DSA acts as the
  325. supplier, and the root DSA as the consumer. Each "spot" shadowing
  326. agreement replicates a first level entry which is mastered by the
  327. first level DSA. The UnitOfReplication shall be set as follows:
  328.  
  329. contextPrefix of AreaSpecification shall be FirstLevelEntry,
  330.  
  331. replicationArea of AreaSpecification shall be set to
  332.                     SEQUENCE {
  333.      specificExclusions  [1]  SET OF {
  334.                     chopAfter [1]  {null} } }
  335.  
  336. where FirstLevelEntry is the Distinguished Name of a first level
  337. entry (e.g. country, locality or international organisation) held
  338. by the master first level DSA.
  339.  
  340. attributes of UnitofReplication shall be an empty SET OF SEQUENCE,
  341.  
  342. knowledge of UnitofReplication shall be absent.
  343.  
  344. 5.4 The root DSA administrator, or the root DSA implementation
  345. (suitably tailored) must then administratively update each
  346. shadowed first level entry, so that they appear to have been
  347. created by a HOB, i.e. it is necessary to add a subordinate
  348. reference to each one of them. The subordinate reference will
  349. point to the respective master first level DSA, and will comprise
  350. of a specific knowledge attribute, and the DSE bit of type subr
  351. being set. The contents of the specific knowledge attribute can be
  352. created from the contents of the supplier knowledge attribute
  353. already present in the first level entry and created by the "spot"
  354. shadowing agreement.
  355.  
  356.  
  357. 6     The Long Term Solution
  358.  
  359. 6.1 Each master first level DSA will have a hierarchical
  360. operational binding with the root DSA of the domain. Each master
  361. first level DSA will master one or more first level entries. The
  362. hierarchical operational binding will keep the appropriate
  363. subordinate reference(s) (of category shadow and master) up to
  364. date, as well as the other entry information that is needed for
  365. one-level Search operations (such as access controls, and
  366. attributes used in filtering).
  367.  
  368. Whilst hierarchical agreements are standardised, this particular
  369. novel use of a HOB is not specifically recognised in the Standard.
  370. Although the ASN.1 will support it, there is no supporting text in
  371. the Standard. The following text supplements that in the Standard,
  372.  
  373.                               Page 7
  374.   draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  375.  
  376. and describes how a first level DSA may have a hierarchical
  377. operational binding with the root DSA of its domain.
  378.  
  379. "Clause 24 of ISO/IEC 9594-4:1993 shall also apply when a first
  380. level DSA is a subordinate DSA, and the root DSA of the domain is
  381. the superior DSA. The naming context held by the superior (root)
  382. DSA is the root naming context (or root context - the terms are
  383. synonymous) of the domain. The root context consists of the root
  384. entry of the DIT (which is empty) plus a complete set of
  385. subordinate DSEs (i.e. first level DSEs), one for each first level
  386. naming context in the domain, and their corresponding subentries.
  387. The first level DSEs and their subentries will contain, in
  388. addition to specific knowledge attribute values of category master
  389. and shadow, sufficient attributes and collective attributes,
  390. including access control information, to allow List and one-level
  391. Search operations to be performed on them.
  392.  
  393. In clause 24.1.2, the DistinguishedName of the immediateSuperior
  394. component of HierarchicalAgreement shall be null."
  395.  
  396. 6.2 The ASN.1 of hierarchical operational bindings already allows
  397. any attributes to be passed from the subordinate DSA to the
  398. superior DSA (SubordinateToSuperior parameter in clause 24.1.4.2
  399. of X.518). However, a note in the 1993 edition of the Standard
  400. limits this to those which are required to perform a List
  401. operation. In the 1997 edition of the Standard [DAM User] this
  402. restriction has been removed, so that the attributes may also be
  403. used for a one-level Search operation.
  404.  
  405. 1993 implementations of X.500 conforming to this RFC, shall also
  406. remove this restriction.
  407.  
  408.  
  409. 7     Security Considerations
  410.  
  411. Security considerations are discussed in this memo in relation to
  412. List and one-level Search operations. Each DSE has access control
  413. information associated with it, and these must be adhered to when
  414. the operations are performed.
  415.  
  416.  
  417. 8     Acknowledgments
  418.  
  419. The author would like to thank DANTE, without whose funding this
  420. work would not have been possible.
  421.  
  422. The author would also like to thank Nexor, who reviewed the first
  423. version of this document in detail and provided valuable comments,
  424. and who first suggested the use of the DISP as a pragmatic
  425.  
  426.                               Page 8
  427. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  428.  
  429. solution for HOB establishment until the DOP becomes widely
  430. implemented.
  431.  
  432. The author would also like to thank John Farrell from the ISODE
  433. Consortium, Andrew Palk   from Digital and Keith Richardson from
  434. ICL who attended the DANTE meeting, and contributed to the
  435. technical contents of the defect reports in Annexes 2 and 3.
  436.  
  437.  
  438. 9     References
  439.  
  440. [DAM User] Draft Amendments on Minor Extensions to OSI Directory
  441. Service to support User Requirements, August 1995.
  442.  
  443. [ENV 41215] "Behaviour of DSAs for Distributed Operations",
  444. European Pre-Standard, Dec 1992
  445.  
  446. [ISP 10615-6] "DSA Support of Distributed Operations", 5th draft
  447. pDISP, Oct 1994
  448.  
  449. [Mins] "Notes of DANTE meeting to discuss Managing the Root Naming
  450. Context. 18 June 1996." D W Chadwick, circulated to IDS mailing
  451. list
  452.  
  453. [NADF 7] SD-7 "Mapping the North American DIT onto Directory
  454. Management Domains", North American Directory Forum, V 8.0, Jan
  455. 1993
  456.  
  457. [RFC 1276] Kille, S., "Replication and Distributed Operations
  458. extensions to provide an Internet Directory using X.500", UCL,
  459. November 1991.
  460.  
  461. [UK 142] Defect report number 142, submitted by the UK to ISO,
  462. March 1995. (Proposed solution text included in Annex 1)
  463.  
  464. [X.500 93] X.500 | 9594.Part 1 Overview of Concepts, Models and
  465. Services
  466. X.501 | 9594.Part 2 Models
  467. X.511 | 9594.Part 3 Abstract Service Definition
  468. X.518 | 9594.Part 4 Procedures for Distributed Operations
  469. X.519 | 9594.Part 5 Protocol Specifications
  470. X.520 | 9594.Part 6 Selected Attribute Types
  471. X.521 | 9594.Part 7 Selected Object Classes
  472. X.509 | 9594.Part 8 Authentication Framework
  473. X.525 | 9594.Part 9 Replication
  474.  
  475.                               Page 9
  476. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  477.  
  478.  
  479. 10     Author's Address
  480.  
  481. D W Chadwick
  482. IT Institute
  483. University of Salford
  484. Salford
  485. M5 4WT
  486. England
  487. Phone: +44 161 745 5351
  488. Fax: +44 161 745 8169
  489. E-mail: D.W.Chadwick@iti.salford.ac.uk
  490.  
  491.  
  492. Annex 1 Solution Text of Defect Reports submitted to ISO/ITU-T by
  493. the UK
  494.  
  495. Defect Report 140
  496.  
  497. Nature of Defect
  498.  
  499. In section 24.1.4.2 it is defined that the SubordinateToSuperior
  500. parameter of a HOB can pass an entryInfo parameter. This should
  501. contain entryACI which may be used in the resolution of the List
  502. operation.
  503.  
  504. This is not correct as the prescriptive ACI from the relevant
  505. subentries is also required in the superior DSA.
  506.  
  507. Solution Proposed by Source
  508.  
  509. It is proposed that the following is added to the
  510. SubordinateToSuperior SEQUENCE of section 24.1.4.2 of X.518:
  511.  
  512.      subentries     [2] SET OF SubentryInfo OPTIONAL
  513.  
  514. This is used to pass the relevant subentries from the subordinate
  515. to the superior. This is similar to the way subentry information
  516. is passed in the SuperiorToSubordinate parameter defined in
  517. 24.1.4.1.
  518.  
  519.  
  520. Defect Report 142
  521.  
  522. Nature of Defect
  523.  
  524. The text which describes AreaSpecification in clause 9.2 of X.525
  525. is completely general. However, for the special case of
  526. replicating first level knowledge references between first level
  527. DSAs, a clarifying sentence should be added.
  528.  
  529.                               Page 10
  530. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  531.  
  532. Solution Proposed by Source
  533.  
  534. In Section 9.2, under the ASN.1, after the description of area,
  535. and before the description of SubtreeSpecification, add the
  536. sentence:
  537.  
  538.      "For the case where a DSA is shadowing first level knowledge
  539.      from a first level DSA, the contextPrefix component is
  540.      empty."
  541.  
  542. Annex 2 Defect Report on 1993 Standard for Adding full ACIs to
  543. DISP for Subordinate References, so that Secure List Operation can
  544. be performed in Shadow DSAs
  545.  
  546. Nature of Defect:
  547.  
  548. The List operation may be carried out in a superior DSA using
  549. subordinate reference information, providing that the fromEntry
  550. flag is set to false in the response. However, in order to do this
  551. securely, complete access control information is needed for the
  552. RDN of the subordinate entry. The existing text assumes that this
  553. is held in entry ACI (e.g. see 9.2.4.1 c) or in prescriptive ACI
  554. held in subentries above the DSE (e.g. see 9.2.4.1 b). In the case
  555. of a subordinate reference, the prescriptive ACI may be held below
  556. the DSE, if the subordinate reference points to a new
  557. administrative point. The shadowing document needs to make it
  558. clear that this can be the case, and needs to allow for this
  559. additional access control information to be shadowed.
  560.  
  561. A related defect report (140) has already suggested that this same
  562. omission should be added to operational bindings.
  563.  
  564. Solution Proposed by the Source:
  565.  
  566. All the following changes are to X.525|ISO 9594-9.
  567.  
  568. I) Insert the following text into 7.2.2.3, at the end of both the
  569. second paragraph and the first sentence of the third paragraph
  570. (after "appropriate knowledge"):
  571. "and access control information."
  572.  
  573. II) Insert a new third paragraph into 7.2.2.3:
  574. "If  subordinate knowledge is supplied, and the supplying DSE (of
  575. type subr) is also of type admPoint, then the SDSE shall
  576. additionally be of type admPoint and the administrativeRole
  577. attribute shall be supplied.  If  such a DSE has any immediately
  578. subordinate subentries containing PrescriptiveACI relating to the
  579. administrative point, then they shall also be supplied as SDSEs in
  580. the shadowed information.
  581.  
  582.                               Page 11
  583. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  584.  
  585. Note. A DSE can be of type subr and admPoint in a superior DSA,
  586. when the naming context in the subordinate DSA is the start of a
  587. new administrative area."
  588.  
  589. III) Update figure 3 to show a subentry immediately below a
  590. subordinate reference. The subentry contains prescriptiveACI and
  591. is part of the shadowed information.
  592.  
  593.                          .
  594.  Etc.                   / \
  595.                        /   \
  596.                       /  o  \
  597.                      /  / \  \
  598. Replicated          /  /   \  \
  599. Area --------------/--/->   \  \
  600.                   /  /       \  \
  601.                  /  /         \  \
  602.                 /  /           \  \
  603. Subordinate    /__/_____________\__\
  604. knowledge--------/-> o   o     o \
  605.                 /   /           \ \
  606. Prescriptive---/-> o             o \
  607. ACI Subentries/                     \
  608.                 Unit of Replication
  609.  
  610.  
  611.              Etc.
  612.               o
  613.              / \
  614.             /   \
  615.            /     \
  616.           /       \
  617.          /         \
  618.         /           \
  619.        /_____________\
  620.         o    o     o
  621.        /            \
  622.       o              o
  623.     Shadowed Information
  624.  
  625. ADDITIONS TO FIGURE 3, SECTION 7.2, X.525
  626.  
  627.  
  628. IV) Add supporting text to section 7.2 in the paragraph after
  629. Figure 3. Insert after the sentence "Subordinate knowledge may
  630. also be replicated" the following sentences "Implicit in the Add
  631. supporting text to section 7.2 in the paragraph after Figure 3.
  632. Insert after the sentence subordinate knowledge is the access
  633. control information which governs access to the RDN of the
  634. subordinate knowledge. When the subordinate entry is an
  635.  
  636.                               Page 12
  637. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  638.  
  639. administrative point in another DSA, then part of this access
  640. control information may be held in prescriptiveACI subentries
  641. beneath the subordinate knowledge."
  642.  
  643. v) Add a new point d) to 9.2.4.1:
  644. "if subordinate knowledge (not extended knowledge) is shadowed
  645. then any prescriptiveACI in subordinate subentries shall also be
  646. copied."
  647.  
  648. Annex 3 Defect Report on 1997 Standard Proposing an Enhancement to
  649. the Shadowing Agreement in order to support 1 Level Searches in
  650. Shadow DSAs.
  651.  
  652. Nature of Defect:
  653.  
  654. The 1997 edition of the standard has allowed, for reasons of
  655. operational efficiency, one level Searches to be carried out in
  656. the superior DSA, when the actual entries are context prefixes in
  657. subordinate DSAs. The HOBs have been extended to allow this entry
  658. information to be carried up to the superior DSA. Unfortunately,
  659. we forgot to add the corresponding text to Part 9, so that shadow
  660. DSAs are able to copy this additional information from the
  661. supplier DSA. This defect report proposes the additional text for
  662. Part 9.
  663.  
  664. Solution Proposed by the Source:
  665.  
  666. All the following changes are to X.525|ISO 9594-9.
  667.  
  668. I) Section 9.2, add a new subordinates parameter to
  669. UnitOfReplication, viz:
  670.  
  671. UnitOfReplication   ::= SEQUENCE{
  672. area                AreaSpecification,
  673. attributes          AttributeSelection,
  674. knowledge           Knowledge OPTIONAL,
  675. subordinates        BOOLEAN DEFAULT FALSE }
  676.  
  677. subordinates is used to indicate that subordinate entries, rather
  678. than simply subordinate references, are to be copied to the
  679. consumer DSA. subordinates may only be TRUE if knowledge is
  680. requested and extendedKnowledge is FALSE.
  681.  
  682. II) Insert a new fourth paragraph (assuming previous defect for
  683. List was accepted) into 7.2.2.3:
  684.  
  685. "If subordinates is specified, then the supplier shall send
  686. subordinate entries rather than subordinate references, and the
  687. SDSEs will be of type subr, entry and cp. The subordinate entries
  688. will contain attributes according to the attribute selection.
  689.  
  690.                               Page 13
  691. draft-ietf-ids-root-naming-01.txt       Expires: March 20 1997
  692.  
  693. In addition, if the supplying DSE is of type admPoint, then the
  694. SDSE shall additionally be of type admPoint and the
  695. administrativeRole attribute shall be supplied. All appropriate
  696. subentries below the admPoint DSE shall also be supplied as SDSEs
  697. in the shadowed information."
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.                               Page 14
  743.  
  744.