GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4373

Network Working Group R. Harrison Request for Comments: 4373 J. Sermersheim Category: Informational Novell, Inc.

                                                               Y. Dong
                                                          January 2006
           Lightweight Directory Access Protocol (LDAP)
              Bulk Update/Replication Protocol (LBURP)

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 The Lightweight Directory Access Protocol (LDAP) Bulk
 Update/Replication Protocol (LBURP) allows an LDAP client to perform
 a bulk update to an LDAP server.  The protocol frames a sequenced set
 of update operations within a pair of LDAP extended operations to
 notify the server that the update operations in the framed set are
 related in such a way that the ordering of all operations can be
 preserved during processing even when they are sent asynchronously by
 the client.  Update operations can be grouped within a single
 protocol message to maximize the efficiency of client-server
 communication.
 The protocol is suitable for efficiently making a substantial set of
 updates to the entries in an LDAP server.

Harrison, et al. Informational [Page 1] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

Table of Contents

 1. Introduction ....................................................3
 2. Conventions Used in This Document ...............................3
 3. Overview of Protocol ............................................3
    3.1. Update Initiation ..........................................4
    3.2. Update Stream ..............................................4
         3.2.1. LBURPUpdateRequest ..................................4
         3.2.2. LBURPUpdateResponse .................................4
    3.3. Update Termination .........................................4
    3.4. Applicability of Protocol ..................................5
 4. Description of Protocol Flow ....................................5
 5. Elements of Protocol ............................................6
    5.1. StartLBURPRequest ..........................................7
         5.1.1. updateStyleOID ......................................7
    5.2. StartLBURPResponse .........................................7
         5.2.1. maxOperations .......................................8
    5.3. LBURPUpdateRequest .........................................8
         5.3.1. sequenceNumber ......................................8
         5.3.2. UpdateOperationList .................................9
    5.4. LBURPUpdateResponse ........................................9
         5.4.1. OperationResults ...................................10
                5.4.1.1. operationNumber ...........................10
                5.4.1.2. ldapResult ................................10
    5.5. EndLBURPRequest ...........................................10
         5.5.1. sequenceNumber .....................................10
    5.6. EndLBURPResponse ..........................................11
 6. Semantics of the Incremental Update Style ......................11
 7. General LBURP Semantics ........................................11
 8. Security Considerations ........................................12
 9. IANA Considerations ............................................13
    9.1. LDAP Object Identifier Registrations ......................13
 10. Normative References ..........................................14
 11. Informative References ........................................14

Harrison, et al. Informational [Page 2] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

1. Introduction

 The Lightweight Directory Access Protocol (LDAP) Bulk
 Update/Replication Protocol (LBURP) arose from the need to allow an
 LDAP client to efficiently present large quantities of updates to an
 LDAP server and have the LDAP server efficiently process them.  LBURP
 introduces a minimum of new operational functionality to the LDAP
 protocol because the update requests sent by the client encapsulate
 standard LDAP [RFC2251] update operations.  However, this protocol
 greatly facilitates bulk updates by allowing the client to send the
 update operations asynchronously and still allow the server to
 maintain proper ordering of the operations.  It also allows the
 server to recognize the client's intent to perform a potentially
 large set of update operations and then to change its processing
 strategy to more efficiently process the operations.

2. Conventions Used in This Document

 Imperative keywords defined in RFC 2119 [RFC2119] are used in this
 document, and carry the meanings described there.
 All Basic Encoding Rules (BER) [X.690] encodings follow the
 conventions found in section 5.1 of [RFC2251].
 The term "supplier" applies to an LDAP client or an LDAP server
 (acting as a client) that supplies a set of update operations to a
 consumer.
 The term "consumer" applies to an LDAP server that consumes (i.e.,
 processes) the sequenced set of update operations sent to it by a
 supplier.

3. Overview of Protocol

 LBURP frames a set of update operations within a pair of LDAP
 extended operations that mark the beginning and end of the update
 set.  These updates are sent via LDAP extended operations, each
 containing a sequence number and a list of one or more update
 operations to be performed by the consumer.  Except for the fact that
 they are grouped together as part of a larger LDAP message, the
 update operations in each subset are encoded as LDAP update
 operations and use the LDAP Abstract Syntax Notation One (ASN.1)
 [X.680] message types specified in [RFC2251].

Harrison, et al. Informational [Page 3] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

3.1. Update Initiation

 The protocol is initiated when a supplier sends a StartLBURPRequest
 extended operation to a consumer as a notification that a stream of
 associated LBURPUpdateRequests will follow.  The supplier associates
 semantics with this stream of requests by including the Object
 Identifier (OID) of the bulk update/replication style in the
 StartLBURPRequest.  The consumer responds to the StartLBURPRequest
 with a StartLBURPResponse message.

