home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1276 < prev    next >
Text File  |  1991-11-28  |  34KB  |  947 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                            S.E. Hardcastle-Kille
  8. Requests for Comments 1276                   University College London
  9.                                                          November 1991
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.           Replication and Distributed Operations extensions
  17.              to provide an Internet Directory using X.500
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25. Status of this Memo
  26.     This RFC specifies an IAB standards track protocol for the
  27.     Internet community, and requests discussion and suggestions for
  28.     improvements.  Please refer to the current edition of the ``IAB
  29.     Official Protocol Standards'' for the standardization state and
  30.     status of this protocol.  Distribution of this memo is unlimited.
  31.  
  32. Abstract
  33.     Some requirements on extensions to X.500 are described in the
  34.     RFC[HK91b], in order to build an Internet Directory using
  35.     X.500(1988).  This document specifies a set of solutions to the
  36.     problems raised.  These solutions are based on some work done for
  37.     the QUIPU implementation, and demonstrated to be effective in a
  38.     number of directory pilots.  By documenting a de facto standard,
  39.     rapid progress can be made towards a full-scale pilot.  These
  40.     procedures are an INTERIM approach.  There are known
  41.     deficiencies, both in terms of manageability and scalability.
  42.     Transition to standard approaches are planned when appropriate
  43.     standards are available.  This RFCwill be obsoleted at this
  44.     point.
  45.  
  46.  
  47.  
  48.  
  49. RFC 1276         Internet Directory Replication          November 1991
  50.  
  51.  
  52. Contents
  53.  
  54. 1   Approach                                                         2
  55.  
  56. 2   Extensions to Distributed Operations                             3
  57.  
  58.  
  59. 3   Alternative DSAs                                                 4
  60.  
  61. 4   Data Model                                                       5
  62.  
  63.  
  64. 5   DSA Naming                                                       6
  65.  
  66. 6   Knowledge Representation                                         6
  67.  
  68. 7   Replication Protocol                                             9
  69.  
  70.  
  71. 8   New Application Context                                         12
  72.  
  73. 9   Policy on Replication Procedures                                12
  74.  
  75.  
  76. 10  Use of the Directory by Applications                            12
  77.  
  78. 11  Migration and Scaling                                           12
  79.  
  80. 12  Security Considerations                                         13
  81.  
  82.  
  83. 13  Author's Address                                                13
  84.  
  85. A   ASN.1 Summary and Object Identifier Allocation                  14
  86.  
  87.  
  88. List of Figures
  89.  
  90.     1      Knowledge Attributes  .   .   .   .   .   .   .   .       8
  91.  
  92.     2      Replication Protocol  .   .   .   .   .   .   .   .      10
  93.     3      Summary of the ASN.1  .   .   .   .   .   .   .   .      17
  94.  
  95.  
  96.  
  97. Hardcastle-Kille                                                Page 1
  98.  
  99.  
  100.  
  101.  
  102. RFC 1276         Internet Directory Replication          November 1991
  103.  
  104.  
  105. 1  Approach
  106.  
  107. There are a number of non-negotiable requirements which must be met
  108. before a directory can be deployed on the Internet [HK91b].  These
  109. problems are being tackled in the standards arena, but there is
  110. currently no stable solution.  One approach would be to attempt to
  111. intercept the standard.  Difficulties with this would be:
  112.  
  113.  
  114.  o  Defining a coherent intercept would be awkward, and the effort
  115.     would probably be better devoted to working on the standard.  It
  116.     is not even clear that such an intercept could be defined.
  117.  
  118.  o  The target is moving, and it is always tempting to track it, thus
  119.     causing more delay.
  120.  
  121.  o  There would be a delay involved with this approach.  It would be
  122.     too late to be useful for a rapid start, and sufficiently close to
  123.     the timing of the final standard that many would choose not to
  124.     implement it.
  125.  
  126. Therefore, we choose to take a simple approach.  This is a good deal
  127. simpler than the full X.500 approach, and is based on operational
  128. experience.  The advantages of this approach are:
  129.  
  130.  
  131.  o  It is proven in operation.  This RFCis simply documenting what is
  132.     being done already.
  133.  
  134.  o  There will be a minimum of delay in starting to use the approach.
  135.  
  136.  o  The approach is simpler, and so the cost of implementation is much
  137.     less.  It will therefore be much more attractive to add into an
  138.     implementation, as it is less effort, and can be further ahead of
  139.     the standard.
  140.  
  141. These procedures are an INTERIM approach.  There are known
  142. deficiencies, both in terms of manageability and scalability.
  143. Transition to standard approaches are planned when appropriate
  144. standards are available.  This RFCwill be obsoleted at this point.
  145.  
  146.  
  147.  
  148.  
  149.  
  150. Hardcastle-Kille                                                Page 2
  151.  
  152.  
  153.  
  154.  
  155. RFC 1276         Internet Directory Replication          November 1991
  156.  
  157.  
  158. 2  Extensions to Distributed Operations
  159.  
  160. The distributed operations of X.500 assume that all DUAs and DSAs are
  161. fully interconnected with a global network service.  For the Internet
  162. Pilot, this assumption is invalid.  DSAs may be operated over TCP/IP,
  163. TP4/CLNS, or TP0/CONS.
  164. The extension to distributed operations to support this situation is
  165. straightforward.  We define the term community as an environment where
  166. direct (network) communication is possible.  Communities may be
  167. separated because they operate different protocols, or because of lack
  168. of physical connectivity.  Example communities are the DARPA/NSF
  169. Internet, and the Janet private X.25 network.  A network entity in a
  170. community is addressed by its Network Address.  If two network
  171. entities are in the same community, they can by definition
  172. communicate.  A community is identified by a set of network address
  173. prefixes.  For the approach to be useful, this set should be small
  174. (typically 1).  For TCP/IP Networks, and X.25 Networks not providing
  175. CONS, the approach is described in [HK91a] allows for communities to
  176. be defined for the networks of operational interest.
  177.  
  178. This model can be used to determine whether a pair of application
  179. entities can communicate.  For each entity, determine the presentation
  180. address (typically by directory lookup).  Each network address in the
  181. presentation address will have a single associated community.  The set
  182. of communities to which each application entity belongs can thus be
  183. determined.  If the two application entities have a common community,
  184. then they can communicate directly.
  185. Two extensions to the standard distributed operations are needed.
  186.  
  187.  
  188. 1.  Consider a DSA (the local DSA) which is contacted by either a DUA
  189.     or DSA (the calling entity) to resolve a query.  The local DSA
  190.     determines that the query must be progressed by another DSA (the
  191.     referred-to DSA). The DSA will make a chain/referral choice.  If
  192.     chaining is prohibited by service control, a referral will be
  193.     passed back.  Otherwise, if the local DSA prefers to chain (e.g.,
  194.     for policy reasons) it will then chain.  The remaining situation
  195.     is that the local DSA prefers to give a referral.  It shall only
  196.     do so if it believes that the calling entity can directly connect
  197.     to the referred-to DSA. If the calling entity is a DUA, it should
  198.     be assumed to belong only to the community of the called network
  199.     address.  If the calling entity is a DSA, its communities should
  200.     be determined by lookup of the DSA's presentation address in the
  201.     directory.  The communities of the referred-to DSA can be
  202.  
  203. Hardcastle-Kille                                                Page 3
  204.  
  205.  
  206.  
  207.  
  208. RFC 1276         Internet Directory Replication          November 1991
  209.  
  210.  
  211.     determined from its presentation address, which will either be
  212.     present in the reference or can be looked up in the directory.  If
  213.     the calling entity and the referred-to DSA do not have a common
  214.     community, then chaining shall be used.  Otherwise, a referral may
  215.     be passed back to the calling entity.
  216.  
  217. 2.  Consider that a DSA (or DUA), termed here the local entity is
  218.     following a referral (to a referred-to DSA). In some cases, the
  219.     local entity and referred-to DSA will not be able to communicate
  220.     directly (i.e., not have a common community).  There are two
  221.     approaches to solve this:
  222.  
  223.    (a)  Pass the query to a DSA it would use to resolve a query for
  224.         the entry one level higher in the DIT. This will work,
  225.         provided that this DSA follows this specification.  This
  226.         default mechanism will work without additional configuration.
  227.  
  228.    (b)  Use a ``relay DSA'' to access the community.  A relay DSA is
  229.         one which can chain the query on to the remote community.  The
  230.         relay DSA must belong to both the remote community and to at
  231.         least one community to which the local entity belongs.  The
  232.         choice of relay DSA for a given community will be manually
  233.         configured by a DSA manager to enable access to a community to
  234.         which there is not direct connectivity.  Typically this will
  235.         be used where the default DSA is a poor choice (e.g., because
  236.         relaying is not authorised through this DSA).
  237.  
  238.     A DSA conforming to this specification shall follow these
  239.     procedures.  A DUA may also follow these procedures, and this will
  240.     give improvements in some circumstances (i.e., the ability to
  241.     resolve certain queries without use of chaining).  However, this
  242.     specification does not place requirements on DUAs.
  243.  
  244.  
  245. 3  Alternative DSAs
  246.  
  247. There is a need to give information on slave copies of data.  This can
  248. be done using the standard protocol, but modifying the semantics.
  249. This relies on the fact that there may only be a single subordinate
  250. reference or cross reference.
  251.  
  252. If there is a need to include references to master and slave data (EDB
  253. copies) in a referral, then this should be done in a referral by
  254. specifying a subordinate reference with multiple values.  This cannot
  255.  
  256. Hardcastle-Kille                                                Page 4
  257.  
  258.  
  259.  
  260.  
  261. RFC 1276         Internet Directory Replication          November 1991
  262.  
  263.  
  264. be a standard subordinate reference, which would only have a single
  265. value.  Therefore, this usage does not conflict with standard
  266. references.  The first reference is the master copy, and subsequent
  267. references are slave copies.
  268.  
  269.  
  270. 4  Data Model
  271.  
  272. The X.500 data model takes the unit of mastering data as the entry.  A
  273. DSA may hold an arbitrary collection of entries.  We restrict this
  274. model so that for the replication protocol defined in this
  275. specification the base unit of replication (shadowing) is the complete
  276. set of immediate subordinate entries of a given entry, termed an Entry
  277. Data Block (EDB). An EDB is named by its parent entry.  It contains
  278. the relative distinguished names of all of the children of the entry,
  279. and each of the child entries.  For each entry, this comprises all
  280. attributes of the entry, the relative distinguished name, and
  281. knowledge information associated with the entry.  If a DSA holds
  282. (non-cached) information on an entry, it will hold information on all
  283. of its siblings.  One DSA will hold a master EDB. This will contain
  284. two types of entry:
  285.  
  286. 1.  Entries for which this DSA is the master.
  287.  
  288. 2.  Slave copies of entries which are mastered in another DSA,
  289.     indicated by a subordinate reference.  This copy must be
  290.     maintained automatically by the DSA holding the master EDB.
  291.  
  292.  
  293. Thus the master EDB contains a mixture of master entries, and entries
  294. which are mastered elsewhere and shadowed by the DSA holding the
  295. master EDB on an entry by entry basis.  Other DSAs may hold slave
  296. copies of this EDB (slave EDBs), which are replicated in their
  297. entirity directly or indirectly from the master EDB. This approach has
  298. the following advantages.
  299.  
  300.  o  Name resolution is simplified, and performance improved.
  301.  
  302.  o  Single level searching and listing have good performance, and are
  303.     straightforward to implement.  In a more general case of applying
  304.     the standard, without sophisticated replication, these operations
  305.     might require to access very many DSAs and be prohibitively
  306.     expensive.
  307.  
  308.  
  309. Hardcastle-Kille                                                Page 5
  310.  
  311.  
  312.  
  313.  
  314. RFC 1276         Internet Directory Replication          November 1991
  315.  
  316.  
  317. 5  DSA Naming
  318.  
  319. All DSAs must be named in the DIT, and the master definition of the
  320. presentation address stored in this entry.  X.500 (including some of
  321. the extension work) implies that the presentation address information
  322. is extensively replicated (manually).  The management overhead implied
  323. by this is not acceptable.
  324. Care must be taken to prevent deadlock in determining a DSAs address.
  325. This is solved by:
  326.  
  327.  
  328. 1.  Use of a well known DSA with ``root knowledge''
  329.  
  330. 2.  Naming DSAs in a manner which prevents deadlocks.  Currently this
  331.     is done by giving DSAs names high in the DIT.
  332.  
  333. The Internet Pilot will need to define detailed policies for naming
  334. DSAs, in conjunction with the replication policy.  This will be
  335. defined in a future RFC.
  336.  
  337.  
  338. 6  Knowledge Representation
  339.  
  340.  
  341. Knowledge information is represented in the DIT. It seems unreasonable
  342. to manage this by any other means.  Knowledge information is
  343. represented in an entry by use of knowledge attributes.  These
  344. attributes are considered separately from all the other attributes in
  345. the entry which are termed ``user attributes''.  Each entry in a
  346. master EDB will be in one of four categories.
  347.  
  348. 1.  The entry is a leaf entry mastered in this EDB, and so only
  349.     contains user attributes
  350.  
  351. 2.  The level below has an associated EDB (i.e., the DIT continues
  352.     downwards to use the data model of this specification).  All
  353.     attributes of this entry will be mastered in this entry.  The
  354.     entry will contain an attribute with the name of the DSA which
  355.     holds the master of the associated EDB. Optionally, it will
  356.     contain an attribute holding the names of DSAs which hold slave
  357.     EDBs.  The entry may not hold a subordinate reference attribute.
  358.     The DIT is followed by use of the master and slave attributes.
  359.  
  360.  
  361.  
  362. Hardcastle-Kille                                                Page 6
  363.  
  364.  
  365.  
  366.  
  367. RFC 1276         Internet Directory Replication          November 1991
  368.  
  369.  
  370. 3.  The entry is mastered in a DSA which does not follow this
  371.     specification.  The entry in the EDB will contain a master
  372.     attribute, which holds a subordinate reference (or cross
  373.     reference) to the DSA which holds the master entry.  The user
  374.     attributes of the entry will be mastered in the DSA pointed to by
  375.     the reference.  The DSA holding the master EDB, which actually
  376.     acts as an intermediate shadow for this entry, will read these
  377.     attributes from the DSA indicated by the reference, so that it
  378.     will have a full copy of the entry, using a standared DSP Read
  379.     operation.  This technique is called ``spot shadowing''.  Any
  380.     access control on the entry being spot shadowed must be configured
  381.     so that all attributes can be copied by the DSA holding the master
  382.     EDB. DSAs taking slave copies of the EDB will not do spot
  383.     shadowing.  However, the knowledge attributes will be copied, and
  384.     may be used by this DSA (e.g., for modify operations).
  385.  
  386. 4.  The entries at the level below are held in DSAs which do not
  387.     follow this specification, and all of these are indicated by a set
  388.     of NSSRs (Non Specific Subordinate Reference).  The NSSRs are
  389.     stored as an attribute of the entry.  The user attributes are
  390.     either mastered in the EDB.
  391.     It is important to note that NSSRs are stored at the level above
  392.     subordinate references.  At a given point in the DIT, if there are
  393.     subordinate references, these are stored in shadow entries below
  394.     that point, and named by the RDN. If there are NSSRs, they are
  395.     stored in the entry itself, as there is no RDN associated with an
  396.     NSSR. This approach is cleanest where there are either NSSRs or
  397.     subordinate references, but not both.  For example, consider an
  398.     Organisation HP, whose many OUs are stored in a set of DSAs
  399.     indicated by by NSSRs.  Here, the NSSR attributes will be used to
  400.     identify these DSAs.
  401.     This model of replication is not tightly integrated with NSSRs.
  402.     Where there is a mixture of NSSRs and Subordinate references at a
  403.     given point in the DIT, this is handled by giving a single
  404.     subordinate reference to a DSA which follows standard X.500
  405.     distributed operations and can cleanly handle this mixture.  In
  406.     practice, this is equivalent to not allowing a mixture of
  407.     subordinate references and NSSRs.
  408.  
  409. The information framework needed to support this is defined in
  410. Figure_1.______________________________________________________________
  411.  
  412.  
  413.  
  414.  
  415. Hardcastle-Kille                                                Page 7
  416.  
  417.  
  418.  
  419.  
  420. RFC 1276         Internet Directory Replication          November 1991
  421.  
  422.  
  423.  
  424. InternetDSNonLeafObject ::= OBJECT-CLASS
  425.         SUBCLASS OF top
  426.         MUST CONTAIN {masterDSA}
  427.         MAY CONTAIN {slaveDSA}
  428.  
  429. ExternalDSObject ::= OBJECT-CLASS
  430.         SUBCLASS OF top
  431.         MAY CONTAIN {SubordinateReference, CrossReference,          10
  432.                 NonSpecificSubordinateReference}
  433.                         -- will contain exactly one of these references
  434.  
  435. MasterDSA ::= ATTRIBUTE
  436.     WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
  437.     SINGLE VALUE
  438.  
  439. SlaveDSA ::= ATTRIBUTE
  440.     WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
  441.                                                                     20
  442. SubordinateReference ::= ATTRIBUTE
  443.     WITH ATTRIBUTE-SYNTAX AccessPoint
  444.     SINGLE VALUE
  445.  
  446. CrossReference ::= ATTRIBUTE
  447.     WITH ATTRIBUTE-SYNTAX AccessPoint
  448.     SINGLE VALUE
  449.  
  450. NonSpecificSubordinateReference ::= ATTRIBUTE
  451.     WITH ATTRIBUTE-SYNTAX AccessPoint                               30
  452.  
  453. AccessPoint ::= SET {
  454.         ae-title [0] Name,
  455.         address  [2] PresentationAddress OPTIONAL }
  456.  
  457.                 -- Same definition as X.500 AccessPoint,
  458.                 -- but presentation address is optional
  459.  
  460.  
  461. ___________________Figure_1:__Knowledge_Attributes_____________________
  462.  
  463. Two object classes are defined to support this approach:
  464.  
  465.  
  466.  
  467.  
  468. Hardcastle-Kille                                                Page 8
  469.  
  470.  
  471.  
  472.  
  473. RFC 1276         Internet Directory Replication          November 1991
  474.  
  475.  
  476. InternetDSNonLeafObject This is for where the level below follows the
  477.     model defined here, and there is an Entry Data Block (EDB)
  478.     containing the sibling entries.  The Entry itself contains master
  479.     data.  The associated attributes are:
  480.  
  481.     MasterDSA The name of the DSA where the master EDB is held.
  482.  
  483.     SlaveDSA The names of DSAs which hold slave copies of the EDB for
  484.         public access.
  485.  
  486. ExternalDSObject This is for where the entry and levels below are
  487.     mastered according to X.500.  There are attributes corresponding
  488.     to the standard knowledge references, which are used to resolve
  489.     queries.  The presentation address is optional in these
  490.     attributes.  If not present, it should be looked up in the DSAs
  491.     own entry.  For NonSpecificSubordinateReference, the master of the
  492.     entry will be in the master EDB, For SubordinateReference or
  493.     CrossReference1 the DSA which masters the EDB will ``spot shadow''
  494.     the entry, by reading it at intervals.  This will ensure that the
  495.     master EDB contains a copy of each entry.  Single level searching
  496.     can then be done efficiently where it is not required to access
  497.     the master copy of the data.  DSAs holding slave copies of the EDB
  498.     do not perform spot shadowing, but do receive copies of the
  499.     references.
  500.  
  501.  
  502. 7  Replication Protocol
  503. _______________________________________________________________________
  504. GetEntryDataBlock ABSTRACT-OPERATION
  505.         ARGUMENT GetEntryDataBlockArgument
  506.         RESULT GetEntryDataBlockResult
  507.         ERRORS {nameError,ServiceError,SecurityError,EDBVersionError}
  508.  
  509. EDBVersionError ABSTRACT-ERROR
  510.         PARAMETER versionHeld EDBVersion
  511.  
  512.  
  513. GetEntryDataBlockArgument ::= SET {                                 10
  514.  
  515. ----------------------------
  516.     1. These references are really the same.  The function and value
  517. are the same.  The name depends on where the reference is stored.  It
  518. may be preferable to have only one attribute.
  519.  
  520.  
  521. Hardcastle-Kille                                                Page 9
  522.  
  523.  
  524.  
  525.  
  526. RFC 1276         Internet Directory Replication          November 1991
  527.  
  528.  
  529.         entry [0] DistinguishedName,
  530.         CHOICE {
  531.                 sendIfMoreRecentThan [1] EDBVersion,
  532.                 getVersionNumber [2] NULL,
  533.                 getEDB [3] NULL,        -- force retrieval
  534.                 continuation [4] SEQUENCE {
  535.                         EDBVersion,
  536.                         nextEntryPosition INTEGER }
  537.                 },
  538.         maxEntries [5] INTEGER OPTIONAL                             20
  539.                         -- if omitted return whole EDB in
  540.                         -- one operation
  541. }
  542.  
  543. GetEntryDataBlockResult ::= SEQUENCE {
  544.                 versionHeld [0] EDBVersion,
  545.                 [1] SEQUENCE OF RelativeEntry OPTIONAL,
  546.                         -- if omitted, only version is returned
  547.                 nextEntryPostion INTEGER OPTIONAL
  548.                         -- if omitted there are no more entries     30
  549.         }
  550.  
  551.  
  552.  
  553. RelativeEntry ::= SEQUENCE {
  554.         RelativeDistinguishedName,
  555.         SET OF Attribute
  556.         }
  557.  
  558. EDBVersion ::= UTCTime                                              40
  559.  
  560. ___________________Figure_2:__Replication_Protocol_____________________
  561.  
  562. A ROS operation to support replication is defined in Figure 2.  This
  563. pulls an entire copy of the EDB. In normal use, the initiator
  564. specifies the EDB Version held.  If the responder has a more recent
  565. version, then all of the entries in the EDB are returned.  There are
  566. options to rerequest only the version of EDB held, or to return the
  567. full EDB irrespective of the version held by the initiator.
  568. For large EDBs, transfer of an entire EDB in a single operation would
  569. lead to very large ROS PDUs.  This gives a definite scaling
  570. limitation.  To overcome this, the protocol allows an EDB to be
  571. retrived in chunks of a size (in number of entries) specified by the
  572.  
  573.  
  574. Hardcastle-Kille                                               Page 10
  575.  
  576.  
  577.  
  578.  
  579. RFC 1276         Internet Directory Replication          November 1991
  580.  
  581.  
  582. initiator.  The responder specifies a number which indicates the next
  583. entry to be transferred.  The same operation can be used to retrieve
  584. the next chunk of the EDB, with EDBVersion and the same integer as
  585. parameters.
  586. This approach is simple to implement.  It is less efficient than an
  587. incremental technique.  When scaling dictates that an incremental
  588. technique must be used, it is expected that a suitable standard will
  589. be available.
  590. An implementation issue that must be noted is how to deal with updates
  591. whilst a multi-operation transfer is in progress.  There are two
  592. possible approaches:
  593.  
  594.  
  595. 1.  Refuse/block updates until the EDB is transferred.  This may cause
  596.     problems where the rate of update and transfer is high, as this
  597.     may make update very difficult (for the manager).
  598.  
  599. 2.  Create a new version of the EDB, whilst retaining the old EDB to
  600.     complete the bulk transfer.  A suitable retentions strategy would
  601.     be to hold an EDB version as long as the association on which it
  602.     is being pulled it remains active.
  603.  
  604. 3.  Allow the update and fail subsequent transfer requests for the
  605.     EDB. This may cause both transfer failure and excessive waste of
  606.     bandwidth due to retries if the rate of update and transfer is
  607.     high.
  608.  
  609. If option 1.  or 3.  is chosen, for a widely replicated EDB where the
  610. update rate is greater than a few changes per day, it is recommended
  611. to configure the master EDB in a DSA which only replicates to one
  612. other DSA. This second DSA can then control its update rate, and
  613. safely perform a large fanout of replications (option 3).  The first
  614. DSA will have reasonable availability for modifications (option 1).
  615.  
  616. This protocol will be used by DSAs to obtain copies of EDBs high in
  617. the tree (typically root and national EDBs).  DSAs which need these
  618. copies should establish bilateral agreements to access them2.
  619. This protocol should only transfer user attributes.  In particular,
  620. implementation specific attributes such as those needed to support
  621.  
  622. ----------------------------
  623.     2. QUIPU defines some attributes to register such agreements, but
  624. these are probably not appropriate for this specification.
  625.  
  626.  
  627. Hardcastle-Kille                                               Page 11
  628.  
  629.  
  630.  
  631.  
  632. RFC 1276         Internet Directory Replication          November 1991
  633.  
  634.  
  635. private access control should not be transferred.  There may be
  636. bilateral agreements on access control policy of the information
  637. (e.g., size limits on listing), which are implemented by (different)
  638. system specific techniques.
  639.  
  640.  
  641. 8  New Application Context
  642.  
  643. A DSA which follows these procedures will support a new
  644. ApplicationContext ``Internet DSP'' defined in Appendix A. This will
  645. be stored in the DSAs entry, so that support of the extensions defined
  646. here can easily be determined.
  647.  
  648.  
  649. 9  Policy on Replication Procedures
  650.  
  651. To be effective, a directory configuration must be laid out.  These
  652. protocols will need to be used in the framework of a pilot, and
  653. service providers making available data for replication.
  654. There is a requirement to manage the replication process.  This can be
  655. done by a combination of local configuration (to register shadowing
  656. agreements) and directory operations to set pointers to master and
  657. slave copies of the data.
  658.  
  659.  
  660. 10  Use of the Directory by Applications
  661.  
  662.  
  663. Care must be taken by users of the directory when replication is
  664. available.  This is not a change from current use of X.500, but is
  665. noted here as it is important.  Normal read requests should allow use
  666. of copy information.  If the user of the directory believes that
  667. information may be out of date (e.g., because an association could not
  668. be established), then the request should be repeated and use of copy
  669. data prohibited by service controls.
  670.  
  671.  
  672. 11  Migration and Scaling
  673.  
  674. The major scaling limit of this approach is the non-incremental
  675. update.  This will put a limit on the maximum DIT fanout which can be
  676. supported.  Given an average entry size of around a thousand bytes,
  677. and a maximum reasonable transfer size is tens of megabytes, then the
  678.  
  679.  
  680. Hardcastle-Kille                                               Page 12
  681.  
  682.  
  683.  
  684.  
  685. RFC 1276         Internet Directory Replication          November 1991
  686.  
  687.  
  688. fanout limit of this approach is of order 10 000.  Note that smaller
  689. organisations will tend to be registered geographically (e.g., in the
  690. US, by State), so that the limit of the number of Organisations is
  691. somewhat larger.  It should be noted that although the replication
  692. technique described here is general, it is only intended for high
  693. levels of the DIT. These figures assume this.
  694. These techniques do not preclude use of other techniques for
  695. replication.  It would be quite reasonable to replicate data using
  696. this approach, and that which will be defined in X.500(92).
  697.  
  698.  
  699. References
  700.  
  701. [HK91a] S.E. Hardcastle-Kille. Encoding network addresses to support
  702.         operation over non-osi lower layers. Request for Comments
  703.         RFC 1277, Department of Computer Science, University College
  704.         London, November 1991.
  705.  
  706. [HK91b] S.E. Hardcastle-Kille. Replication requirement to provide an
  707.         internet directory using X.500. Request for Comments
  708.         RFC 1275, Department of Computer Science, University College
  709.         London, November 1991.
  710.  
  711.  
  712. 12  Security Considerations
  713.  
  714. Security considerations are not discussed in this memo.
  715.  
  716.  
  717. 13  Author's Address
  718.  
  719.     Steve Hardcastle-Kille
  720.     Department of Computer Science
  721.     University College London
  722.     Gower Street
  723.     WC1E 6BT
  724.     England
  725.  
  726.  
  727.     Phone:  +44-71-380-7294
  728.  
  729.     EMail:  S.Kille@CS.UCL.AC.UK
  730.  
  731.  
  732.  
  733. Hardcastle-Kille                                               Page 13
  734.  
  735.  
  736.  
  737.  
  738. RFC 1276         Internet Directory Replication          November 1991
  739.  
  740.  
  741. A  ASN.1 Summary and Object Identifier Allocation
  742.  
  743. There_are_a_few_object_identifiers_needed.__These_are_defined_here.____
  744.  
  745. InternetDSP  TAGS ::=
  746. BEGIN
  747.  
  748. IMPORTS
  749.     APPLICATION-SERVICE-ELEMENT, PORT, APPLICATION-CONTEXT,
  750.     aCSE, ABSTRACT OPERATION
  751.         FROM Remote-Operations-Notation-extension {joint-iso-ccitt
  752.         remote-operations(4) notation-extension(2)}
  753.  
  754.                                                                     10
  755.    id-as-mrse, id-as-mase, id-as-ms
  756.         FROM MTSAccessProtocol {joint-iso-ccitt mhs-motis(6)
  757.         protocols(0) modules(0) object-identifiers(0)}
  758.  
  759.    chainedReadASE, chainedSearchASE, chainedModifyASE
  760.         FROM DirectorySystemProtocol {joint-iso-ccitt ds(5)
  761.                 modules(1) dsp(12)}
  762.  
  763.    DistinguishedName, RelativeDistinguishedName, Attribute
  764.         FROM InformationFramework {joint-iso-ccitt ds(5)            20
  765.                 modules(1) InformationFramework(1)}
  766.  
  767.  
  768.    ATTRIBUTE, OBJECT-CLASS
  769.         FROM InformationFramework {joint-iso-ccitt ds(5)
  770.         modules(1) informationFramework(1)};
  771.  
  772.  
  773.  
  774. internet-dsp OBJECT IDENTIFIER ::= {ccitt data(9) pss(2342)         30
  775.         ucl(19200300) internet-dsp(107)}
  776.  
  777. -- General
  778.  
  779. at OBJECT IDENTIFIER ::= {internet-dsp at(1)}
  780. oc OBJECT IDENTIFIER ::= {internet-dsp oc(2)}
  781.  
  782.  
  783. -- Object Classes needed for association
  784.  
  785.  
  786. Hardcastle-Kille                                               Page 14
  787.  
  788.  
  789.  
  790.  
  791. RFC 1276         Internet Directory Replication          November 1991
  792.  
  793.  
  794.                                                                     40
  795. id-ac-idsp  OBJECT IDENTIFIER ::= {internet-dsp ac-idsp(3))}
  796. id-as-idsp  OBJECT IDENTIFIER ::= {internet-dsp as-idsp(4))}
  797. id-ase-replication  OBJECT IDENTIFIER ::= {internet-dsp ase-replication(5))}
  798.  
  799.  
  800. -- Attribute Types
  801.  
  802. master-dsa MasterDSA ::= {at 1}
  803. slave-dsa SlaveDSA ::= {at 2}
  804. subordinate-reference SubordinateReference ::= {at 3}               50
  805. cross-reference CrossReference ::= {at 4}
  806. nssr NonSpecificSubordinateReference ::= {at 5}
  807.  
  808. -- Object Classes
  809.  
  810. internet-ds-non-leaf-object InternetDSNonLeafObject ::= {oc 1}
  811. external-ds-object ExternalDSObject ::= {oc 2}
  812.  
  813.  
  814. -- Operation and Error bindings                                     60
  815.  
  816. getEntryDataBlock GetEntryDataBlock ::= 10
  817.  
  818. eDBVersionError EDBVersionError ::= 10
  819.  
  820.  
  821. -- Protocol Definitions
  822.  
  823. replicationASE APPLICATION-SERVICE-ELEMENT
  824.     OPERATIONS {getEntryDataBlock}                                  70
  825.     ::= id-ase-replication
  826.  
  827. internet-dsp APPLICATION-CONTEXT
  828.     APPLICATION SERVICE ELEMENTS {aCSE}
  829.     BIND MSBind
  830.     UNBIND MSUnbind
  831.     REMOTE OPERATIONS {rOSE}
  832.     OPERATIONS OF { chainedReadADSm chainedSearchASE,
  833.         chainedModifyASE, replicationASE }
  834.     ABSTRACT SYNTAXES {                                             80
  835.         id-as-acse,
  836.         id-as-idsp }
  837.     ::= id-ac-idsp
  838.  
  839. Hardcastle-Kille                                               Page 15
  840.  
  841.  
  842.  
  843.  
  844. RFC 1276         Internet Directory Replication          November 1991
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.                                                                     90
  854. InternetDSNonLeafObject ::= OBJECT-CLASS
  855.         SUBCLASS OF top
  856.         MUST CONTAIN {masterDSA}
  857.         MAY CONTAIN {slaveDSA}
  858.  
  859. ExternalDSObject ::= OBJECT-CLASS
  860.         SUBCLASS OF top
  861.         MAY CONTAIN {SubordinateReference, CrossReference,
  862.                 NonSpecificSubordinateReference}
  863.                         -- will contain exactly one of these references100
  864.  
  865. MasterDSA ::= ATTRIBUTE
  866.     WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
  867.     SINGLE VALUE
  868.  
  869. SlaveDSA ::= ATTRIBUTE
  870.     WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
  871.  
  872. SubordinateReference ::= ATTRIBUTE
  873.     WITH ATTRIBUTE-SYNTAX AccessPoint                              110
  874.     SINGLE VALUE
  875.  
  876. CrossReference ::= ATTRIBUTE
  877.     WITH ATTRIBUTE-SYNTAX AccessPoint
  878.     SINGLE VALUE
  879.  
  880. NonSpecificSubordinateReference ::= ATTRIBUTE
  881.     WITH ATTRIBUTE-SYNTAX AccessPoint
  882.  
  883. AccessPoint ::= SET {                                              120
  884.         ae-title [0] Name,
  885.         address  [2] PresentationAddress OPTIONAL }
  886.  
  887.                 -- Same definition as X.500 AccessPoint,
  888.                 -- but presentation address is optional
  889.  
  890. GetEntryDataBlock ABSTRACT-OPERATION
  891.  
  892. Hardcastle-Kille                                               Page 16
  893.  
  894.  
  895.  
  896.  
  897. RFC 1276         Internet Directory Replication          November 1991
  898.  
  899.  
  900.         ARGUMENT GetEntryDataBlockArgument
  901.         RESULT GetEntryDataBlockResult
  902.         ERRORS {nameError,ServiceError,SecurityError,EDBVersionError}130
  903.  
  904. EDBVersionError ABSTRACT-ERROR
  905.         PARAMETER versionHeld EDBVersion
  906.  
  907.  
  908. GetEntryDataBlockArgument ::= SET {
  909.         entry [0] DistinguishedName,
  910.         CHOICE {
  911.                 sendIfMoreRecentThan [1] EDBVersion,
  912.                 getVersionNumber [2] NULL,                         140
  913.                 getEDB [3] NULL,        -- force retrieval
  914.                 continuation [4] SEQUENCE {
  915.                         EDBVersion,
  916.                         nextEntryPosition INTEGER }
  917.                 },
  918.         maxEntries [5] INTEGER OPTIONAL
  919.                         -- if omitted return whole EDB in
  920.                         -- one operation
  921. }
  922.                                                                    150
  923. GetEntryDataBlockResult ::= SEQUENCE {
  924.                 versionHeld [0] EDBVersion,
  925.                 [1] SEQUENCE OF RelativeEntry OPTIONAL,
  926.                         -- if omitted, only version is returned
  927.                 nextEntryPostion INTEGER OPTIONAL
  928.                         -- if omitted there are no more entries
  929.         }
  930.  
  931.  
  932.                                                                    160
  933. RelativeEntry ::= SEQUENCE {
  934.         RelativeDistinguishedName,
  935.         SET OF Attribute
  936.         }
  937.  
  938. EDBVersion ::= UTCTime
  939. END
  940.  
  941. ___________________Figure_3:__Summary_of_the_ASN.1_____________________
  942.  
  943.  
  944.  
  945. Hardcastle-Kille                                               Page 17
  946.  
  947.