git.sur5r.net Git - openldap/blob - doc/drafts/draft-ietf-ldup-protocol-xx.txt

   1
   2 LDUP Replication Update Protocol
   3 Internet-Draft
   4 Intended Category: Standards Track
   5 Expires: September 10, 2000
   6
   7
   8                                                             Ellen Stokes
   9                                                          IBM Corporation
  10
  11                                                              Gordon Good
  12                                            Netscape Communications Corp.
  13
  14                                                            March 10 2000
  15
  16                   The LDUP Replication Update Protocol
  17                Filename: draft-ietf-ldup-protocol-01.txt
  18
  19 Table of Contents
  20
  21 1.    Status of this Memo.............................................2
  22 2.    Abstract........................................................2
  23 3.    Overview of Protocol............................................2
  24 4.    High-level Description of Protocol Flow.........................3
  25 4.1   Supplier-initiated incremental replication protocol.............3
  26 4.2.     Consumer-initiated replication protocol......................4
  27 5.    Replication protocol element definitions........................5
  28 5.1   StartFramedProtocolRequest Extended Operation...................5
  29 5.2   StartFramedProtocolResponse Extended Operation..................6
  30 5.3   ReplicationUpdate Extended Operation............................7
  31 5.3.1    UniqueIdentifier.............................................8
  32 5.3.2    ReplicationPrimitive.........................................8
  33 5.3.2.1     AddEntryPrimitive.........................................8
  34 5.3.2.2     MoveEntryPrimitive........................................9
  35 5.3.2.3     RenameEntryPrimitive......................................9
  36 5.3.2.4     RemoveEntryPrimitive......................................9
  37 5.3.2.5     AddAttributeValuePrimitive................................10
  38 5.3.2.6     RemoveAttributeValuePrimitive.............................10
  39 5.3.2.7     RemoveAttributePrimitive..................................10
  40 5.4   EndFramedProtocolRequest Extended Operation.....................11
  41 5.5   EndFramedProtocolResponse Extended Operation....................11
  42 5.6   ReplicationUpdateResponse Extended Operation....................12
  43 6.    Semantics of Full and Incremental Update protocols..............13
  44 7.    Summary of response codes.......................................13
  45 8.    Implications for log-based and state-based servers..............13
  46 9.    Replication of access control and schema information............13
  47 10.   Security Considerations.........................................14
  48 11.   Glossary of Terms...............................................14
  49 12.   Acknowledgments.................................................14
  50 13.   References......................................................14
  51 14.   Author's Addresses..............................................15
  52
  53
  54
  55 Stokes and Good                                                 [Page 1]
  56 \f
  57 Internet-Draft               LDUP Workgroup                March 10 2000
  58
  59
  60 1. Status of this Memo
  61
  62    This document is an Internet-Draft and is in full conformance with
  63    all provisions of Section 10 of RFC2026.
  64
  65    Internet-Drafts are working documents of the Internet Engineering
  66    Task Force (IETF), its areas, and its working groups. Note that other
  67    groups may also distribute working documents as Internet-Drafts.
  68
  69    Internet-Drafts are draft documents valid for a maximum of six months
  70    and may be updated, replaced, or obsoleted by other documents at any
  71    time.  It is inappropriate to use Internet- Drafts as reference
  72    material or to cite them other than as "work in progress."
  73
  74    To view the list Internet-Draft Shadow Directories, see
  75    http://www.ietf.org/shadow.html.
  76
  77    This Internet Draft expires September 10, 2000.
  78
  79
  80 2. Abstract
  81
  82    The protocol described in this document is designed to allow one LDAP
  83    server to replicate its directory content to another LDAP server. The
  84    protocol is designed to be used in a replication configuration where
  85    multiple updatable servers are present. Provisions are made in the
  86    protocol to carry information that allows the server receiving
  87    updates to apply a total ordering to all updates in the replicated
  88    system. This total ordering allows all replicas to correctly resolve
  89    conflicts that arise when LDAP clients submit changes to different
  90    servers that later replicate to one another.
  91
  92    All protocol elements described here are LDAP Version 3 extended
  93    operations. LDAP Version 3 is described in RFC 2251 [LDAPv3].
  94
  95    Certain terms used in this document are defined in the document "LDAP
  96    Replication Architecture" (draft-ietf-ldup-model-00.txt).
  97
  98    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  99    "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
 100    to be interpreted as described in RFC 2119 [KEYWORDS].
 101
 102 3. Overview of Protocol
 103
 104    The LDAP Replication Architecture [ARCHITECTURE] describes the
 105    overall approach used in ensuring consistency of multiple updatable
 106    replicas of directory content. The protocol described in this
 107    document implements the approach desribed in that document.
 108
 109
 110
 111 Stokes and Good                                                 [Page 2]
 112 \f
 113 Internet-Draft               LDUP Workgroup                March 10 2000
 114
 115
 116    LDAP Version 3 extended operations are used to carry replicated
 117    content from one server to another. The extended operations defined
 118    in this document are used to initiate and end a replication session,
 119    and to exchange updates. These updates carry with them information
 120    that allows the receiving server to apply a total ordering to all of
 121    the updates in a replicated system. All servers that receive
 122    replication updates apply a consistent set of update resolution
 123    policies, described in [URP]. Consistent application of the update
 124    resolution policies ensures that all replicas eventually converge and
 125    contain the same directory data.
 126
 127    This protocol is based upon the extended operations defined in
 128    [FRAMING].
 129
 130    This protocol is intended to meet the requirements set forth in
 131    [REQ].
 132
 133 4. High-level Description of Protocol Flow
 134
 135    The following section provides a high-level overview of the
 136    replication protocol. Throughout this section, the supplier server is
 137    indicated by the letter "S" and the consumer server by the letter
 138    "C". The construct "S -> C" indicates that the supplier is sending an
 139    LDAPv3 extended operation to the consumer, and "C -> S" indicates
 140    that the consumer is sending an LDAPv3 extended operation to the
 141    supplier.
 142
 143 4.1 Supplier-initiated incremental replication protocol
 144
 145       S -> C: LDAP bind operation (identity and credentials
 146              used are implementation-defined)
 147
 148       C -> S: Bind response
 149
 150       S -> C: StartFramedProtocolRequest LDAPv3 extended
 151               operation. The parameters are:
 152
 153                 1) The OID for the LDUP incremental replication protocol or the
 154                    LDUP total update protocol, depending on whether an incremental
 155                    or complete refresh of the replica is to be performed.
 156                 2) A protocol-specific payload containing:
 157                   a) The root of replicated area (unambiguously
 158                      identifies the replicated area)
 159                   b) The supplier's replicaID
 160                   c) The protocol initiation type - Supplier-Initiated
 161                      in this case.
 162
 163       C -> S: StartFramedProtocolResponse LDAPv3 extended operation. The
 164
 165
 166
 167 Stokes and Good                                                 [Page 3]
 168 \f
 169 Internet-Draft               LDUP Workgroup                March 10 2000
 170
 171
 172               parameters are:
 173
 174                 1) A protocol-specific payload containing:
 175                   a) A response code (see section 7)
 176                   b) An optional update vector that is included
 177                      if and only if the response code is REPL_SUCCESS.
 178
 179       S -> C: The supplier may send zero or more ReplicationUpdate LDAPv3
 180               extended operations. The parameters are:
 181
 182                 1) The UUID of the entry being updated
 183                 2) One or more Replication Primitives (The supplier
 184                    may send as many of these as required to bring
 185                    the consumer up to date)
 186
 187       C -> S: At any time, the consumer may send an unsolicited
 188               ReplicationUpdateResponse LDAPv3 extended operation. The
 189               parameters are:
 190
 191                 1) An optional update vector.  If sent, this indicates that
 192                    the consumer has committed all updates whose CSNs are
 193                    covered by the transmitted update vector [see glossary
 194                    for a definition of "covered by"].
 195                 2) An optional AbortUpdate boolean flag.  If a supplier
 196                    receives a ReplicationUpdateResponse from a consumer with
 197                    the AbortUpdate flag set to true, the supplier server MUST
 198                    immediately cease sending updates and terminate its
 199                    connection to the consumer.
 200
 201       S -> C: After all required updates have been sent to the consumer, the
 202               supplier sends an EndFramedProtocolRequest LDAPv3 extended
 203               operation.
 204
 205       C -> S: The consumer responds by sending an EndFramedProtocolResponse
 206               LDAPv3 extended operation, and then closes the connection.
 207
 208 4.2. Consumer-initiated replication protocol
 209
 210    C -> S: LDAP bind operation (identity and credentials
 211           used are implementation-defined)
 212
 213    S -> C: Bind response
 214
 215    C -> S: StartFramedProtocolRequest LDAPv3 extended
 216            operation. The parameters are:
 217
 218              1) The OID for the LDUP incremental replication protocol or the
 219                 LDUP total update protocol, depending on whether an incremental
 220
 221
 222
 223 Stokes and Good                                                 [Page 4]
 224 \f
 225 Internet-Draft               LDUP Workgroup                March 10 2000
 226
 227
 228                 or complete refresh of the replica is to be performed.
 229              2) A protocol-specific payload containing:
 230                a) The root of replicated area (unambiguously
 231                   identifies the replicated area)
 232                b) The consumer's replicaID
 233                c) The protocol initiation type - Consumer-Initiated
 234                   in this case.
 235
 236    S -> C: StartFramedProtocolResponse LDAPv3 extended operation. The
 237            parameters are:
 238
 239              1) A protocol-specific payload containing:
 240                a) A response code (see section 7)
 241
 242    S -> C: The supplier server disconnects from the consumer server,
 243            and then connects to the consumer, beginning a Supplier-
 244            Initiated protocol session (see section 4.1).
 245
 246
 247 5. Replication protocol element definitions
 248
 249 5.1 StartFramedProtocolRequest Extended Operation
 250
 251    The StartFramedProtocolRequest extended operation is sent by a replication
 252    initiator to a server to indicate that a replication session should
 253    commence. For supplier-initiated replication, the supplier sends this
 254    extended operation to the replication consumer to indicate that a
 255    replication session should commence. For consumer-initiated
 256    replication, the consumer sends this extended operation to the
 257    replication supplier to indicate that the supplier should initiate a
 258    replication session to the consumer as soon as possible.
 259
 260    The StartFramedProtocolRequest extended operation is defined
 261    in [FRAMING]. When signaling the beginning of a replication
 262    session, then requestValue of the StartFramedProtocolRequest
 263    is set to the following:
 264
 265       requestValue ::= SEQUENCE {
 266           framedProtocolOID LDAPOID,
 267           framedProtocolPayload OPTIONAL OCTET STRING
 268       }
 269
 270    The framedProtocolOID of the StartReplicationRequest must be the OID
 271    for the LDUP incremental replication protocol,
 272    2.16.840.1.113719.1.142.1.4.3, or the LDUP total update protocol,
 273    2.16.840.1.113719.1.142.1.4.4.  See section 7 for information on the
 274    semantic behavior of these update protocols.  Implementations MUST
 275    support the two update protocols defined in this document.
 276
 277
 278
 279 Stokes and Good                                                 [Page 5]
 280 \f
 281 Internet-Draft               LDUP Workgroup                March 10 2000
 282
 283
 284    The framedProtocolPayload of the StartFramedProtocolRequestValue must
 285    be set to the BER-encoding of the following:
 286
 287       framedProtocolPayload ::= SEQUENCE {
 288           replicaRoot            LDAPDN,
 289           replicaID              LDAPString,
 290           replicationInitiator   ENUMERATED {
 291               supplier (0),
 292               consumer (1)
 293           }
 294       }
 295
 296    The parameters in the framedProtocolPayload of the
 297    StartFramedProtocolRequestValue are:
 298
 299       - replicaRoot: the distinguished name of the entry at the top of
 300       the replicated area, and uniquely identifies the unit of
 301       replication.
 302
 303       - replicaID: the replica identifier of the replication initiator.
 304       Each replica of a given replicated area is identified by a unique
 305       identifier, described in [ARCHITECTURE].
 306
 307       - replicationInitiator: used to differentiate between a supplier-
 308       initiated session and a consumer-initiated session.  If the
 309       replicationInitiator contains the enumerated value <supplier>,
 310       then the initiator is the supplier, and the receiver of this
 311       operation should prepare to receive a set of replication updates
 312       (or should reject the operation is replication updates are not
 313       permitted for some reasonm, perhaps due to access control
 314       restrictions).  If the replicationInitiator contains the
 315       enumerated value <consumer>, then the receiver should prepare to
 316       establish a supplier-initiated replication session with the
 317       consumer as soon as possible, updating the replicated are given by
 318       replicaRoot and using the update protocol given by
 319       replicationProtocolOID.
 320
 321 5.2 StartFramedProtocolResponse Extended Operation
 322
 323    The StartFramedProtocolResponse extended operation is sent in
 324    response to a StartFramedProtocolRequest extended operation.
 325
 326    For a supplier-initiated session, the response field of the
 327    StartFramedProtocolResponse extended response indicates that the
 328    consumer is or is not prepared to accept a set of updates. If the
 329    consumer is prepared to accept updates, it sends a response field
 330    containing a success code and the consumer's replica update vector.
 331    If the consumer is unwilling or unable to accept updates, it sends a
 332
 333
 334
 335 Stokes and Good                                                 [Page 6]
 336 \f
 337 Internet-Draft               LDUP Workgroup                March 10 2000
 338
 339
 340    response field containing an error code.
 341
 342    For a consumer-initiated session, the response field of the
 343    StartFramedProtocolResponse extended respons indicates that the
 344    supplier is or is not prepared to send a set of updates to the
 345    consumer. If the supplier is prepared to send updates to the
 346    consumer, it sends a response field containing a success code. If the
 347    supplier is unwilling or unable to send updates to the consumer, it
 348    sends a response field containing an error code. In both cases, the
 349    supplier disconnects from the consumer. If the supplier sent a
 350    success code to the consumer, it opens a connection to the consumer
 351    as soon as possible and initiates a supplier-initiated replication
 352    session.
 353
 354    The StartFramedProtocolResponse extended operation is defined in
 355    [FRAMING]. When responding to a StartFramedProtocolRequest signaling
 356    the beginning of an LDUP replication session, the response field of
 357    the StartFramedProtocolResponse is set to the following:
 358
 359       StartFramedProtocolResponseValue ::= SEQUENCE {
 360           responseCode           LDUPResponseCode,
 361           replicaUpdateVector    Attribute,
 362       }
 363
 364    LDUPResponseCodes are defined in section 8.
 365
 366    The replicaUpdateVector contains a replica update vector, as defined
 367    in [INFOMOD]. The update vector is encoded as a normal LDAP
 368    attribute, defined in [LDAPv3].
 369
 370
 371 5.3 ReplicationUpdate Extended Operation
 372
 373 The ReplicationUpdate extended operation carries a set of replication
 374 primitives that represent the desired final state of a single entry.
 375
 376 The ReplicationUpdate extended operation is defined as follows:
 377
 378 An LDAPv3 Extended Request is defined in [LDAPv3] as follows:
 379
 380    ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
 381        requestName  [0] LDAPOID
 382        requestValue [1] OCTET STRING OPTIONAL
 383    }
 384
 385 The requestName of the ReplicationUpdate must be the OID
 386 2.16.840.1.113719.1.142.100.3.
 387
 388
 389
 390
 391 Stokes and Good                                                 [Page 7]
 392 \f
 393 Internet-Draft               LDUP Workgroup                March 10 2000
 394
 395
 396 The requestValue of the ReplicationUpdate must be set to the BER-
 397 encoding of the following:
 398
 399    requestValue ::= SEQUENCE {
 400        uniqueID     UniqueIdentifier,
 401        updates      SET OF ReplicationPrimitive
 402    }
 403
 404 5.3.1 UniqueIdentifier
 405
 406    The Distinguished Name of an entry may be changed (by renaming the
 407    entry), or the entry may not have a distinguished name (if it was
 408    deleted).  The Unique Identifier provides an immutable name,
 409    independent of the current name or deletion status, for an entry. All
 410    replicated operations address entries by their Unique Identifiers.
 411
 412       UniqueIdentifier ::= LDAPString
 413
 414
 415 5.3.2 ReplicationPrimitive
 416
 417    A ReplicationPrimitive carries a single assertion about the the final
 418    state of an entry, attribute, or attribute value. There are seven
 419    types of primitives.
 420
 421       ReplicationPrimitive ::= CHOICE {
 422           addEntryPrimitive                AddEntryPrimitive,
 423           moveEntryPrimitive               MoveEntryPrimitive,
 424           renameEntryPrimitive             RenameEntryPrimitive,
 425           removeEntryPrimitive             RemoveEntryPrimitive,
 426           addAttributeValuePrimitive       AddAttributeValuePrimitive,
 427           removeAttributeValuePrimitive    RemoveAttributeValuePrimitive,
 428           removeAttributePrimitive         RemoveAttributePrimitive
 429       }
 430
 431    Each primitive applies to the entry referred to by the
 432    uniqueIdentifier in the enclosing ReplicationUpdate extended
 433    operation.
 434
 435    Each primitive carries an lLDAPChangeSequenceNumber that is used by
 436    the consumer server to correctly resolve update conflicts. [URP]
 437    describes the update reconciliation procedures.
 438
 439 5.3.2.1 AddEntryPrimitive
 440
 441    The AddEntryPrimitive is used to add a new entry.
 442
 443       AddEntryPrimitive ::= [APPLICATION 0] SEQUENCE {
 444
 445
 446
 447 Stokes and Good                                                 [Page 8]
 448 \f
 449 Internet-Draft               LDUP Workgroup                March 10 2000
 450
 451
 452           csn       lDAPChangeSequenceNumber,
 453           superior  UniqueIdentifier,
 454           rdn       RelativeLDAPDN
 455       }
 456
 457    Parameters of the AddEntryPrimitive are:
 458
 459       - csn: The change sequence number of the primitive.
 460
 461       - superior: The unique identifier of the superior (parent) entry.
 462
 463       - rdn: The relative distinguished name of the new entry.
 464
 465 5.3.2.2 MoveEntryPrimitive
 466
 467    The MoveEntryPrimitive is used to move an entry to a new location in
 468    the DIT.
 469
 470       MoveEntryPrimitive ::= [APPLICATION 1] SEQUENCE {
 471           csn      lDAPChangeSequenceNumber,
 472           superior UniqueIdentifier
 473       }
 474
 475    Parameters of the MoveEntryPrimitive are:
 476
 477       - csn: The change sequence number of the primitive.
 478
 479       - superior: The unique identifier of the new superior (parent)
 480       entry.
 481
 482 5.3.2.3 RenameEntryPrimitive
 483
 484    The RenameEntryPrimitive is used to change the RDN of an entry.
 485
 486       RenameEntryPrimitive ::= [APPLICATION 2] SEQUENCE {
 487           csn lDAPChangeSequenceNumber,
 488           rdn RelativeLDAPDN
 489       }
 490
 491    Parameters of the RenameEntryPrimitive are:
 492
 493       - csn: The change sequence number of the primitive.
 494
 495       - rdn: The new relative distinguished name of the entry.
 496
 497 5.3.2.4 RemoveEntryPrimitive
 498
 499    The RemoveEntryPrimitive is used to delete an entry from the DIT.
 500
 501
 502
 503 Stokes and Good                                                 [Page 9]
 504 \f
 505 Internet-Draft               LDUP Workgroup                March 10 2000
 506
 507
 508       RemoveEntryPrimitive ::= [APPLICATION 3] SEQUENCE {
 509           csn lDAPChangeSequenceNumber
 510       }
 511
 512    Parameters of the RemoveEntryPrimitive are:
 513
 514       - csn: The change sequence number of the primitive.
 515
 516 5.3.2.5 AddAttributeValuePrimitive
 517
 518    The AddAttributeValuePrimitive is use to add a new attribute value to
 519    an entry.
 520
 521       AddAttributeValuePrimitive ::= [APPLICATION 4] SEQUENCE {
 522           csn     lDAPChangeSequenceNumber,
 523           type    AttributeDescription,
 524           value   AttributeValue
 525       }
 526
 527    Parameters of the AddAttributeValuePrimitive are:
 528
 529       - csn: The change sequence number of the primitive.
 530
 531       - type: The type of the attribute being added.
 532
 533       - value: The value being added. Multiple values are not permitted.
 534
 535 5.3.2.6 RemoveAttributeValuePrimitive
 536
 537    The RemoveAttributeValuePrimitive is used to remove a particular
 538    attribute value from an entry.
 539
 540       RemoveAttributeValuePrimitive ::= [APPLICATION 5] SEQUENCE {
 541           csn   lDAPChangeSequenceNumber,
 542           type  AttributeDescription,
 543           value AttributeValue
 544       }
 545
 546    Parameters of the RemoveAttributeValuePrimitive are:
 547
 548       - csn: The change sequence number of the primitive.
 549
 550       - type: The type of the attribute being removed.
 551
 552       - value: The value being removed. Multiple values are not
 553       permitted.
 554
 555 5.3.2.7 RemoveAttributePrimitive
 556
 557
 558
 559 Stokes and Good                                                [Page 10]
 560 \f
 561 Internet-Draft               LDUP Workgroup                March 10 2000
 562
 563
 564    The RemoveAttributePrimitive is used to remove an attribute and all
 565    its values from an entry.
 566
 567       RemoveAttributePrimitive ::= [APPLICATION 6] SEQUENCE {
 568           csn  lDAPChangeSequenceNumber,
 569           type AttributeDescription
 570       }
 571
 572    Parameters of the RemoveAttributePrimitive are:
 573
 574       - csn: The change sequence number of the primitive.
 575
 576       - type: The type of the attribute being removed.
 577
 578
 579 5.4 EndFramedProtocolRequest Extended Operation
 580
 581    The EndFramedProtocolRequest extended operation is sent from the
 582    replication supplier to the replication consumer to indicate the end
 583    of the sequence of replication updates. In the event that the
 584    supplier is sending a total update, the requestValue field of the
 585    EndFramedProtocolRequest extended operation contains a replica update
 586    vector. The consumer server must replace its replica update vector,
 587    if present, with the one provided by the supplier. In the event that
 588    the supplier is sending an incremental update, the replica update
 589    vector is absent.
 590
 591    The EndFramedProtocolRequest extended operation is defined in
 592    [FRAMING]. When used to signal the termination of an LDUP incremental
 593    or total update session, the requestValue field of the
 594    EndFramedProtocolRequest is set to the following:
 595
 596       requestValue ::= SEQUENCE {
 597           replicaUpdateVector    Attribute OPTIONAL,
 598           returnConsumerUpdateVector BOOLEAN
 599       }
 600
 601    If returnConsumerUpdateVector is TRUE, the consumer server must
 602    return its current update vector to the supplier in the response
 603    field of the EndFramedProtocolResponse extended response (defined in
 604    section 5.5).  Typically, the supplier will request the consumer's
 605    update vector for read-only replicas, since the read-only replica
 606    will never initiate a replication session, and will therefore never
 607    have the opportunity to provide its update vector to other servers.
 608
 609
 610 5.5 EndFramedProtocolResponse Extended Operation
 611
 612
 613
 614
 615 Stokes and Good                                                [Page 11]
 616 \f
 617 Internet-Draft               LDUP Workgroup                March 10 2000
 618
 619
 620    The EndFramedProtocolResponse extended operation is defined in
 621    [FRAMING]. It is used to respond to a EndFramedProtocolRequest.  The
 622    response field of the EndFramedProtocolResponse extended operation is
 623    set to the following:
 624
 625       response ::= SEQUENCE {
 626           replicaUpdateVector    Attribute OPTIONAL
 627       }
 628
 629    The replicaUpdateVector contains the consumer's current replica
 630    update vector, and is optional. The consumer server should only send
 631    the replicaUpdateVector if requested by the supplier server in the
 632    EndReplicationRequest extended operation.
 633
 634 5.6 ReplicationUpdateResponse Extended Operation
 635
 636 The ReplicationUpdateResponse extended operation is sent, unsolicited,
 637 by a consumer to a supplier when the consumer wishes the supplier to
 638 stop sending updates.
 639
 640 An LDAPv3 extended response is defined in [LDAPv3] as follows:
 641
 642    ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
 643        COMPONENTS of LDAPResult,
 644        responseName  [10] LDAPOID OPTIONAL,
 645        response      [11] OCTET STRING OPTIONAL
 646    }
 647
 648 The responseName of the ReplicationUpdateResponse must be the OID [OID
 649 to be assigned].
 650
 651 The response field of the ReplicationUpdateResponse must be set to the
 652 BER-encoding of the following:
 653
 654    response ::= SEQUENCE {
 655        replicaUpdateVector  Attribute OPTIONAL
 656        abortUpdate          BOOLEAN
 657    }
 658
 659 The parameters of the ReplicationUpdateResponse are:
 660
 661 - An optional update vector.  If sent, this indicates that the consumer
 662 has committed all updates whose CSNs are covered by the transmitted
 663 update vector [see glossary for a definition of "covered by"].  - An
 664 optional AbortUpdate boolean flag.  If a supplier receives a
 665 ReplicationUpdateResponse from a consumer with the AbortUpdate flag set
 666 to true, the supplier server MUST immediately cease sending updates and
 667 terminate its connection to the consumer.
 668
 669
 670
 671 Stokes and Good                                                [Page 12]
 672 \f
 673 Internet-Draft               LDUP Workgroup                March 10 2000
 674
 675
 676 6. Semantics of Full and Incremental Update protocols
 677
 678 [To be written]
 679
 680 7. Summary of response codes
 681
 682 The following list describes the response codes that may be included in
 683 the StartFramedProtocolResponse, EndFramedProtocolResponse, and
 684 ReplicationUpdateResponse extended operations.
 685
 686    LDUPResponseCode  ::= SEQUENCE {
 687        resultCode  ENUMERATED {
 688                  success                   (0),
 689                  operationsError           (1),
 690                  protocolError             (2),
 691                  insufficientAccessRights (50),
 692                  busy                     (51),
 693                  excessiveCSNSkew        (200),
 694
 695                  other              (80) },
 696        errorMessage LDAPString }
 697
 698 The meanings of the response codes are as follows:
 699
 700    success..................... As defined in [LDAPv3].
 701    operationsError............. As defined in [LDAPv3].
 702    protocolError............... As defined in [LDAPv3].
 703    insufficientAccessRights.... Access denied. The identity that the
 704                                 initiator provided in the bind request does
 705                                 not have sufficient privileges to perform
 706                                 the operation.
 707    busy........................ The replica is temporarily unable to accept
 708                                 updates.
 709    excessiveCSNSkew............ The consumer server has detected that the
 710                                 CSNs being generated by the supplier are
 711                                 too small (perhaps because the supplier's
 712                                 clock was set back). Updates from the
 713                                 supplier will not be applied.
 714    other....................... Some other error occurred.
 715
 716 8. Implications for log-based and state-based servers
 717
 718 To be written, or possibly incorporated into [ARCHITECTURE].
 719
 720 9. Replication of access control and schema information
 721
 722 To be written, or possibly incorporated into [ARCHITECTURE].
 723
 724
 725
 726
 727 Stokes and Good                                                [Page 13]
 728 \f
 729 Internet-Draft               LDUP Workgroup                March 10 2000
 730
 731
 732 10. Security Considerations
 733
 734 To be written.
 735
 736 11. Glossary of Terms
 737
 738    Covered by: We say that a CSN is "covered by" an update vector if and
 739    only if the CSN is less than or equal to the component of the update
 740    vector corresponding to the replica ID in the CSN. In other words,
 741    given a CSN with components <t,S,r,s> and an update vector with CSNs
 742    <t0,S0,r0,s0>,<t1,S1,r1,s1>...<tn,Sn,Rn,sn>, then the CSN is covered
 743    by the RUV if and only if one of the following holds for some value
 744    i:
 745       a) r = ri and t < ti
 746       b) r = ri and t = ti and S < Si
 747       c) r = ri and t = ti and S = Si and s < si
 748
 749
 750 12. Acknowledgments
 751
 752 To be written.
 753
 754 13. References
 755
 756
 757 [ARCHITECTURE]
 758      J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architec-
 759      ture", Internet-Draft, draft-ietf-ldup-model-02.txt, October 1999.
 760
 761
 762 [FRAMING]
 763      E. Stokes, G. Good, "Extended Operations for Framing LDAP Bulk
 764      Update Operations", Internet-Draft, draft-ietf-ldup-framing-00.txt,
 765      March 2000.
 766
 767
 768 [INFOMOD]
 769      E. Reed, "LDAP Replication Information Model", Internet-Draft,
 770      draft-reed-ldup-infomod-00.txt, June 1999.
 771
 772
 773 [KEYWORDS]
 774      S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev-
 775      els", Harvard University, RFC 2119, March 1997.
 776
 777
 778 [LDAPv3]
 779      M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
 780
 781
 782
 783 Stokes and Good                                                [Page 14]
 784 \f
 785 Internet-Draft               LDUP Workgroup                March 10 2000
 786
 787
 788      (v3)", RFC 2251, December 1997.
 789
 790
 791 [REQ]R. Weiser, E. Stokes, "LDAP V3 Replication Requirements",
 792      Internet-Draft, draft-ietf-ldup-replica-req-02.txt, October 1999.
 793
 794
 795 [URP]S. Legg, A. Payne, "LDUP Update Reconciliation Procedures",
 796      Internet-Draft, draft-ietf-ldup-urp-02.txt, October 1999.
 797
 798 14. Author's Addresses
 799
 800    Ellen Stokes
 801    IBM
 802    11400 Burnet Rd
 803    Austin, TX 78758
 804    USA
 805    EMail: stokes@austin.ibm.com
 806    phone: +1 512 838 3725
 807    fax:   +1 512 838 0156
 808
 809    Gordon Good
 810    Netscape Communications Corp.
 811    501 E. Middlefield Rd.
 812    Mailstop MV068
 813    Mountain View, CA 94043
 814    USA
 815    EMail:  ggood@netscape.com
 816    Phone:  +1 650 937-3825
 817
 818    15. Document Revision History
 819    (This section will be removed prior to this document's publication
 820    as a proposed standard)
 821
 822    Differences between draft-ietf-ldup-protocol-00.txt and
 823    draft-ietf-ldup-protocol-01.txt:
 824
 825    1) The document was reworked to use the ldup framed protocol
 826    draft [FRAMING].
 827
 828
 829 Appendix A - Complete ASN.1 Definition
 830
 831 To be written.
 832
 833 Full Copyright Statement
 834
 835 Copyright (C) The Internet Society (1999).  All Rights Reserved.
 836
 837
 838
 839 Stokes and Good                                                [Page 15]
 840 \f
 841 Internet-Draft               LDUP Workgroup                March 10 2000
 842
 843
 844 This document and translations of it may be copied and furnished to oth-
 845 ers, and derivative works that comment on or otherwise explain it or
 846 assist in its implementation may be prepared, copied, published and dis-
 847 tributed, in whole or in part, without restriction of any kind, provided
 848 that the above copyright notice and this paragraph are included on all
 849 such copies and derivative works.  However, this document itself may not
 850 be modified in any way, such as by removing the copyright notice or
 851 references to the Internet Society or other Internet organizations,
 852 except as needed for the purpose of developing Internet standards in
 853 which case the procedures for copyrights defined in the Internet Stan-
 854 dards process must be followed, or as required to translate it into
 855 languages other than English.
 856
 857 The limited permissions granted above are perpetual and will not be
 858 revoked by the Internet Society or its successors or assigns.
 859
 860 This document and the information contained herein is provided on an "AS
 861 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
 862 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
 863 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
 864 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT-
 865 NESS FOR A PARTICULAR PURPOSE.
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895 Stokes and Good                                                [Page 16]