3.2. Update Stream

 After the consumer responds with a StartLBURPResponse, the supplier
 sends a stream of LBURPUpdateRequest messages to the consumer.
 Messages within this stream may be sent asynchronously to maximize
 the efficiency of the transfer.  The consumer responds to each
 LBURPUpdateRequest with an LBURPUpdateResponse message.

3.2.1. LBURPUpdateRequest

 Each LBURPUpdateRequest contains a sequence number identifying its
 relative position within the update stream and an UpdateOperationList
 containing an ordered list of LDAP update operations to be applied to
 the Directory Information Tree (DIT).  The sequence number enables
 the consumer to process LBURPUpdateRequest messages in the order they
 were sent by the supplier even when they are sent asynchronously.
 The consumer processes each LBURPUpdateRequest according to the
 sequence number by applying the LDAP update operations in its
 UpdateOperationList to the DIT in the order they are listed.

3.2.2. LBURPUpdateResponse

 When the consumer has processed the update operations from an
 UpdateOperationList, it sends an LBURPUpdateResponse to the supplier
 indicating the success or failure of the update operations contained
 within the corresponding LBURPUpdateRequest.

3.3. Update Termination

 After the supplier has sent all of its LBURPUpdateRequest messages,
 it sends an EndLBURPRequest message to the consumer to terminate the
 update stream.  Upon servicing all LBURPOperation requests and
 receiving the EndLBURPRequest, the consumer responds with an
 EndLBURPResponse, and the update is complete.

Harrison, et al. Informational [Page 4] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

3.4. Applicability of Protocol

 LBURP is designed to facilitate the bulk update of LDAP servers.  It
 can also be used to synchronize directory information between a
 single master and multiple slaves.
 No attempt is made to deal with the issues associated with multiple-
 master replication environments (such as keeping modification times
 of attribute values) so that updates to the same entry on different
 replicas can be correctly ordered.  For this reason, when LBURP alone
 is used for replication, proper convergence of the data between all
 replicas can only be assured in a single-master replication
 environment.

4. Description of Protocol Flow

 This section describes the LBURP protocol flow and the information
 contained in each protocol message.  Throughout this section, the
 client or server acting as a supplier is indicated by the letter "S",
 and the server acting as a consumer is indicated by the letter "C".
 The construct "S -> C" indicates that the supplier is sending an LDAP
 message to the consumer, and "C -> S" indicates that the consumer is
 sending an LDAP message to the supplier.  Note that the protocol flow
 below assumes that a properly authenticated LDAP session has already
 been established between the supplier and consumer.
     S -> C: StartLBURPRequest message.  The parameter is:
                1) OID for the LBURP update style (see section 5.1.1).
     C -> S: StartLBURPResponse message.  The parameter is:
                1) An optional maxOperations instruction
                   (see section 5.2.1).
     S -> C: An update stream consisting of zero or more
             LBURPUpdateRequest messages.  The requests MAY be sent
             asynchronously.  The parameters are:
                1) A sequence number specifying the order of
                   this LBURPUpdateRequest with respect to the
                   other LBURPUpdateRequest messages in the update
                   stream (see section 5.3.1).
                2) LBURPUpdateRequest.updateOperationList, a list
                   of one or more LDAP update operations (see section
                   5.3.2).

Harrison, et al. Informational [Page 5] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

             The consumer processes the LBURPUpdateRequest messages
             in the order of their sequence numbers and applies the
             LDAP update operations contained within each
             LBURPUpdateRequest to the DIT in the order they are
             listed.
     C -> S: LBURPUpdateResponse message.  This is sent when the
             consumer completes processing the update operations
             from each LBURPUpdateRequest.updateOperationList.
     S -> C: EndLBURPRequest message.  This is sent after the
             supplier sends all of its LBURPUpdateRequest messages
             to the consumer.  The parameter is:
                1) A sequence number that is one greater than the
                   sequence number of the last LBURPUpdateRequest
                   message in the update stream.  This allows the
                   EndLBURPRequest to also be sent asynchronously.
     C -> S: EndLBURPResponse message.  This is sent in response to
             the EndLBURPRequest after the consumer has serviced
             all LBURPOperation requests.

