idnits 2.17.1 draft-ietf-ids-root-naming-00.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-26) 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 453 lines 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 2 instances of too long lines in the document, the longest one being 47 characters in excess of 72. ** 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 408: '...subentries [2] SET OF SubentryInfo OPTIONAL...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 306 -- Looks like a reference, but probably isn't: '0' on line 255 -- Looks like a reference, but probably isn't: '3' on line 256 -- Looks like a reference, but probably isn't: '2' on line 408 ** Downref: Normative reference to an Historic RFC: RFC 1276 -- 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. 'NADF 7' -- Possible downref: Non-RFC (?) normative reference: ref. 'UK 142' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IDS Working Group David Chadwick 2 Internet-Draft University of Salford 3 DANTE IN PRINT 18 January 21 1996 4 draft-ietf-ids-root-naming-00.txt Expires: July 21 1996 6 Managing the X.500 Root Naming Context 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are 11 working documents of the Internet Engineering Task Force 12 (IETF), its areas, and its working groups. Note that other 13 groups may also distribute working documents as 14 Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months. Internet-Drafts may be updated, replaced, or 18 obsoleted by other documents at any time. It is not 19 appropriate to use Internet-Drafts as reference material or to 20 cite them other than as a ``working draft'' or ``work in 21 progress.'' 23 To learn the current status of any Internet-Draft, please 24 check the 1id-abstracts.txt listing contained in the 25 Internet-Drafts Shadow Directories on ds.internic.net, 26 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. 28 Abstract 30 The X.500 Standard [X.500 93] has the concept of first level 31 DSAs, whose administrators must collectively manage the root 32 naming context through bi-lateral agreements or other private 33 means which are outside the scope of the Standard. 35 The Paradise-NameFLOW X.500 service has an established 36 procedure for managing the root naming context, which 37 currently uses Quipu proprietary replication mechanisms and a 38 root DSA. The benefits that derive from this are twofold: 40 - firstly it is much easier to co-ordinate the management 41 of the root context information, when there is a central 42 point of administration, 44 - secondly the performance of one-level Search operations 45 is greatly improved because the Quipu distribution and 46 replication mechanism does not have a restriction that 47 exists in the 1988 and 1993 Standard. 49 The Paradise-NameFLOW project is moving towards 1993 Standard 50 replication protocols and wants to standardise the protocol 51 and procedure for managing the root naming context which will 52 be based on 1993 Standard protocols. Such a protocol and 53 procedure will be useful to private X.500 domains as well as 54 to the Internet X.500 public domain. It is imperative that 55 overall system performance is not degraded by this transition. 57 This document describes the use of 1993 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 60 are supplementary to that of the Standard. 62 Table of Contents 64 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . .3 66 2 Migration Plan . . . . . . . . . . . . . . . . . . . . . . . .3 68 3 Technical Solution . . . . . . . . . . . . . . . . . . . . . .4 70 4 Interim Solution . . . . . . . . . . . . . . . . . . . . . . .7 72 5 Security Considerations. . . . . . . . . . . . . . . . . . . .8 74 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .8 76 References . . . . . . . . . . . . . . . . . . . . . . . . . . .9 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . .9 80 Annex 1 Solution Text of Defect Reports submitted to ISO/ITU-T 81 by the UK . . . . . . . . . . . . . . . . . . . . . . . . 10 83 1 Introduction 85 The Paradise-NameFLOW service has a proprietary way of 86 managing the set of first level DSAs and the root naming 87 context. There is a single root DSA (Giant Tortoise) which 88 holds all of the country entries, and the country entries are 89 then replicated to every country (first level) DSA by Quipu 90 replication [RFC 1276] from the root DSA. The root DSA is not 91 a feature of the X.500 Standard [X.500 93]. It was introduced 92 because of the non-standard nature of the original Quipu 93 knowledge model (also described in RFC 1276). However, it does 94 have significant advantages both in managing the root naming 95 context and in the performance of one-level Searches of the 96 root. Performance is increased because each country DSA holds 97 all the entry information of every country. 99 By comparison, the 1988 Standard root context which is 100 replicated to all the country DSAs, only holds knowledge 101 information and a boolean (to say if the entry is an alias or 102 not) for each country entry. This is sufficient to perform a 103 List operation, but not a one-level Search operation. When 104 access controls were added to the 1993 Standard, the root 105 context information was increased (erroneously as it happens - 106 this is the subject of defect report 140 - see Annex 1) to 107 hold the access controls for each country entry, but a note in 108 the Standard restricted its use to the List operation, in 109 order to remain compatible with the 1988 edition of the 110 Standard. 112 2 Migration Plan 114 The Paradise-NameFLOW service is now migrating to 1993 115 Standard [X.500 93] conforming products, and it is essential 116 to replace the Quipu replication protocol with the 1993 117 shadowing and operational binding protocols, but without 118 losing the performance improvement that has been gained for 119 one-level Searches. 121 It is still the intention of the Paradise-NameFLOW service to 122 have one master root DSA. This root DSA will not support user 123 Directory operations via the DAP or the DSP, but each country 124 (first level) DSA will be able to shadow the root context from 125 this root DSA, using the DISP. Each first level DSA then only 126 needs to have one bi-lateral agreement, between itself and the 127 root DSA. This agreement will ensure that the first level DSA 128 keeps the root DSA up to date with its country level 129 information, and in turn, that the root DSA keeps the first 130 level DSA up to date with the complete root naming context. 131 When a new first level DSA comes on line, it only needs to 132 establish a bi-lateral agreement with the root DSA, in order 133 to obtain the complete root context. 135 This is a much easier configuration to manage than simply a 136 set of first level DSAs without a root DSA, as suggested in 137 the Standard. In this case each first level DSA must have bi-lateral agreements with all of the other first level DSAs. 138 When a new first level DSA comes on line, it must establish 139 agreements with all the existing first level DSAs. As the 140 number of first level DSAs grows, the process becomes 141 unmanageable. 143 However, it is also important to increase the amount of 144 information that is held about every country entry, so that a 145 one-level Search operation can be performed in each first 146 level DSA, without it needing to chain or refer the operation 147 to all the other first level DSAs (as is currently the case 148 with a Standard conformant system.) 150 3 Technical Solution 152 3.1 The solution is three-fold. Firstly, create a root DSA, 153 and establish hierarchical operational bindings between it and 154 each master first level DSA (3.2). Secondly, the Standard is 155 enhanced to allow extra information to be carried to the root 156 DSA via the HOB, and for this information to be used for one-level Search operations (3.3). Thirdly, each master first 157 level DSA enters into a shadowing agreement with the root DSA, 158 to shadow the enlarged root context information. In this way 159 each first level DSA is then capable of independently 160 performing List and one-level Search operations, and name 161 resolving to all other first level DSAs (3.4). 163 (Note 1. It is strongly recommended that non-specific 164 subordinate references should not be allowed in the root 165 context for efficiency reasons. This is directed by the 166 European functional standard [ENV 41215] and the NADF standing 167 document [NADF 7]. It is also preferred by the International 168 Standardized Profile [ISP 10615-6].) 170 (Note 2. It is recognised that manufacturers are taking a 171 phased approach to implementing the features of the 1993 172 Standard, and are usually implementing the DISP prior to the 173 DOP. For this reason, section 4 details an interim solution 174 that relies entirely on the DISP for populating the root DSA.) 176 3.2 Each master first level DSA will have a hierarchical 177 operational binding with the root DSA of the domain. Each 178 master first level DSA will master one or more first level 179 entries. The hierarchical operational binding will keep the 180 appropriate subordinate reference(s) (of category shadow and 181 master) up to date, as well as the other entry information 182 that is needed for one-level Search operations (such as access 183 controls, and attributes used in filtering). 185 Whilst hierarchical agreements are standardised, this 186 particular novel use of a HOB is not specifically recognised 187 in the Standard. Although the ASN.1 will support it, there is 188 no supporting text in the Standard. The following text 189 supplements that in the Standard, and describes how a first 190 level DSA may have a hierarchical operational binding with the 191 root DSA of its domain. 193 "Clause 24 of ISO/IEC 9594-4:1993 shall also apply when a 194 first level DSA is a subordinate DSA, and the root DSA of the 195 domain is the superior DSA. The naming context held by the 196 superior (root) DSA is the root naming context (or root 197 context - the terms are synonymous) of the domain. The root 198 context consists of the root entry of the DIT (which is empty) 199 plus a complete set of subordinate DSEs, one for each first 200 level naming context in the domain. The subordinate DSEs will 201 contain, in addition to specific knowledge attribute values of 202 category master and shadow, sufficient attributes, including 203 access control information, to allow List and one-level Search 204 operations to be performed on them. 206 In clause 24.1.2, the DistinguishedName of the 207 immediateSuperior component of HierarchicalAgreement shall be 208 null." 210 3.3 The ASN.1 of hierarchical operational bindings already 211 allows any attributes to be passed from the subordinate DSA to 212 the superior DSA (SubordinateToSuperior parameter in clause 213 24.1.4.2 of X.518). However, a note in the Standard limits 214 this to those which are required to perform a List operation. 215 The UK submitted a ballot comment to the PDAM on Minor 216 Extensions to OSI Directory Service to support User 217 Requirements, to remove this restriction, so that the 218 attributes may also be used for a one-level Search operation. 219 This amendment has been accepted, and the restriction has been 220 removed in the current Draft Amendment to the 1996 version of 221 the Standard [DAM User]. 223 1993 implementations of X.500 conforming to this RFC, shall 224 also remove this restriction. 226 3.4 Each master first level DSA will enter into a shadowing 227 agreement with the root DSA, for the purpose of shadowing the 228 root naming context. 230 The 1993 edition of the Standard explicitly recognises that 231 there can be master and shadow first level DSAs (X.501 Section 232 18.5). (The 1988 edition of the standard does not explicitly 233 recognise this, since it does not recognise shadowing.) A 234 shadow first level DSA holds a copy of the root context, 235 provided by a master first level DSA. In addition it holds 236 shadow copies of the (one or more) country entries that the 237 master first level DSA holds. There is currently an 238 outstanding defect report [UK 142] on the 1993 Standard to 239 clarify how a shadowing agreement is established between first 240 level DSAs. Once this has been ratified, the only additional 241 text needed in order to establish a shadowing agreement 242 between the root DSA and a master first level DSA is as 243 follows: 245 "When clause 9.2 of ISO/IEC 9594-9:1993 is applied to the 246 shadowing of the root context by a first level DSA from the 247 root DSA of a domain, then UnitOfReplication shall be set as 248 follows: 250 contextPrefix of AreaSpecification shall be null, 252 replicationArea of AreaSpecification shall be set to 253 SEQUENCE { 254 specificExclusions [1] SET OF { 255 chopBefore [0] FirstLevelEntry}, 256 maximum [3] 1 } 258 where FirstLevelEntry is the RDN of a first level entry (e.g. 259 country, locality or international organisation) held by the 260 master first level DSA. specificExclusions shall contain one 261 FirstLevelEntry for each first level entry mastered by this 262 DSA, 264 attributes of UnitofReplication shall be an empty SET OF 265 SEQUENCE, 267 knowledge of UnitofReplication shall be set to both (shadow 268 and master). 270 In other words, the information that will be replicated will 271 be an empty root entry plus all the attributes of the complete 272 set of subordinate DSEs of the root, excluding the DSEs that 273 the first level DSA already masters." 275 Note that the maximum component of replicationArea, although 276 not strictly necessary, is there for pragmatic reasons, for 277 example, where a community of users wish to use the root DSA 278 to hold some country specific entries. 280 4 Interim Solution 282 4.1 The interim solution may be of use to systems which do not 283 yet support the DOP for managing hierarchical operational 284 bindings. The interim solution comprises of two replacement 285 steps for HOB establishment between the root DSA and master 286 first level DSAs. Step one (4.2) allows the root DSA to shadow 287 first level entries from a master first level DSA. Step two 288 (4.3) requires either the root DSA administrator or the root 289 DSA implementation to massage the shadow first level entries 290 so that they appear to have been created by a HOB. Managing 291 the root context then continues as in 3.4 above. 293 4.2 The hierarchical operational binding between the root DSA 294 and a master first level DSA can be replaced by a set of 295 "spot" shadowing agreements, in which the first level DSA acts 296 as the supplier, and the root DSA as the consumer. Each "spot" 297 shadowing agreement replicates a first level entry which is 298 mastered by the first level DSA. The UnitOfReplication shall 299 be set as follows: 301 contextPrefix of AreaSpecification shall be FirstLevelEntry, 303 replicationArea of AreaSpecification shall be set to 304 SEQUENCE { 305 specificExclusions [1] SET OF { 306 chopAfter [1] {null} } } 308 where FirstLevelEntry is the Distinguished Name of a first 309 level entry (e.g. country, locality or international 310 organisation) held by the master first level DSA. 312 attributes of UnitofReplication shall be an empty SET OF 313 SEQUENCE, 315 knowledge of UnitofReplication shall be absent. 317 4.3 The root DSA administrator, or the root DSA implementation 318 (suitably tailored) must then administratively update each 319 shadowed first level entry, so that they appear to have been 320 created by a HOB, i.e. it is necessary to add a subordinate 321 reference to each one of them. The subordinate reference will 322 point to the respective master first level DSA, and will 323 comprise of a specific knowledge attribute, and the DSE bit of 324 type subr being set. The contents of the specific knowledge 325 attribute can be created from the contents of the supplier 326 knowledge attribute already present in the first level entry 327 and created by the "spot" shadowing agreement. 329 5 Security Considerations 331 Security considerations are not discussed in this memo. 333 6 Acknowledgements 335 The author would like to thank DANTE, without whose funding 336 this work would not have been possible. 338 The author would also like to thank Nexor, who reviewed the 339 document in detail and provided valuable comments, and who 340 first suggested the Interim Solution as a stop-gap measure 341 until the DOP is widely implemented. 343 References 345 [RFC 1276] Kille, S., "Replication and Distributed Operations 346 extensions to provide an Internet Directory using X.500", UCL, 347 November 1991. 349 [X.500 93] X.500 | 9594.Part 1 Overview of Concepts, Models 350 and Services 351 X.501 | 9594.Part 2 Models 352 X.511 | 9594.Part 3 Abstract Service Definition 353 X.518 | 9594.Part 4 Procedures for Distributed Operations 354 X.519 | 9594.Part 5 Protocol Specifications 355 X.520 | 9594.Part 6 Selected Attribute Types 356 X.521 | 9594.Part 7 Selected Object Classes 357 X.509 | 9594.Part 8 Authentication Framework 358 X.525 | 9594.Part 9 Replication 360 [ENV 41215] "Behaviour of DSAs for Distributed Operations", 361 European Pre-Standard, Dec 1992 363 [ISP 10615-6] "DSA Support of Distributed Operations", 5th 364 draft pDISP, Oct 1994 366 [NADF 7] SD-7 "Mapping the North American DIT onto Directory 367 Management Domains", North American Directory Forum, V 8.0, 368 Jan 1993 370 [UK 142] Defect report number 142, submitted by the UK to ISO, 371 March 1995. (Proposed solution text included in Annex 1) 373 [DAM User] Draft Amendments on Minor Extensions to OSI 374 Directory Service to support User Requirements, August 1995. 376 Author's Address 378 D W Chadwick 379 IT Institute 380 University of Salford 381 Salford 382 M5 4WT 383 England 384 Phone: +44 161 745 5351 385 Fax: +44 161 745 8169 386 E-mail: D.W.Chadwick@iti.salford.ac.uk 388 Annex 1 Solution Text of Defect Reports submitted to ISO/ITU-T 389 by the UK 391 Defect Report 140 393 Nature of Defect 395 In section 24.1.4.2 it is defined that the 396 SubordinateToSuperior parameter of a HOB can pass an entryInfo 397 parameter. This should contain entryACI which may be used in 398 the resolution of the List operation. 400 This is not correct as the prescriptive ACI from the relevant 401 subentries is also required in the superior DSA. 403 Solution Proposed by Source 405 It is proposed that the following is added to the 406 SubordinateToSuperior SEQUENCE of section 24.1.4.2 of X.518: 408 subentries [2] SET OF SubentryInfo OPTIONAL 410 This is used to pass the relevant subentries from the 411 subordinate to the superior. This is similar to the way 412 subentry information is passed in the SuperiorToSubordinate 413 parameter defined in 24.1.4.1. 415 Defect Report 142 417 Nature of Defect 419 The text which describes AreaSpecification in clause 9.2 of 420 X.525 is completely general. However, for the special case of 421 replicating first level knowledge references between first 422 level DSAs, a clarifying sentence should be added. 424 Solution Proposed by Source 426 In Section 9.2, under the ASN.1, after the description of 427 area, and before the description of SubtreeSpecification, add 428 the sentence: 430 "For the case where a DSA is shadowing first level 431 knowledge from a first level DSA, the contextPrefix 432 component is empty."