2 LDUP Replication Update Protocol
4 Intended Category: Standards Track
5 Expires: September 10, 2000
12 Netscape Communications Corp.
16 The LDUP Replication Update Protocol
17 Filename: draft-ietf-ldup-protocol-01.txt
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
55 Stokes and Good [Page 1]
57 Internet-Draft LDUP Workgroup March 10 2000
60 1. Status of this Memo
62 This document is an Internet-Draft and is in full conformance with
63 all provisions of Section 10 of RFC2026.
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.
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."
74 To view the list Internet-Draft Shadow Directories, see
75 http://www.ietf.org/shadow.html.
77 This Internet Draft expires September 10, 2000.
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.
92 All protocol elements described here are LDAP Version 3 extended
93 operations. LDAP Version 3 is described in RFC 2251 [LDAPv3].
95 Certain terms used in this document are defined in the document "LDAP
96 Replication Architecture" (draft-ietf-ldup-model-00.txt).
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].
102 3. Overview of Protocol
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.
111 Stokes and Good [Page 2]
113 Internet-Draft LDUP Workgroup March 10 2000
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.
127 This protocol is based upon the extended operations defined in
130 This protocol is intended to meet the requirements set forth in
133 4. High-level Description of Protocol Flow
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
143 4.1 Supplier-initiated incremental replication protocol
145 S -> C: LDAP bind operation (identity and credentials
146 used are implementation-defined)
148 C -> S: Bind response
150 S -> C: StartFramedProtocolRequest LDAPv3 extended
151 operation. The parameters are:
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
163 C -> S: StartFramedProtocolResponse LDAPv3 extended operation. The
167 Stokes and Good [Page 3]
169 Internet-Draft LDUP Workgroup March 10 2000
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.
179 S -> C: The supplier may send zero or more ReplicationUpdate LDAPv3
180 extended operations. The parameters are:
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)
187 C -> S: At any time, the consumer may send an unsolicited
188 ReplicationUpdateResponse LDAPv3 extended operation. The
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.
201 S -> C: After all required updates have been sent to the consumer, the
202 supplier sends an EndFramedProtocolRequest LDAPv3 extended
205 C -> S: The consumer responds by sending an EndFramedProtocolResponse
206 LDAPv3 extended operation, and then closes the connection.
208 4.2. Consumer-initiated replication protocol
210 C -> S: LDAP bind operation (identity and credentials
211 used are implementation-defined)
213 S -> C: Bind response
215 C -> S: StartFramedProtocolRequest LDAPv3 extended
216 operation. The parameters are:
218 1) The OID for the LDUP incremental replication protocol or the
219 LDUP total update protocol, depending on whether an incremental
223 Stokes and Good [Page 4]
225 Internet-Draft LDUP Workgroup March 10 2000
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
236 S -> C: StartFramedProtocolResponse LDAPv3 extended operation. The
239 1) A protocol-specific payload containing:
240 a) A response code (see section 7)
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).
247 5. Replication protocol element definitions
249 5.1 StartFramedProtocolRequest Extended Operation
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.
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:
265 requestValue ::= SEQUENCE {
266 framedProtocolOID LDAPOID,
267 framedProtocolPayload OPTIONAL OCTET STRING
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.
279 Stokes and Good [Page 5]
281 Internet-Draft LDUP Workgroup March 10 2000
284 The framedProtocolPayload of the StartFramedProtocolRequestValue must
285 be set to the BER-encoding of the following:
287 framedProtocolPayload ::= SEQUENCE {
289 replicaID LDAPString,
290 replicationInitiator ENUMERATED {
296 The parameters in the framedProtocolPayload of the
297 StartFramedProtocolRequestValue are:
299 - replicaRoot: the distinguished name of the entry at the top of
300 the replicated area, and uniquely identifies the unit of
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].
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.
321 5.2 StartFramedProtocolResponse Extended Operation
323 The StartFramedProtocolResponse extended operation is sent in
324 response to a StartFramedProtocolRequest extended operation.
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
335 Stokes and Good [Page 6]
337 Internet-Draft LDUP Workgroup March 10 2000
340 response field containing an error code.
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
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:
359 StartFramedProtocolResponseValue ::= SEQUENCE {
360 responseCode LDUPResponseCode,
361 replicaUpdateVector Attribute,
364 LDUPResponseCodes are defined in section 8.
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].
371 5.3 ReplicationUpdate Extended Operation
373 The ReplicationUpdate extended operation carries a set of replication
374 primitives that represent the desired final state of a single entry.
376 The ReplicationUpdate extended operation is defined as follows:
378 An LDAPv3 Extended Request is defined in [LDAPv3] as follows:
380 ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
381 requestName [0] LDAPOID
382 requestValue [1] OCTET STRING OPTIONAL
385 The requestName of the ReplicationUpdate must be the OID
386 2.16.840.1.113719.1.142.100.3.
391 Stokes and Good [Page 7]
393 Internet-Draft LDUP Workgroup March 10 2000
396 The requestValue of the ReplicationUpdate must be set to the BER-
397 encoding of the following:
399 requestValue ::= SEQUENCE {
400 uniqueID UniqueIdentifier,
401 updates SET OF ReplicationPrimitive
404 5.3.1 UniqueIdentifier
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.
412 UniqueIdentifier ::= LDAPString
415 5.3.2 ReplicationPrimitive
417 A ReplicationPrimitive carries a single assertion about the the final
418 state of an entry, attribute, or attribute value. There are seven
421 ReplicationPrimitive ::= CHOICE {
422 addEntryPrimitive AddEntryPrimitive,
423 moveEntryPrimitive MoveEntryPrimitive,
424 renameEntryPrimitive RenameEntryPrimitive,
425 removeEntryPrimitive RemoveEntryPrimitive,
426 addAttributeValuePrimitive AddAttributeValuePrimitive,
427 removeAttributeValuePrimitive RemoveAttributeValuePrimitive,
428 removeAttributePrimitive RemoveAttributePrimitive
431 Each primitive applies to the entry referred to by the
432 uniqueIdentifier in the enclosing ReplicationUpdate extended
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.
439 5.3.2.1 AddEntryPrimitive
441 The AddEntryPrimitive is used to add a new entry.
443 AddEntryPrimitive ::= [APPLICATION 0] SEQUENCE {
447 Stokes and Good [Page 8]
449 Internet-Draft LDUP Workgroup March 10 2000
452 csn lDAPChangeSequenceNumber,
453 superior UniqueIdentifier,
457 Parameters of the AddEntryPrimitive are:
459 - csn: The change sequence number of the primitive.
461 - superior: The unique identifier of the superior (parent) entry.
463 - rdn: The relative distinguished name of the new entry.
465 5.3.2.2 MoveEntryPrimitive
467 The MoveEntryPrimitive is used to move an entry to a new location in
470 MoveEntryPrimitive ::= [APPLICATION 1] SEQUENCE {
471 csn lDAPChangeSequenceNumber,
472 superior UniqueIdentifier
475 Parameters of the MoveEntryPrimitive are:
477 - csn: The change sequence number of the primitive.
479 - superior: The unique identifier of the new superior (parent)
482 5.3.2.3 RenameEntryPrimitive
484 The RenameEntryPrimitive is used to change the RDN of an entry.
486 RenameEntryPrimitive ::= [APPLICATION 2] SEQUENCE {
487 csn lDAPChangeSequenceNumber,
491 Parameters of the RenameEntryPrimitive are:
493 - csn: The change sequence number of the primitive.
495 - rdn: The new relative distinguished name of the entry.
497 5.3.2.4 RemoveEntryPrimitive
499 The RemoveEntryPrimitive is used to delete an entry from the DIT.
503 Stokes and Good [Page 9]
505 Internet-Draft LDUP Workgroup March 10 2000
508 RemoveEntryPrimitive ::= [APPLICATION 3] SEQUENCE {
509 csn lDAPChangeSequenceNumber
512 Parameters of the RemoveEntryPrimitive are:
514 - csn: The change sequence number of the primitive.
516 5.3.2.5 AddAttributeValuePrimitive
518 The AddAttributeValuePrimitive is use to add a new attribute value to
521 AddAttributeValuePrimitive ::= [APPLICATION 4] SEQUENCE {
522 csn lDAPChangeSequenceNumber,
523 type AttributeDescription,
527 Parameters of the AddAttributeValuePrimitive are:
529 - csn: The change sequence number of the primitive.
531 - type: The type of the attribute being added.
533 - value: The value being added. Multiple values are not permitted.
535 5.3.2.6 RemoveAttributeValuePrimitive
537 The RemoveAttributeValuePrimitive is used to remove a particular
538 attribute value from an entry.
540 RemoveAttributeValuePrimitive ::= [APPLICATION 5] SEQUENCE {
541 csn lDAPChangeSequenceNumber,
542 type AttributeDescription,
546 Parameters of the RemoveAttributeValuePrimitive are:
548 - csn: The change sequence number of the primitive.
550 - type: The type of the attribute being removed.
552 - value: The value being removed. Multiple values are not
555 5.3.2.7 RemoveAttributePrimitive
559 Stokes and Good [Page 10]
561 Internet-Draft LDUP Workgroup March 10 2000
564 The RemoveAttributePrimitive is used to remove an attribute and all
565 its values from an entry.
567 RemoveAttributePrimitive ::= [APPLICATION 6] SEQUENCE {
568 csn lDAPChangeSequenceNumber,
569 type AttributeDescription
572 Parameters of the RemoveAttributePrimitive are:
574 - csn: The change sequence number of the primitive.
576 - type: The type of the attribute being removed.
579 5.4 EndFramedProtocolRequest Extended Operation
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
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:
596 requestValue ::= SEQUENCE {
597 replicaUpdateVector Attribute OPTIONAL,
598 returnConsumerUpdateVector BOOLEAN
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.
610 5.5 EndFramedProtocolResponse Extended Operation
615 Stokes and Good [Page 11]
617 Internet-Draft LDUP Workgroup March 10 2000
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:
625 response ::= SEQUENCE {
626 replicaUpdateVector Attribute OPTIONAL
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.
634 5.6 ReplicationUpdateResponse Extended Operation
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.
640 An LDAPv3 extended response is defined in [LDAPv3] as follows:
642 ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
643 COMPONENTS of LDAPResult,
644 responseName [10] LDAPOID OPTIONAL,
645 response [11] OCTET STRING OPTIONAL
648 The responseName of the ReplicationUpdateResponse must be the OID [OID
651 The response field of the ReplicationUpdateResponse must be set to the
652 BER-encoding of the following:
654 response ::= SEQUENCE {
655 replicaUpdateVector Attribute OPTIONAL
659 The parameters of the ReplicationUpdateResponse are:
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.
671 Stokes and Good [Page 12]
673 Internet-Draft LDUP Workgroup March 10 2000
676 6. Semantics of Full and Incremental Update protocols
680 7. Summary of response codes
682 The following list describes the response codes that may be included in
683 the StartFramedProtocolResponse, EndFramedProtocolResponse, and
684 ReplicationUpdateResponse extended operations.
686 LDUPResponseCode ::= SEQUENCE {
687 resultCode ENUMERATED {
691 insufficientAccessRights (50),
693 excessiveCSNSkew (200),
696 errorMessage LDAPString }
698 The meanings of the response codes are as follows:
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
707 busy........................ The replica is temporarily unable to accept
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.
716 8. Implications for log-based and state-based servers
718 To be written, or possibly incorporated into [ARCHITECTURE].
720 9. Replication of access control and schema information
722 To be written, or possibly incorporated into [ARCHITECTURE].
727 Stokes and Good [Page 13]
729 Internet-Draft LDUP Workgroup March 10 2000
732 10. Security Considerations
736 11. Glossary of Terms
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
746 b) r = ri and t = ti and S < Si
747 c) r = ri and t = ti and S = Si and s < si
758 J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architec-
759 ture", Internet-Draft, draft-ietf-ldup-model-02.txt, October 1999.
763 E. Stokes, G. Good, "Extended Operations for Framing LDAP Bulk
764 Update Operations", Internet-Draft, draft-ietf-ldup-framing-00.txt,
769 E. Reed, "LDAP Replication Information Model", Internet-Draft,
770 draft-reed-ldup-infomod-00.txt, June 1999.
774 S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev-
775 els", Harvard University, RFC 2119, March 1997.
779 M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
783 Stokes and Good [Page 14]
785 Internet-Draft LDUP Workgroup March 10 2000
788 (v3)", RFC 2251, December 1997.
791 [REQ]R. Weiser, E. Stokes, "LDAP V3 Replication Requirements",
792 Internet-Draft, draft-ietf-ldup-replica-req-02.txt, October 1999.
795 [URP]S. Legg, A. Payne, "LDUP Update Reconciliation Procedures",
796 Internet-Draft, draft-ietf-ldup-urp-02.txt, October 1999.
798 14. Author's Addresses
805 EMail: stokes@austin.ibm.com
806 phone: +1 512 838 3725
810 Netscape Communications Corp.
811 501 E. Middlefield Rd.
813 Mountain View, CA 94043
815 EMail: ggood@netscape.com
816 Phone: +1 650 937-3825
818 15. Document Revision History
819 (This section will be removed prior to this document's publication
820 as a proposed standard)
822 Differences between draft-ietf-ldup-protocol-00.txt and
823 draft-ietf-ldup-protocol-01.txt:
825 1) The document was reworked to use the ldup framed protocol
829 Appendix A - Complete ASN.1 Definition
833 Full Copyright Statement
835 Copyright (C) The Internet Society (1999). All Rights Reserved.
839 Stokes and Good [Page 15]
841 Internet-Draft LDUP Workgroup March 10 2000
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.
857 The limited permissions granted above are perpetual and will not be
858 revoked by the Internet Society or its successors or assigns.
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.
895 Stokes and Good [Page 16]