5. Elements of Protocol

 LBURP uses two LDAP ExtendedRequest messages--StartLBURPRequest and
 EndLBURPRequest--to initiate and terminate the protocol.  A third
 LDAP ExtendedRequest message--LBURPUpdateRequest--is used to send
 update operations from the supplier to the consumer.  These three
 requests along with their corresponding responses comprise the entire
 protocol.
 LBURP request messages are defined in terms of the LDAP
 ExtendedRequest [RFC2251] as follows:
      ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
          requestName    [0] LDAPOID,
          requestValue   [1] OCTET STRING OPTIONAL
      }
 LBURP response messages are defined in terms of the LDAP
 ExtendedResponse [RFC2251] as follows:
     ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
         COMPONENTS of LDAPResult,
         responseName  [10] LDAPOID OPTIONAL,
         response      [11] OCTET STRING OPTIONAL
      }

Harrison, et al. Informational [Page 6] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

5.1. StartLBURPRequest

 The requestName value of the StartLBURPRequest is OID 1.3.6.1.1.17.1.
 The requestValue of the StartLBURPRequest contains the BER-encoding
 of the following ASN.1:
     StartLBURPRequestValue ::= SEQUENCE {
         updateStyleOID LDAPOID
     }
 LDAPOID is defined in [RFC2251], section 4.1.2.

5.1.1. updateStyleOID

 The updateStyleOID is an OID that uniquely identifies the LBURP
 update style being used.  This document defines one LBURP update
 semantic style that can be transmitted between the StartLBURPRequest
 and EndLBURPRequest.  The updateStyleOID is included in the protocol
 for future expansion of additional update styles.  For example, a
 future specification might define an update style with semantics to
 replace all existing entries with a new set of entries and thus only
 allows the Add operation.
 The updateStyleOID for the LBURP Incremental Update style is
 1.3.6.1.1.17.7.  The semantics of this update style are described in
 section 6.

5.2. StartLBURPResponse

 The responseName of the StartLBURPResponse is the OID 1.3.6.1.1.17.2.
 The optional response element contains the BER-encoding of the
 following ASN.1:
     StartLBURPResponseValue ::= maxOperations
     maxOperations ::= INTEGER (0 .. maxInt)
     maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --

Harrison, et al. Informational [Page 7] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

5.2.1. maxOperations

 When present, the value of maxOperations instructs the supplier to
 send no more than that number of update operations per
 LBURPUpdateRequest.updateOperationList (see section 5.3.2).  If the
 consumer does not send a maxOperations value, it MUST be prepared to
 accept any number of update operations per
 LBURPUpdateRequest.updateOperationList.  The supplier MAY send fewer
 but MUST NOT send more than maxOperations update operations in a
 single LBURPUpdateRequest.updateOperationList.

5.3. LBURPUpdateRequest

 The LBURPUpdateRequest message is used to send a set of zero or more
 LDAP update operations from the supplier to the consumer along with
 sequencing information that enables the consumer to maintain the
 proper sequencing of multiple asynchronous LBURPUpdateRequest
 messages.
 The requestName of the LBURPUpdateRequest is the OID 1.3.6.1.1.17.5.
 The requestValue of an LBURPOperation contains the BER-encoding of
 the following ASN.1:
     LBURPUpdateRequestValue ::= SEQUENCE {
         sequenceNumber INTEGER (1 .. maxInt),
         updateOperationList UpdateOperationList
     }

5.3.1. sequenceNumber

 The sequenceNumber orders associated LBURPOperation requests.  This
 enables the consumer to process LBURPOperation requests in the order
 specified by the supplier.  The supplier MUST set the value of
 sequenceNumber of the first LBURPUpdateRequest to 1, and MUST
 increment the value of sequenceNumber by 1 for each succeeding
 LBURPUpdateRequest.  In the unlikely event that the number of
 LBURPUpdateRequest messages exceeds maxInt, a sequenceNumber value of
 1 is deemed to be the succeeding sequence number following a sequence
 number of maxInt.

Harrison, et al. Informational [Page 8] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

5.3.2. UpdateOperationList

 The UpdateOperationList is a list of one or more standard LDAP update
 requests and is defined as follows:
     UpdateOperationList ::= SEQUENCE OF SEQUENCE{
         updateOperation CHOICE {
            addRequest       AddRequest,
            modifyRequest    ModifyRequest,
            delRequest       DelRequest,
            modDNRequest     ModifyDNRequest
         },
         controls       [0] Controls OPTIONAL
     }
 AddRequest, ModifyRequest, DelRequest, and ModifyDNRequest are
 defined in [RFC2251], sections 4.6, 4.7, 4.8, and 4.9.
 The LDAP update requests in the UpdateOperationList MUST be applied
 to the DIT in the order in which they are listed.

