idnits 2.17.1 draft-ietf-ids-root-naming-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 468: '... subentries [2] SET OF SubentryInfo OPTIONAL...' RFC 2119 keyword, line 617: '...nowledge Knowledge OPTIONAL,...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 79 has weird spacing: '... Report on 1...' == Line 80 has weird spacing: '...ncement to t...' == Line 289 has weird spacing: '...quently a def...' == Line 396 has weird spacing: '...ew Palk from...' == Line 526 has weird spacing: '..."If subordina...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 305 -- Looks like a reference, but probably isn't: '0' on line 238 -- Looks like a reference, but probably isn't: '3' on line 239 -- Looks like a reference, but probably isn't: '2' on line 468 == Unused Reference: 'ISP 10615-6' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'RFC 1276' is defined on line 419, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ENV 41215' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISP 10615-6' -- Possible downref: Non-RFC (?) normative reference: ref. 'Mins' -- Possible downref: Non-RFC (?) normative reference: ref. 'NADF 7' ** Downref: Normative reference to an Historic RFC: RFC 1276 -- Possible downref: Non-RFC (?) normative reference: ref. 'UK 142' Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-ietf-ids-root-naming-01.txt Expires: March 20 1997 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 8 Managing the X.500 Root Naming Context 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months. Internet-Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use 20 Internet-Drafts as reference material or to cite them other than 21 as a "working draft" or "work in progress". 23 To learn the current status of any Internet-Draft, please check 24 the 1id-abstracts.txt listing contained in the Internet-Drafts 25 Shadow Directories on ds.internic.net, nic.nordu.net, 26 ftp.nisc.sri.com, or munnari.oz.au. 28 Abstract 30 The X.500 Standard [X.500 93] has the concept of first level DSAs, 31 whose administrators must collectively manage the root naming 32 context through bi-lateral agreements or other private means which 33 are outside the scope of the Standard. 35 The NameFLOW-Paradise X.500 service has an established procedure 36 for managing the root naming context, which currently uses Quipu 37 proprietary replication mechanisms and a root DSA. The benefits 38 that derive from this are twofold: 40 - firstly it is much easier to co-ordinate the management of 41 the root context information, when there is a central point 42 of administration, 44 - secondly the performance of one-level Search operations is 45 greatly improved because the Quipu distribution and 46 replication mechanism does not have a restriction that exists 47 in the 1988 and 1993 Standard. 49 The NameFLOW-Paradise project is moving towards 1993 ISO Standard 50 replication protocols and wants to standardise the protocol and 51 procedure for managing the root naming context which will be based 52 on 1993 Standard protocols. Such a protocol and procedure will be 53 useful to private X.500 domains as well as to the Internet X.500 54 public domain. It is imperative that overall system performance is 55 not degraded by this transition. 57 This document describes the use of 1993 ISO Standard protocols for 58 managing the root context. Whilst the ASN.1 is compatible with 59 that of the Standard, the actual settings of the parameters are 60 supplementary to that of the Standard. 62 Table of Contents 64 1 Introduction 2 65 2 Migration Plan 3 66 3 Technical Solutions 4 67 4 The Fast Track Solution 5 68 5 The Slower Track Solution 6 69 6 The Long Term Solution 7 70 7 Security Considerations 8 71 8 Acknowledgments 8 72 9 References 9 73 10 Author's Address 10 74 Annex 1 Solution Text of Defect Reports submitted to ISO/ITU- 75 T by the UK 10 76 Annex 2 Defect Report on 1993 Standard for Adding full ACIs 77 to DISP for Subordinate References, so that Secure List 78 Operation can be performed in Shadow DSAs 11 79 Annex 3 Defect Report on 1997 Standard Proposing an 80 Enhancement to the Shadowing Agreement in order to 81 support 1 Level Searches in Shadow DSAs. 13 83 1 Introduction 85 The NameFLOW-Paradise service has a proprietary way of managing 86 the set of first level DSAs and the root naming context. There is 87 a single root DSA (Giant Tortoise) which holds all of the country 88 entries, and the country entries are then replicated to every 89 country (first level) DSA and other DSAs by Quipu replication [RFC 90 1276] from the root DSA. In June 1996 there were 770 DSAs 91 replicating this information over the Internet. The root DSA is 92 not a feature of the X.500 Standard [X.500 93]. It was introduced 93 because of the non-standard nature of the original Quipu knowledge 94 model (also described in RFC 1276). However, it does have 95 significant advantages both in managing the root naming context 96 and in the performance of one-level Searches of the root. 97 Performance is increased because each country DSA holds all the 98 entry information of every country. 100 By comparison, the 1988 Standard root context which is replicated 101 to all the country DSAs, only holds knowledge information and a 102 boolean (to say if the entry is an alias or not) for each country 103 entry. This is sufficient to perform an insecure List operation, 104 but not a one-level Search operation. When access controls were 105 added to the 1993 Standard, the root context information was 106 increased (erroneously as it happens - this is the subject of 107 defect report 140 - see Annex 1) to hold the access controls for 108 each country entry, but a note in the Standard restricted its use 109 to the List operation, in order to remain compatible with the 1988 110 edition of the Standard. 112 2 Migration Plan 114 The NameFLOW-Paradise service is now migrating to 1993 Standard 115 [X.500 93] conforming products, and it is essential to replace the 116 Quipu replication protocol with the 1993 shadowing and operational 117 binding protocols, but without losing the performance improvement 118 that has been gained for one-level Searches. 120 It is still the intention of the NameFLOW-Paradise service to have 121 one master root DSA. This root DSA will not support user Directory 122 operations via the LDAP, the DAP or the DSP, but each country 123 (first level) DSA will be able to shadow the root context from 124 this root DSA, using the DISP. Each first level DSA then only 125 needs to have one bi-lateral agreement, between itself and the 126 root DSA. This agreement will ensure that the first level DSA 127 keeps the root DSA up to date with its country level information, 128 and in turn, that the root DSA keeps the first level DSA up to 129 date with the complete root naming context. When a new first level 130 DSA comes on line, it only needs to establish a bi-lateral 131 agreement with the root DSA, in order to obtain the complete root 132 context. 134 This is a much easier configuration to manage than simply a set of 135 first level DSAs without a root DSA, as suggested in the ISO 136 Standard. In the Standard case each first level DSA must have bi- 137 lateral agreements with all of the other first level DSAs. When a 138 new first level DSA comes on line, it must establish agreements 139 with all the existing first level DSAs. As the number of first 140 level DSAs grows, the process becomes unmanageable. 142 However, it is also important to increase the amount of 143 information that is held about every country entry, so that a one- 144 level Search operation can be performed in each first level DSA, 145 without it needing to chain or refer the operation to all the 146 other first level DSAs (as is currently the case with a Standard 147 conforming system.) 148 3 Technical Solutions 150 0.1 The solution at first appears to be relatively straight 151 forward, and involves two steps. Firstly, create a root DSA, and 152 establish hierarchical operational bindings using the DOP, between 153 it and each master first level DSA. Secondly, each master first 154 level DSA enters into a shadowing agreement with the root DSA, to 155 shadow the enlarged root context information. In this way each 156 first level DSA is then capable of independently performing List 157 and one-level Search operations, and name resolving to all other 158 first level DSAs. 160 3.2 Unfortunately there are a number of complications that inhibit 161 a quick implementation of this solution. Firstly, few DSA 162 suppliers have implemented the DOP. Secondly there are several 163 defects in the Standard that currently stop the above solution 164 from working. 166 3.3 At a meeting chaired by DANTE in the UK on 18 June 1996[Mins], 167 at which several DSA suppliers were present, the following 168 pragmatic technical solution was proposed. This comprises a fast 169 track partial solution and a slower track fuller solution. Both 170 the fast and slower tracks use the shadowing protocol (DISP) for 171 both steps of the solution, and do not rely on the DOP to 172 establish HOBs. The fast track solution, described in section 4, 173 will support knowledge distribution of the root context, and the 174 (insecure) List operation of the root's subordinates. The List 175 operation will be insecure because access control information will 176 not be present in the shadow DSEs. (However, since it is generally 177 thought that first level entries, in particular country entries, 178 are publicly accessible, this is not considered to be a serious 179 problem.) Suppliers expect to have the fast track solution 180 available before the end of 1996. The slower track solution, 181 described in section 5, will in addition support fully secure one 182 level Search and List operations of the root (without the need to 183 chain to the master DSAs). Suppliers at the DANTE meeting did not 184 realistically expect this to be in their products much sooner than 185 mid 1998. 187 3.4 The long term solution, which relies on the DOP to establish 188 HOBs, is described in section 6 of this document. 190 (Note. It is strongly recommended that non-specific subordinate 191 references should not be allowed in the root context for 192 efficiency reasons. This is directed by the European functional 193 standard [ENV 41215] and the NADF standing document [NADF 7]. It 194 is also preferred by the International Standardized Profile [ISP 195 10615-6].) 196 4 The Fast Track Solution 198 4.1 The fast track solution provides root knowledge collection and 199 insecure List operations for first level DSAs, and will be of use 200 to systems which do not yet support the DOP for managing 201 hierarchical operational bindings. The fast track solution relies 202 upon the DISP with very few changes to the 1993 edition of the 203 Standard. 205 4.2 Each master first level DSA administrator will make available 206 to the administrator of the root DSA, sufficient information to 207 allow the root DSA to configure a subordinate reference to their 208 DSA. In the simplest case, this can be via a telephone call, and 209 the information comprises the access point of their DSA and the 210 RDNs of the first level entries that they master. 212 4.3 Each master first level DSA enters into a shadowing agreement 213 with the root DSA, for the purpose of shadowing the root naming 214 context. 216 The 1993 edition of the Standard explicitly recognises that there 217 can be master and shadow first level DSAs (X.501 Section 18.5). 218 (The 1988 edition of the standard does not explicitly recognise 219 this, since it does not recognise shadowing.) A shadow first level 220 DSA holds a copy of the root context, provided by a master first 221 level DSA. In addition it holds shadow copies of the (one or more) 222 country entries that the master first level DSA holds. There is 223 currently an outstanding defect report [UK 142] on the 1993 224 Standard to clarify how a shadowing agreement is established 225 between first level DSAs. Once this has been ratified, the only 226 additional text needed in order to establish a shadowing agreement 227 between the root DSA and a master first level DSA is as follows: 229 "When clause 9.2 of ISO/IEC 9594-9:1993 is applied to the 230 shadowing of the root context by a first level DSA from the root 231 DSA of a domain, then UnitOfReplication shall be set as follows: 233 contextPrefix of AreaSpecification shall be null, 235 replicationArea of AreaSpecification shall be set to 236 SEQUENCE { 237 specificExclusions [1] SET OF { 238 chopBefore [0] FirstLevelEntry}, 239 maximum [3] 1 } 241 where FirstLevelEntry is the RDN of a first level entry (e.g. 242 country, locality or international organisation) held by the 243 master first level DSA. specificExclusions shall contain one 244 FirstLevelEntry for each first level entry mastered by this DSA, 246 attributes of UnitofReplication shall be an empty SET OF SEQUENCE, 248 knowledge of UnitofReplication shall be set to both (shadow and 249 master). 251 In other words, the information that will be replicated will be an 252 empty root entry plus all the attributes of the complete set of 253 subordinate DSEs of the root that are held in the root DSA 254 excluding the DSEs that the first level DSA already masters, plus 255 a complete set of subordinate reference." 257 Note that the maximum component of replicationArea, although not 258 strictly necessary, is there for pragmatic reasons, for example, 259 where a community of users wish to use the root DSA to hold some 260 country specific entries. 262 5 The Slower Track Solution 264 5.1 The slower track solution provides support for fully secure 265 one level Search and List operations of the root in first level 266 DSAs, and comprises of two steps for HOB establishment between the 267 root DSA and master first level DSAs, using the DISP instead of 268 the DOP. Step one, described in 5.3, allows the root DSA to shadow 269 first level entries from a master first level DSA. Step two, 270 described in 5.4, requires either the root DSA administrator or 271 the root DSA implementation to massage the shadow first level 272 entries so that they appear to have been created by a HOB. 273 Managing the root context then continues as in 4.3 above. 275 5.2 This solution requires two significant defects in the ISO 276 Standard to be corrected. Firstly, access control information 277 needs to be added to subordinate references in the DISP to allow 278 the List operation to work securely in a shadowed DSA. (The ACI 279 are held in both the subr DSE and in its subentry.) This requires 280 a defect report on the 93 standard to be submitted. The text of 281 this defect report (that has been submitted to ISO) is given in 282 Annex 2. 284 Secondly, a new type of shadowing agreement will need to be 285 established between the supplier and consumer DSAs, to copy 286 subordinate entries rather than simply subordinate references, so 287 that one level Search operations can work in the shadowing DSA. 288 This procedure should have been part of the 1997 edition of the 289 standard, but due to an omission is not. Consequently a defect 290 report on the 1997 Standard has been submitted. The text of this 291 defect report is given in Annex 3. 293 5.3 The hierarchical operational binding between the root DSA and 294 a master first level DSA can be replaced by a set of "spot" 295 shadowing agreements, in which the first level DSA acts as the 296 supplier, and the root DSA as the consumer. Each "spot" shadowing 297 agreement replicates a first level entry which is mastered by the 298 first level DSA. The UnitOfReplication shall be set as follows: 300 contextPrefix of AreaSpecification shall be FirstLevelEntry, 302 replicationArea of AreaSpecification shall be set to 303 SEQUENCE { 304 specificExclusions [1] SET OF { 305 chopAfter [1] {null} } } 307 where FirstLevelEntry is the Distinguished Name of a first level 308 entry (e.g. country, locality or international organisation) held 309 by the master first level DSA. 311 attributes of UnitofReplication shall be an empty SET OF SEQUENCE, 313 knowledge of UnitofReplication shall be absent. 315 5.4 The root DSA administrator, or the root DSA implementation 316 (suitably tailored) must then administratively update each 317 shadowed first level entry, so that they appear to have been 318 created by a HOB, i.e. it is necessary to add a subordinate 319 reference to each one of them. The subordinate reference will 320 point to the respective master first level DSA, and will comprise 321 of a specific knowledge attribute, and the DSE bit of type subr 322 being set. The contents of the specific knowledge attribute can be 323 created from the contents of the supplier knowledge attribute 324 already present in the first level entry and created by the "spot" 325 shadowing agreement. 327 6 The Long Term Solution 329 6.1 Each master first level DSA will have a hierarchical 330 operational binding with the root DSA of the domain. Each master 331 first level DSA will master one or more first level entries. The 332 hierarchical operational binding will keep the appropriate 333 subordinate reference(s) (of category shadow and master) up to 334 date, as well as the other entry information that is needed for 335 one-level Search operations (such as access controls, and 336 attributes used in filtering). 338 Whilst hierarchical agreements are standardised, this particular 339 novel use of a HOB is not specifically recognised in the Standard. 340 Although the ASN.1 will support it, there is no supporting text in 341 the Standard. The following text supplements that in the Standard, 343 draft-ietf-ids-root-naming-01.txt Expires: March 20 1997 345 and describes how a first level DSA may have a hierarchical 346 operational binding with the root DSA of its domain. 348 "Clause 24 of ISO/IEC 9594-4:1993 shall also apply when a first 349 level DSA is a subordinate DSA, and the root DSA of the domain is 350 the superior DSA. The naming context held by the superior (root) 351 DSA is the root naming context (or root context - the terms are 352 synonymous) of the domain. The root context consists of the root 353 entry of the DIT (which is empty) plus a complete set of 354 subordinate DSEs (i.e. first level DSEs), one for each first level 355 naming context in the domain, and their corresponding subentries. 356 The first level DSEs and their subentries will contain, in 357 addition to specific knowledge attribute values of category master 358 and shadow, sufficient attributes and collective attributes, 359 including access control information, to allow List and one-level 360 Search operations to be performed on them. 362 In clause 24.1.2, the DistinguishedName of the immediateSuperior 363 component of HierarchicalAgreement shall be null." 365 6.2 The ASN.1 of hierarchical operational bindings already allows 366 any attributes to be passed from the subordinate DSA to the 367 superior DSA (SubordinateToSuperior parameter in clause 24.1.4.2 368 of X.518). However, a note in the 1993 edition of the Standard 369 limits this to those which are required to perform a List 370 operation. In the 1997 edition of the Standard [DAM User] this 371 restriction has been removed, so that the attributes may also be 372 used for a one-level Search operation. 374 1993 implementations of X.500 conforming to this RFC, shall also 375 remove this restriction. 377 7 Security Considerations 379 Security considerations are discussed in this memo in relation to 380 List and one-level Search operations. Each DSE has access control 381 information associated with it, and these must be adhered to when 382 the operations are performed. 384 8 Acknowledgments 386 The author would like to thank DANTE, without whose funding this 387 work would not have been possible. 389 The author would also like to thank Nexor, who reviewed the first 390 version of this document in detail and provided valuable comments, 391 and who first suggested the use of the DISP as a pragmatic 392 solution for HOB establishment until the DOP becomes widely 393 implemented. 395 The author would also like to thank John Farrell from the ISODE 396 Consortium, Andrew Palk from Digital and Keith Richardson from 397 ICL who attended the DANTE meeting, and contributed to the 398 technical contents of the defect reports in Annexes 2 and 3. 400 9 References 402 [DAM User] Draft Amendments on Minor Extensions to OSI Directory 403 Service to support User Requirements, August 1995. 405 [ENV 41215] "Behaviour of DSAs for Distributed Operations", 406 European Pre-Standard, Dec 1992 408 [ISP 10615-6] "DSA Support of Distributed Operations", 5th draft 409 pDISP, Oct 1994 411 [Mins] "Notes of DANTE meeting to discuss Managing the Root Naming 412 Context. 18 June 1996." D W Chadwick, circulated to IDS mailing 413 list 415 [NADF 7] SD-7 "Mapping the North American DIT onto Directory 416 Management Domains", North American Directory Forum, V 8.0, Jan 417 1993 419 [RFC 1276] Kille, S., "Replication and Distributed Operations 420 extensions to provide an Internet Directory using X.500", UCL, 421 November 1991. 423 [UK 142] Defect report number 142, submitted by the UK to ISO, 424 March 1995. (Proposed solution text included in Annex 1) 426 [X.500 93] X.500 | 9594.Part 1 Overview of Concepts, Models and 427 Services 428 X.501 | 9594.Part 2 Models 429 X.511 | 9594.Part 3 Abstract Service Definition 430 X.518 | 9594.Part 4 Procedures for Distributed Operations 431 X.519 | 9594.Part 5 Protocol Specifications 432 X.520 | 9594.Part 6 Selected Attribute Types 433 X.521 | 9594.Part 7 Selected Object Classes 434 X.509 | 9594.Part 8 Authentication Framework 435 X.525 | 9594.Part 9 Replication 436 10 Author's Address 438 D W Chadwick 439 IT Institute 440 University of Salford 441 Salford 442 M5 4WT 443 England 444 Phone: +44 161 745 5351 445 Fax: +44 161 745 8169 446 E-mail: D.W.Chadwick@iti.salford.ac.uk 448 Annex 1 Solution Text of Defect Reports submitted to ISO/ITU-T by 449 the UK 451 Defect Report 140 453 Nature of Defect 455 In section 24.1.4.2 it is defined that the SubordinateToSuperior 456 parameter of a HOB can pass an entryInfo parameter. This should 457 contain entryACI which may be used in the resolution of the List 458 operation. 460 This is not correct as the prescriptive ACI from the relevant 461 subentries is also required in the superior DSA. 463 Solution Proposed by Source 465 It is proposed that the following is added to the 466 SubordinateToSuperior SEQUENCE of section 24.1.4.2 of X.518: 468 subentries [2] SET OF SubentryInfo OPTIONAL 470 This is used to pass the relevant subentries from the subordinate 471 to the superior. This is similar to the way subentry information 472 is passed in the SuperiorToSubordinate parameter defined in 473 24.1.4.1. 475 Defect Report 142 477 Nature of Defect 479 The text which describes AreaSpecification in clause 9.2 of X.525 480 is completely general. However, for the special case of 481 replicating first level knowledge references between first level 482 DSAs, a clarifying sentence should be added. 484 Solution Proposed by Source 486 In Section 9.2, under the ASN.1, after the description of area, 487 and before the description of SubtreeSpecification, add the 488 sentence: 490 "For the case where a DSA is shadowing first level knowledge 491 from a first level DSA, the contextPrefix component is 492 empty." 494 Annex 2 Defect Report on 1993 Standard for Adding full ACIs to 495 DISP for Subordinate References, so that Secure List Operation can 496 be performed in Shadow DSAs 498 Nature of Defect: 500 The List operation may be carried out in a superior DSA using 501 subordinate reference information, providing that the fromEntry 502 flag is set to false in the response. However, in order to do this 503 securely, complete access control information is needed for the 504 RDN of the subordinate entry. The existing text assumes that this 505 is held in entry ACI (e.g. see 9.2.4.1 c) or in prescriptive ACI 506 held in subentries above the DSE (e.g. see 9.2.4.1 b). In the case 507 of a subordinate reference, the prescriptive ACI may be held below 508 the DSE, if the subordinate reference points to a new 509 administrative point. The shadowing document needs to make it 510 clear that this can be the case, and needs to allow for this 511 additional access control information to be shadowed. 513 A related defect report (140) has already suggested that this same 514 omission should be added to operational bindings. 516 Solution Proposed by the Source: 518 All the following changes are to X.525|ISO 9594-9. 520 I) Insert the following text into 7.2.2.3, at the end of both the 521 second paragraph and the first sentence of the third paragraph 522 (after "appropriate knowledge"): 523 "and access control information." 525 II) Insert a new third paragraph into 7.2.2.3: 526 "If subordinate knowledge is supplied, and the supplying DSE (of 527 type subr) is also of type admPoint, then the SDSE shall 528 additionally be of type admPoint and the administrativeRole 529 attribute shall be supplied. If such a DSE has any immediately 530 subordinate subentries containing PrescriptiveACI relating to the 531 administrative point, then they shall also be supplied as SDSEs in 532 the shadowed information. 534 Note. A DSE can be of type subr and admPoint in a superior DSA, 535 when the naming context in the subordinate DSA is the start of a 536 new administrative area." 538 III) Update figure 3 to show a subentry immediately below a 539 subordinate reference. The subentry contains prescriptiveACI and 540 is part of the shadowed information. 542 . 543 Etc. / \ 544 / \ 545 / o \ 546 / / \ \ 547 Replicated / / \ \ 548 Area --------------/--/-> \ \ 549 / / \ \ 550 / / \ \ 551 / / \ \ 552 Subordinate /__/_____________\__\ 553 knowledge--------/-> o o o \ 554 / / \ \ 555 Prescriptive---/-> o o \ 556 ACI Subentries/ \ 557 Unit of Replication 559 Etc. 560 o 561 / \ 562 / \ 563 / \ 564 / \ 565 / \ 566 / \ 567 /_____________\ 568 o o o 569 / \ 570 o o 571 Shadowed Information 573 ADDITIONS TO FIGURE 3, SECTION 7.2, X.525 575 IV) Add supporting text to section 7.2 in the paragraph after 576 Figure 3. Insert after the sentence "Subordinate knowledge may 577 also be replicated" the following sentences "Implicit in the Add 578 supporting text to section 7.2 in the paragraph after Figure 3. 579 Insert after the sentence subordinate knowledge is the access 580 control information which governs access to the RDN of the 581 subordinate knowledge. When the subordinate entry is an 582 administrative point in another DSA, then part of this access 583 control information may be held in prescriptiveACI subentries 584 beneath the subordinate knowledge." 586 v) Add a new point d) to 9.2.4.1: 587 "if subordinate knowledge (not extended knowledge) is shadowed 588 then any prescriptiveACI in subordinate subentries shall also be 589 copied." 591 Annex 3 Defect Report on 1997 Standard Proposing an Enhancement to 592 the Shadowing Agreement in order to support 1 Level Searches in 593 Shadow DSAs. 595 Nature of Defect: 597 The 1997 edition of the standard has allowed, for reasons of 598 operational efficiency, one level Searches to be carried out in 599 the superior DSA, when the actual entries are context prefixes in 600 subordinate DSAs. The HOBs have been extended to allow this entry 601 information to be carried up to the superior DSA. Unfortunately, 602 we forgot to add the corresponding text to Part 9, so that shadow 603 DSAs are able to copy this additional information from the 604 supplier DSA. This defect report proposes the additional text for 605 Part 9. 607 Solution Proposed by the Source: 609 All the following changes are to X.525|ISO 9594-9. 611 I) Section 9.2, add a new subordinates parameter to 612 UnitOfReplication, viz: 614 UnitOfReplication ::= SEQUENCE{ 615 area AreaSpecification, 616 attributes AttributeSelection, 617 knowledge Knowledge OPTIONAL, 618 subordinates BOOLEAN DEFAULT FALSE } 620 subordinates is used to indicate that subordinate entries, rather 621 than simply subordinate references, are to be copied to the 622 consumer DSA. subordinates may only be TRUE if knowledge is 623 requested and extendedKnowledge is FALSE. 625 II) Insert a new fourth paragraph (assuming previous defect for 626 List was accepted) into 7.2.2.3: 628 "If subordinates is specified, then the supplier shall send 629 subordinate entries rather than subordinate references, and the 630 SDSEs will be of type subr, entry and cp. The subordinate entries 631 will contain attributes according to the attribute selection. 633 In addition, if the supplying DSE is of type admPoint, then the 634 SDSE shall additionally be of type admPoint and the 635 administrativeRole attribute shall be supplied. All appropriate 636 subentries below the admPoint DSE shall also be supplied as SDSEs 637 in the shadowed information."