5.4. LBURPUpdateResponse

 An LBURPUpdateResponse message is sent from the consumer to the
 supplier to signal that all of the update operations from the
 UpdateOperationList of an LBURPUpdateRequest have been completed and
 to give the results for the update operations from that list.
 The responseName of the LBURPUpdateResponse is the OID
 1.3.6.1.1.17.6.
 If the consumer server cannot successfully decode an
 LBURPUpdateRequest in its entirety, the resultCode for the
 corresponding LBURPUpdateResponse is set to protocolError and the
 response element is omitted.  Updates from the LBURPUpdateRequest
 SHALL NOT be committed to the DIT in this circumstance.
 If the status of all of the update operations being reported by an
 LBURPUpdateResponse message is success, the resultCode of the
 LBURPUpdateResponse message is set to success and the response
 element is omitted.
 If the status of any of the update operations being reported by an
 LBURPUpdateResponse message is something other than success, the
 resultCode for the entire LBURPUpdateResponse is set to other to
 signal that the response element is present.

Harrison, et al. Informational [Page 9] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

5.4.1. OperationResults

 When a response element is included in an LBURPUpdateResponse
 message, it contains the BER-encoding of the following ASN.1:
     OperationResults ::= SEQUENCE OF OperationResult
     OperationResult ::= SEQUENCE {
        operationNumber    INTEGER,
        ldapResult         LDAPResult
     }
 An OperationResult is included for each operation from the
 UpdateOperationList that failed during processing.

5.4.1.1. operationNumber

 The operationNumber identifies the LDAP update operation from the
 UpdateOperationList of the LBURPUpdateRequest that failed.
 Operations are numbered beginning at 1.

5.4.1.2. ldapResult

 The ldapResult included in the OperationResult is the same ldapResult
 that would be sent for the update operation that failed if it had
 failed while being processed as a normal LDAP update operation.
 LDAPResult is defined in [RFC2251], section 4.1.10.

5.5. EndLBURPRequest

 The requestName of the EndLBURPRequest is the OID 1.3.6.1.1.17.3.
 The requestValue contains the BER-encoding of the following ASN.1:
      EndLBURPRequestValue::= SEQUENCE {
          sequenceNumber INTEGER (1 .. maxInt)
      }

5.5.1. sequenceNumber

 The value in sequenceNumber is one greater than the last
 LBURPUpdateRequest.sequenceNumber in the update stream.  It allows
 the server to know when it has received all outstanding asynchronous
 LBURPUpdateRequests.

Harrison, et al. Informational [Page 10] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

5.6. EndLBURPResponse

 The responseName of the EndLBURPResponse is the OID 1.3.6.1.1.17.4.
 There is no response element in the EndLBURPResponse message.

6. Semantics of the Incremental Update Style

 The initial state of entries in the consumer's DIT plus the
 LBURPUpdateRequest messages in the update stream collectively
 represent the desired final state of the consumer's DIT.  All LDAP
 update operations defined in [RFC2251]--Add, Modify, Delete, and
 Modify DN--are allowed in the incremental update stream.  All of the
 semantics of those operations are in effect, so for instance, an
 attempt to add an entry that already exists will fail just as it
 would during a normal LDAP Add operation.

7. General LBURP Semantics

 The consumer server may take any action required to efficiently
 process the updates sent via LBURP, as long as the final state is
 equivalent to that which would have been achieved if the updates in
 the update stream had been applied to the DIT using normal LDAP
 update operations.
 The LBURPUpdateRequest messages that form the update stream MAY be
 sent asynchronously by the supplier to the consumer.  This means that
 the supplier need not wait for an LBURPUpdateResponse message for one
 LBURPUpdateRequest message before sending the next LBURPUpdateRequest
 message.
 When the LBURP update stream contains a request that affects multiple
 Directory System Agents (DSAs), the consumer MAY choose to perform
 the request or return a resultCode value of affectsMultipleDSAs.  As
 with any LDAP operation, a consumer MAY send a resultCode value of
 referral as part of the OperationResult element for any operation on
 an entry that it does not contain.  If the consumer is configured to
 do so, it MAY chain on behalf of the supplier to complete the update
 operation instead.
 While a consumer server is processing an LBURP update stream, it may
 choose not to service LDAP requests on other connections.  This
 provision is designed to allow implementers the freedom to implement
 highly-efficient methods of handling the update stream without being
 constrained by the need to maintain a live, working DIT database
 while doing so.

Harrison, et al. Informational [Page 11] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

 If a consumer chooses to refuse LDAP operation requests from other
 suppliers during LBURP update, it is RECOMMENDED that the consumer
 refer those requests to another server that has the appropriate data
 to complete the operation.
 Unless attribute values specifying timestamps are included as part of
 the update stream, updates made using LBURP are treated the same as
 other LDAP operations wherein they are deemed to occur at the
 present.  Consumers MAY store timestamp values sent by suppliers but
 are not required to do so.
 Implementations may choose to perform the operations in the update
 stream with special permissions to improve performance.
 Consumer implementations should include functionality to detect and
 terminate connections on which an LBURP session has been initiated
 but information (such as the EndLBURPRequest) needed to complete the
 LBURP session is never received.  A timeout is one mechanism that can
 be used to accomplish this.

8. Security Considerations

 Implementations should ensure that a supplier making an LBURP request
 is properly authenticated and authorized to make the updates
 requested.  There is a potential for loss of data if updates are made
 to the DIT without proper authorization.  If LBURP is used for
 replication, implementers should note that unlike other replication
 protocols, no existing replication agreement between supplier and
 consumer is required.  These risks increase if the consumer server
 also processes the update stream with special permissions to improve
 performance.  For these reasons, implementers should carefully
 consider which permissions should be required to perform LBURP
 operations and take steps to ensure that only connections with
 appropriate authorization are allowed to perform them.
 The data contained in the update stream may contain passwords and
 other sensitive data.  Care should be taken to properly safeguard
 this information while in transit between supplier and consumer.  The
 StartTLS [RFC2830] operation is one mechanism that can be used to
 provide data confidentiality and integrity services for this purpose.
 As with any asynchronous LDAP operation, it may be possible for an
 LBURP supplier to send asynchronous LBURPUpdateRequest messages to
 the consumer faster than the consumer can process them.  Consumer
 implementers should take steps to prevent LBURP suppliers from
 interfering with the normal operation of a consumer server by issuing
 a rapid stream of asynchronous LBURPUpdateRequest messages.

Harrison, et al. Informational [Page 12] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

9. IANA Considerations

 Registration of the following values has been made by the IANA
 [RFC3383].

9.1. LDAP Object Identifier Registrations

 The IANA has registered LDAP Object Identifiers identifying the
 protocol elements defined in this technical specification.  The
 following registration template was provided:
 Subject: Request for LDAP OID Registration
 Person & email address to contact for further information:
     Roger Harrison
     rharrison@novell.com
 Specification: RFC 4373
 Author/Change Controller: IESG
 Comments:
 Seven delegations will be made under the assigned OID.  The
 following 6 OIDs are Protocol Mechanism OIDs of type "E"
 (supportedExtension):
 1.3.6.1.1.17.1 StartLBURPRequest LDAP ExtendedRequest message
 1.3.6.1.1.17.2 StartLBURPResponse LDAP ExtendedResponse message
 1.3.6.1.1.17.3 EndLBURPRequest LDAP ExtendedRequest message
 1.3.6.1.1.17.4 EndLBURPResponse LDAP ExtendedResponse message
 1.3.6.1.1.17.5 LBURPUpdateRequest LDAP ExtendedRequest message
 1.3.6.1.1.17.6 LBURPUpdateResponse LDAP ExtendedResponse message
 The following 1 OID is a Protocol Mechanism OID of type "F"
 (supportedFeature):
 1.3.6.1.1.17.7 LBURP Incremental Update style OID

Harrison, et al. Informational [Page 13] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

10. Normative References

 [RFC2119]  Bradner, S., "Key Words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2251]  Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
            Access Protocol (v3)", RFC 2251, December 1997.
 [RFC3383]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
            Considerations for the Lightweight Directory Access
            Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
 [X.680]    ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002
            "Information Technology - Abstract Syntax Notation One
            (ASN.1): Specification of basic notation"
 [X.690]    ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
            "Information technology - ASN.1 encoding rules:
            Specification of Basic Encoding Rules (BER), Canonical
            Encoding Rules (CER) and Distinguished Encoding Rules
            (DER)", 2002.

11. Informative References

 [RFC2830]  Hodges, J., Morgan, R., and M. Wahl, "Lightweight
            Directory Access Protocol (v3): Extension for Transport
            Layer Security", RFC 2830, May 2000.

Harrison, et al. Informational [Page 14] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

Authors' Addresses

 Roger Harrison
 Novell, Inc.
 1800 S. Novell Place
 Provo, UT 84606
 Phone: +1 801 861 2642
 EMail: rharrison@novell.com
 Jim Sermersheim
 Novell, Inc.
 1800 S. Novell Place
 Provo, UT 84606
 Phone: +1 801 861 3088
 EMail: jimse@novell.com
 Yulin Dong
 EMail: yulindong@gmail.com

Harrison, et al. Informational [Page 15] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Harrison, et al. Informational [Page 16]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4373.txt · Last modified: 2006/01/24 23:03 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki