+++ /dev/null
-
-
-
-
-Change Record Object Class Definition Gordon Good
-INTERNET-DRAFT Netscape Communications
- 11 March 1998
-
- Definition of an Object Class to Hold LDAP Change Records
- Filename: draft-good-ldap-changelog-00.txt
-
-Status of this Memo
-
- This document is an Internet-Draft. Internet-Drafts are working
- documents of the Internet Engineering Task Force (IETF), its
- areas, and its working groups. Note that other groups may also
- distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet-
- Drafts as reference material or to cite them other than as
- ``work in progress.''
-
- To learn the current status of any Internet-Draft, please check
- the ``1id-abstracts.txt'' listing contained in the Internet-
- Drafts Shadow Directories on ds.internic.net (US East Coast),
- nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
- munnari.oz.au (Pacific Rim).
-
- This Internet Draft expires October 1st, 1998.
-
-
-
-Abstract
-
- In order to support more flexible replication methods, it is
- desirable to specify some manner in which an LDAP client may retrieve
- a set of changes which have been applied to an LDAP server's
- database. The client, which may be another LDAP server, may then
- choose to update its own replicated copy of the data. This document
- specifies an object class which may be used to represent changes
- applied to an LDAP server. It also specifies a method for
- discovering the location of the container object which holds these
- change records, so that clients and servers have a common rendezvous
- point for this information.
-
-
-
-Background and Intended Usage
-
- This document describes an objectclass which can be used to represent
-
-
-
-Good March 11, 1998 [Page 1]
-\f
-INTERNET-DRAFT Change Record Object Class 11 March 1998
-
-
- changes which have been applied to a directory server. It also
- suggests a common location for a container which holds these objects.
- A client may update its local copy of directory information by
- reading the entries within this container, and applying the changes
- to its local database.
-
- The key words "MUST", "MAY", and "SHOULD" used in this document are
- to be interpreted as described in [3].
-
-New Attribute Types Used in the changeLogEntry Object Class
-
- ( 2.16.840.1.113730.3.1.5
- NAME 'changeNumber'
- DESC 'a number which uniquely identifies a change made to a
- directory entry'
- SYNTAX 'INTEGER'
- EQUALITY 'integerMatch'
- ORDERING 'integerOrderingMatch' )
-
- ( 2.16.840.1.113730.3.1.6
- NAME 'targetDN'
- DESC 'the DN of the entry which was modified'
- EQUALITY distinguishedNameMatch
- SYNTAX 'DN' )
-
- ( 2.16.840.1.113730.3.1.7
- NAME 'changeType'
- DESC 'the type of change made to an entry'
- EQUALITY caseIgnoreMatch
- SYNTAX 'DirectoryString' )
-
- ( 2.16.840.1.113730.3.1.8
- NAME 'changes'
- DESC 'a set of changes to apply to an entry'
- SYNTAX 'OctetString' )
-
- ( 2.16.840.1.113730.3.1.9
- NAME 'newRDN'
- DESC 'the new RDN of an entry which is the target of a
- modrdn operation'
- EQUALITY distinguishedNameMatch
- SYNTAX 'DN' )
-
- ( 2.16.840.1.113730.3.1.10
- NAME 'deleteOldRDN'
- DESC 'a flag which indicates if the old RDN should be retained
- as an attribute of the entry'
- EQUALITY booleanMatch
-
-
-
-Good March 11, 1998 [Page 2]
-\f
-INTERNET-DRAFT Change Record Object Class 11 March 1998
-
-
- SYNTAX 'BOOLEAN' )
-
- ( 2.16.840.1.113730.3.1.11
- NAME 'newSuperior'
- DESC 'the new parent of an entry which is the target of a
- moddn operation'
- EQUALITY distinguishedNameMatch
- SYNTAX 'DN' )
-
-
-Schema Definition of the changeLogEntry Object Class
-
- ( 2.16.840.1.113730.3.2.1
- NAME 'changeLogEntry'
- SUP top
- STRUCTURAL
- MUST (
- changeNumber $ targetDN $ changeType
- )
- MAY (
- changes $ newRDN $ deleteOldRDN $ newSuperior
- )
- )
-
-
-
-Discussion of changeLogEntry Attributes:
-
- changeNumber: the change number, as assigned by the supplier. This
- integer MUST strictly increase as new entries are added, and must
- always be unique within a given server. Syntax: INTEGER
-
- targetdn: the distinguished name of the entry which was added,
- modified or deleted. In the case of a modrdn operation, the targetdn
- gives the DN of the entry before it was modified. Syntax: DN
-
- changeType: the type of change. One of: "add", "delete", "modify",
- "modrdn". Later RFCs may define additional values for changeType.
- Syntax: DirectoryString
-
- changes: the changes which were made to the directory server. These
- changes are in LDIF format, which is described in [1].
- Syntax: OctetString
-
- newRDN: the new RDN (Relative Distinguished Name) of the entry, if the
- changeType is "modrdn". If the changeType attribute does not have the
- value "modrdn", then there should be no values contained in the newRDN
- attribute.
-
-
-
-Good March 11, 1998 [Page 3]
-\f
-INTERNET-DRAFT Change Record Object Class 11 March 1998
-
-
- Syntax: DN
-
- deleteOldRDN: a flag which tells whether the old RDN of the entry
- should be retained as a distinguished attribute of the entry, or
- should be deleted. A value of "FALSE" indicates that the RDN should be
- retained as a distinguished attribute, and a value of "TRUE" indicates
- that it should not be retained as a distinguished attribute of the
- entry. If any value other than "TRUE" or "FALSE" is contained in the
- deleteOldRDN attribute, or if the deleteOldRDN contains multiple
- values, the RDN should be retained as a distinguished attribute (that
- is, "FALSE" is the default if no values are present, or if illegal
- values are present).
- Syntax: BOOLEAN
-
- newSuperior: if present, gives the name of the entry which
- becomes the immediate superior of the existing entry. This optional
- attribute reflects LDAPv3 functionality, and MUST NOT be generated
- by LDAPv2 servers [2].
- Syntax: DN
-
-
-
-Discussion of the changeLogEntry object class
-
- The changeLogEntry object class is used to represent changes made to a
- directory server. The set of changes made to a directory server, then,
- is given by the ordered set of all entries within the changelog
- container, ordered by changeNumber.
-
- A client may synchronize its local copy of a remote directory server's
- contents by searching the remote server's changelog container for any
- entries where the changenumber is greater than or equal to the last
- change previously retrieved from that server. If the entry with the
- changenumber matching the last change retrieved is not returned in the
- search results, then the server's changelog has been trimmed. The
- client must then fall back to reading the entire directory to bring its
- copy in sync with the server's.
-
- Assuming that the client has successfully retrieved one or more changelog
- entries from the server, it can then use the information contained in each
- entry to update the corresponding entry (named by the targetDN attribute)
- in its local copy of the database.
-
- Note that, due to access control restrictions, the client is not guaranteed
- read access to the "changes" attribute. If the client discovers that the
- "changes" attribute has no values, then it must read the entry given by
- the targetDN attribute, possibly only retrieving attributes it deems
- "interesting". However, in the case of delete and modrdn operations, there
-
-
-
-Good March 11, 1998 [Page 4]
-\f
-INTERNET-DRAFT Change Record Object Class 11 March 1998
-
-
- is never a "changes" attribute, so it is never necessary to read the target
- entry in these cases.
-
-
-
-Examples of the changeLogEntry object class
-
- In each example below, the "changes" attribute is shown in plain text,
- with embedded newlines. This is done for clarity. It is intended that
- newlines be stored in the entry literally, not encoded in any way.
- If a "changes" attribute value is stored in an LDIF file, it must
- base-64 encoded.
-
- Example 1: A changeLogEntry representing the addition of a
- new entry to the directory
-
- dn: changenumber=1923, cn=changelog
- changenumber: 1923
- targetdn: cn=Barbara Jensen, ou=Accounting, o=Ace Industry, c=US
- changetype: add
- changes: cn: Barbara Jensen\ncn: Babs Jensen\nsn: Jensen\n
- givenname: Barbara\ntelephonenumber: +1 212 555-1212\nmail: babs@ace.com\n
- objectclass: top\nobjectclass: person\nobjectclass: organizationalPerson\n
- objectclass: inetOrgPerson
-
- Example 2: A changeLogEntry representing the deletion of an entry
- from the directory
-
- dn: changenumber=2933, cn=changelog
- changenumber: 2933
- targetdn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
- changetype: delete
-
- Example 3: A changeLogEntry representing the modification of an entry
- in the directory
-
- dn: changenumber=5883, cn=changelog
- changenumber: 5883
- targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US
- changetype: modify
- changes: delete: telephonenumber\ntelephonenumber: 1212\n-\n
- add: telephonenumber\ntelephonenumber: +1 212 555 1212\n-
-
- Example 4: A changeLogEntry representing a modrdn operation performed
- on an entry in the directory
-
- dn: changenumber=10042, cn=changelog
- changenumber: 10042
-
-
-
-Good March 11, 1998 [Page 5]
-\f
-INTERNET-DRAFT Change Record Object Class 11 March 1998
-
-
- targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US
- changetype: modrdn
- newrdn: cn=Bjorn J Jensen
- deleteoldrdn: FALSE
-
-
-Location of the container containing changeLogEntry objects
-
- For LDAPv3 servers, the location of the container which holds
- changeLogEntry objects is obtained by reading the "changeLog" attribute
- of a server's root DSE. For example, if the container's root is
- "cn=changelog", then the root DSE must have an attribute named
- "changeLog" with the value "cn=changelog".
-
- The "changelog" attribute is defined as follows:
-
- ( 2.16.840.1.113730.3.1.35
- NAME 'changelog'
- DESC 'the distinguished name of the entry which contains
- the set of entries comprising this server's changelog'
- EQUALITY distinguishedNameMatch
- SYNTAX 'DN'
- )
-
- For LDAPv2 servers, the name of the changelog container must be
- "cn=changelog".
-
-
-Differences from previous versions of this document
-
- Differences between draft-ietf-asid-changelog-00.txt and
- draft-ietf-asid-changelog-01.txt
-
- 1) Fixed a deficiency in the syntax of the changeNumber attribute. The
- attribute now has INTEGER syntax, with appropriate matching and
- ordering rules defined.
-
- 2) Removed unneeded substring matching rules from the changeType and
- deleteOldRDN attribute definitions.
-
- 3) Made use of MAY, SHOULD, etc. consistent with RFC 2119.
-
- 4) Renamed document (now an individual submission).
-
- 5) Changed syntax of "changes" attribute from "Binary" to "OctetString".
-
- 6) Removed references to X.500 supplier and consumer-initiated
- replication.
-
-
-
-Good March 11, 1998 [Page 6]
-\f
-INTERNET-DRAFT Change Record Object Class 11 March 1998
-
-
- 7) Updated references to current drafts/proposed standards documents.
-
-Security Considerations
-
- Servers implementing this scheme MUST NOT allow the "changes"
- attribute to be generally readable. The "changes" attribute contains
- all modifications made to an entry, and some changes may contain
- sensitive data, e.g. passwords.
-
- If a server does allow read access on the "changes: attribute to a
- particular bound DN, then that DN should be trusted. For example, two
- cooperating servers may exchange the password for some DN which is
- granted read access to the "changes" attribute of the changeLog. This
- would allow one server to retrieve changes and apply them directly to
- its database.
-
- In situations where the "changes" attribute is not readable by a client,
- that client may still use the entries in the changeLog to construct a
- list of entry DNs which are known to have changed since the last time
- the client synchronized. The client may then read each of those entries,
- subject to whatever access control is in effect on the server,
- and update its local copy of each entry.
-
- Servers implementing this scheme should disallow write access to the
- changelog container object and all entries contained within.
-
-
-
-Acknowledgements
-
- This material is based in part upon work supported by the National
- Science Foundation under Grant No. NCR-9416667.
-
-
-
-References
-
- [1] Good, G., "The LDAP Data Interchange Format", INTERNET-DRAFT
- draft-good-ldap-ldif-03.txt, Netscape Communications Corp., March 1997,
- <URL:ftp://ftp.ietf.org/internet-drafts/draft-good-ldap-ldif-03.txt>
-
- [2] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access
- Protocol (v3)", RFC 2251 Critical Angle, Inc., Netscape Communications Corp.,
- ISODE Consortium, July, 1997,
- <URL:ftp://ftp.isi.edu/in-notes/rfc2251.txt>
-
- [3] S. Bradner, "Key Words for use in RFCs to Indicate Requirement
- Levels", Harvard University, RFC 2119, March 1997,
-
-
-
-Good March 11, 1998 [Page 7]
-\f
-INTERNET-DRAFT Change Record Object Class 11 March 1998
-
-
- <URL:http://ds.internic.net/rfc/rfc2119.txt>
-
-
-Author's Address
-
- Gordon Good
- Netscape Communications Corp.
- 501 E. Middlefield Rd.
- Mailstop MV068
- Mountain View, CA 94043, USA
- Phone: +1 415 937-3825
- EMail: ggood@netscape.com
-
- This Internet Draft expires October 1st, 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Good March 11, 1998 [Page 8]
-\f
+++ /dev/null
-
-
-
-
-
-
-
-Internet-Draft E. Stokes
-LDAP Extensions WG B. Blakley
-Intended Category: Standards Track Tivoli Systems
-Expires: 14 January 2001 D. Rinkevich
- IBM
- R. Byrne
- Sun Microsystems
- 14 July 2000
-
- Access Control Model for LDAPv3
- <draft-ietf-ldapext-acl-model-06.txt>
-
-STATUS OF THIS MEMO
-
-This document is an Internet-Draft and is in full
-conformance with all provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet
-Engineering Task Force (IETF), its areas, and its working
-groups. Note that other groups may also distribute working
-documents as Internet-Drafts. Internet-Drafts are draft
-documents valid for a maximum of six months and may be
-updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as
-reference material or to cite them other than as "work in
-progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be
-accessed at http://www.ietf.org/shadow.html.
-
-Comments and suggestions on this document are encouraged.
-Comments on this document should be sent to the LDAPEXT
-working group discussion list:
-
- ietf-ldapext@netscape.com
-
-COPYRIGHT NOTICE
-
-Copyright (C) The Internet Society (2000). All Rights
-Reserved.
-
-ABSTRACT
-
-This document describes the access control model for the
-Lightweight Directory Application Protocol V3 (LDAPv3)
-directory service. It includes a description of the model,
-the LDAP controls, and the extended operations to the LDAP
-protocol. The current LDAP APIs are sufficient for most
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 1]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-access control operations. An API (in a separate document)
-is needed for the extended operation getEffectiveAccess. A
-separate requirements document for access control exists
-[REQTS]. The access control model used the requirements
-documents as a guideline for the development of this
-specification and are reflected in this specification to the
-extent that the working group could agree on an access
-control model.
-
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
-"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and
-"MAY" used in this document are to be interpreted as
-described in [Bradner97].
-
-
-
-1. Introduction
-
-The ability to securely access (replicate and distribute)
-directory information throughout the network is necessary
-for successful deployment. LDAP's acceptance as an access
-protocol for directory information is driving the need to
-provide an access control model definition for LDAP
-directory content among servers within an enterprise and the
-Internet. Currently LDAP does not define an access control
-model, but one is needed to ensure consistent secure access,
-replication, and management across heterogeneous LDAP
-implementations. The major objective is to provide a simple,
-usable, and implementable, but secure and efficient access
-control model for LDAP while also providing the appropriate
-flexibility to meet the needs of both the Internet and
-enterprise environments and policies. This document defines
-the model and the protocol extensions (controls and extended
-operations).
-
-This draft does not (and cannot) fully specify the behavior
-of the Access Control Model in a distributed environment
-(e.g. propagating access control information across servers
-and ACI administration) because there is no LDAP standard
-defining how to distribute directory data between LDAP
-servers. The behavior of the Access Control Model in
-distributed environments is beyond the scope of this draft.
-
-
-
-2. The LDAPv3 Access Control Model
-
-Access Control mechanisms evaluate requests for access to
-protected resources and make decisions about whether those
-requests should be granted or denied. In order to make a
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 2]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-grant/deny decision about a request for access to a
-protected resource, an access control mechanism needs to
-evaluate policy data. This policy data describes security-
-relevant characteristics of the requesting subject and the
-rules which govern the use of the target object.
-
-No mechanism is defined in this document for storage of
-access control information at the server beyond indicating
-that the attribute holding access control information is an
-operational attribute.
-
-The access control mechanisms specified in this document are
-neutral with respect to policy inheritance mechanisms,
-explicit vs. implicit denial, and group nesting.
-
-The access control model defines
-
- - What flows on the wire for interoperability
-
- The existing LDAP protocol flows for ldap operations
- are used to manipulate access control information. A
- set of permissions and their semantics with respect to
- ldap operations is defined. The permissions parallel
- the types of ldap operations defined. What is
- transmitted is exactly what is read back. Encoding of
- access control information on the wire is per the
- LDAPv3 specifications.
-
- There is an additional LDAP control and extended
- protocol operation defined, getEffectiveRights. LDAP
- clients use the control and extended operation to
- manage and administer access control policy enforced by
- LDAP servers.
-
- Servers may store access control information in any way
- they choose. In particular, servers may use the access
- control mechanisms of their datastores to store and
- enforce LDAP access control, or they may implement
- access control managers external to their datastores.
- Datastores and external access control managers MAY
- implement any access control rule syntax and semantics
- they choose, but the semantics MUST be compatible with
- those defined in the section titled "Operational
- Semantics of Access Control Operations".
-
- - Attributes and classes for application portability of
- access control information
-
- An access control information attribute (ldapACI) for
- application portability: This attribute is used as
- input to the LDAP APIs so access control information
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 3]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- can be addressed uniformly independent of how that
- information is addressed and stored at the server.
- This same attribute appears in LDIF output for
- interchange of access control information.
-
- An access control information subentry class
- (ldapACISubEntry) and a set of attributes
- (supportedAccessControlSchemes which is used in the
- rootDSE and accessControlSchemes which is used in the
- subentry ldapACISubEntry) to identity the access
- control mechanisms supported by a server and in a given
- part of the namespace, respectively.
-
- - An attribute in the rootDSE, discloseOnError, to
- control whether it is permissible for the server to
- return the name of an entry or attribute in an error
- (or empty set) operation result. This closes a hole on
- the ability to discover information you are not
- authorized to discover.
-
- - A mechanism to control access to access control
- information: The access control information attribute,
- ldapACI, is used to control access to access control
- information (controls access to itself). How to get an
- initial ldapACI in the directory is server specific and
- beyond the scope of this model.
-
-Servers can support multiple access control mechanisms, but
-MUST be capable of supporting the LDAP Mechanism in the DIT
-scoped by the rootDSE (entire server's DIT) for that server
-and SHOULD be capable of supporting the LDAP mechanism in an
-arbitrary part (subtree) of the DIT.
-
-The accessControlSchemes attribute in the ldapACISubEntry
-indicates which access control mechanism is in effect for
-the scope of that ldapACISubEntry. The
-supportedAccessControlSchemes attribute in the rootDSE
-indicates which acess control mechanisms are supported by
-the server; those mechanisms are in effect in that server's
-DIT unless overridden by a mechanism defined in a
-ldapACISubEntry elsewhere in that DIT.
-
-Changing the value(s) of either the
-supportedAccessControlSchemes or accessControlSchemes
-attributes changes the mechanism(s) in effect for the scope
-of those attributes (where scope is either that of the
-rootDSE or ldapACISubEntry).
-
-Through the use of the mechanism rootDSE attribute and
-ldapACI subentry, it is possible to run multiple mechanisms
-in either the same subtree or separate subtrees. If two
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 4]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-mechanisms are run in the same subtree, it is desirable that
-the result be the same independent of mechanism, but
-definition and discussion of this is beyond the scope of
-this model.
-
-
-
-3. Access Control Mechanism Attributes
-
-Two attributes are defined to identify which access control
-mechanisms are supported by a given server and by a given
-subtree: supportedAccessControlSchemes and
-accessControlSchemes. (We chose these names based on the
-X.500 attribute, AccessControlScheme which is single-valued
-and defined in X.501).
-
-
-3.1 Root DSE Attribute for Access Control Mechanism
-
-The server advertises which access control mechanisms it
-supports by inclusion of the 'supportedAccessControlSchemes'
-attribute in the root DSE. This attribute is a list of
-OIDs, each of which identify an access control mechanism
-supported by the server. By default, these are also the
-mechanisms in effect in subtrees beneath the root in that
-server unless overridden by a ldapACISubEntry (see section
-"Subentry Class Access Control Mechanism").
-
- (<OID to be assigned>
- NAME 'supportedAccessControlSchemes'
- DESC list of access control mechanisms supported
- by this directory server
- SYNTAX LDAPOID
- USAGE dSAOperation
- )
-
-The access control mechanism defined is:
- LDAPv3 <OID to be assigned>
-
-Other vendor access control mechanisms MAY be defined (by
-OID) and are the responsibility of those vendors to provide
-the definition and OID.
-
-
-3.2 Root DSE Attribute for Control of Disclosing Errors
-
-The server specifies whether it is permissible for the name
-of an entry or attribute to be disclosed in an error (or
-empty) operation result. This rootDSE attribute is
-discloseOnError. The default for discloseOnError is false
-(0) or not to disclose on error. The lack of this attribute
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 5]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-in the rootDSE is interpreted as the default.
-
- (<OID to be assigned>
- NAME 'discloseOnError'
- DESC specify whether to return the name of an
- entry or attribute in an error (or
- empty) operation result; 0=do not
- disclose (default); 1=disclose
- SYNTAX LDAPString
- USAGE dSAOperation
-
-
-3.3 Subentry Class Access Control Mechanism
-
-A given naming context MUST provide information about which
-access control mechanisms are in effect for that portion of
-the namespace. This information is contained in a subentry
-(ldapACISubEntry class), derived from [SUBENTRY].
-ldapACISubEntry MAY be used to define the scope of an access
-control mechanism. The value(s) held in the rootDSE
-attribute, supportedAccessControlSchemes, are the mechanisms
-in effect in subtrees beneath the root in that server unless
-overridden in a ldapACISubEntry further down the tree held
-by that server. The scope of that ldapACISubEntry is to the
-end of the subtree held by that server or until another
-ldapACISubEntry is encountered in that subtree held by that
-server. The ldapACISubEntry class is defined as:
-
-
- ( <OID to be assigned>
- NAME 'ldapACISubEntry'
- DESC 'LDAP ACI Subentry class'
- SUP ldapSubEntry STRUCTURAL
- MUST ( accessControlSchemes )
- )
-
-The accessControlSchemes attribute MUST be in each ldap
-access control subentry entry associated with a naming
-context whose access control mechanism is different from
-adjacent naming contexts supported by that directory server.
-accessControlSchemes lists the values (list of OIDs) that
-define the access control mechanisms in effect for the scope
-of that ldap access control subentry. Although, in general,
-this attribute will define only a single mechanism (single
-value), more than one mechanism MAY be in effect for the
-scope of that subentry.
-
- (<OID to be assigned>
- NAME 'accessControlSchemes'
- DESC list of access control mechanisms supported
- in this subtree
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 6]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- SYNTAX LDAPOID
- USAGE dSAOperation
- )
-
-
-
-4. The Access Control Information Attribute (ldapACI)
-
-The access control information attribute, ldapACI, is
-defined as:
-
- (<OID to be assigned>
- NAME 'ldapACI'
- DESC 'ldap access control information'
- EQUALITY caseIgnoreMatch
- SYNTAX directoryString
- USAGE directoryOperation
- )
-
-The intent of the attribute definition is to design a common
-interchange format. Any given LDAP server should be able to
-translate the below defined attribute into meaningful
-operation requests. Each server should be able to understand
-the attribute; there should not be any ambiguity into what
-any part of the syntax means.
-
-While the end goal is to have a common behavior model
-between different LDAP server implementations, the attribute
-definition alone will not ensure identical ACL processing
-behavior between servers. The semantics of how a server
-interprets the ACI syntax are defined in the "Operational
-Semantics of Access Control" section of this document.
-Additionally, while the server must recognize and act on the
-attribute when received over the wire, there are no
-requirements for the server to physically store this
-attribute.
-
-The attribute definition maintains an assumption that the
-receiving server supports inheritance within the security
-model. If the server does not support inheritance, the
-receiving server must expand any inherited information based
-on the scope flag. If the server does not support partial
-inheritance and both the entry and subtree scope are used,
-then entry is the prevailing scope. (It is possible for two
-values in the ldapACI attribute to have different scopes
-given the syntax of ldapACI; one might contain 'entry' and
-another might contain 'subtree'. This implies that some
-ldapACI values inherit down the DIT and othersdo not - hence
-partial inheritance of the ldapACI attribute.)
-
-The attribute is defined so access control information (ACI)
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 7]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-can be addressed in a server independent of server
-implementation. This attribute is used in typical LDAP APIs
-and in LDIF output of ACI. This attribute may be queried or
-set on all directory objects. The BNF and definitions are
-given below.
-
-
-4.1 The BNF
-
-
-4.1.1 ACI String Representation
-
- Values of this syntax are encoded according to the
- following BNF which follows the BNF encoding
- conventions described in [ABNF]:
-
- ldapACI = scope "#" rights "#" attr "#" subject
-
- scope = "entry" / "subtree"
-
- rights = (("grant:" / "deny:") permissions) /
- ("grant:" permissions ";deny:" permissions)
-
- permissions = [permission *("," permission)]
-
- permission = "a" / ; add
- "d" / ; delete
- "e" / ; export
- "i" / ; import
- "n" / ; renameDN
- "b" / ; browseDN
- "t" / ; returnDN
- "r" / ; read
- "s" / ; search
- "w" / ; write (mod-add)
- "o" / ; obliterate (mod-del)
- "c" / ; compare
- "m" / ; make
-
- attr = "[all]" / "[entry]" / (attribute *("," attribute))
-
- attribute = ; OID syntax (1.3.6.1.4.1.1466.115.121.1.38)
- ; from [ATTR]
-
- subject = ["authnLevel:" authnLevel ":"]
- (("authzID-" authzID) /
- ("role:" dn) /
- ("group:" dn) /
- ("subtree:" dn) /
- ("ipAddress:" ipAddress) /
- "public:" /
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 8]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- "this:")
-
- authnLevel = "any" /
- "simple" /
- sasl
-
- sasl = "sasl:"
- ("any" /
- mechanism)
-
- mechanism = ; sasl mechanism from 4.2 of [LDAPv3]
-
- authzID = ; authzID from [AuthMeth] repeated below
- ; for convenience
-
- authzId = dnAuthzId / uAuthzId
-
- ; distinguished-name-based authz id.
- dnAuthzId = "dn:" dn
-
- dn = utf8string ; with syntax defined in [UTF]
-
- ; unspecified userid, UTF-8 encoded.
- uAuthzId = "u:" userid
- userid = utf8string ; syntax unspecified
-
- ipAddress = printableString
- ; dotted decimal form (e.g. 10.0.0.6)
- ; or use wildcards such as 12.3.45.* to
- ; specify a specific subnetwork
- ; or 123.45.6.*+255.255.255.115 to
- ; specify a subnetmask
- ; or use a wildcard domain name such as
- ; *.airius.com to specify a specific
- ; DNS domain
-
- printableString ; printableString syntax from [ATTR]
-
-
-Note that the colon following the "public" and "this"
-subject options exist only to simplify string parsing.
-
-Note also that per [AuthMeth], authzID may be expanded in
-the future.
-
-See section titled 'ACI Examples' for examples of the string
-representation.
-
-
-
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 9]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-4.1.2 ACI Binary Representation
-
- The following ASN.1 data type is used to represent this
- syntax when transferred in binary form:
-
- ldapACI ::= SEQUENCE {
- scope ENUMERATED {
- entry (0),
- subtree (1) },
- rights SEQUENCE OF CHOICE {
- grant [0] Permissions,
- deny [1] Permissions },
- attr CHOICE {
- all [0] NULL,
- entry [1] NULL,
- attributes [2] SEQUENCE OF Attribute },
- subject SEQUENCE {
- authnLevel CHOICE {
- any [0] NULL,
- simple [1] NULL,
- sasl [2] CHOICE {
- any [0] NULL,
- mechanism [1] LDAPString -- from [LDAPv3]
- }
- },
- subject CHOICE {
- dn [0] DN,
- user [1] utf8String
- role [1] DN,
- group [2] DN,
- subtree [3] DN,
- ipAddress [4] IPAddress,
- public [6] NULL,
- this [7] NULL }, } -- may be expanded
- per [AuthMeth]
-
- Permissions ::= SEQUENCE OF ENUMERATED {
- add (0),
- delete (1),
- export (2),
- import (3),
- renameDN (4),
- browseDN (5),
- returnDN (6),
- read (7),
- search (8),
- write (9),
- obliterate (10),
- compare (11),
- make (12) }
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 10]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- Attribute ::= AttributeType -- from [LDAPv3]
-
- IPAddress ::= PrintableString -- (e.g. 10.0.0.6)
-
-
-
-4.2 The Components of ldapACI Attribute
-
-This section defines components that comprise the access
-control information attribute, ldapACI.
-
-
-4.2.1 Scope
-
-Two scopes for access control information are defined:
-
- - entry - the access control information in the ldapACI
- attribute applies only to the entry in which it is
- contained
-
- - subtree - the access control information in the ldapACI
- attribute applies to each entry down the subtree unless
- it is overridden by an entry-specific ldapACI whose
- values are more specific.
-
-Use of prescriptive ACIs and scoping via use of a
-ldapACISubEntry is outside the scope of this document.
-
-
-4.2.2 Access Rights and Permissions
-
-Access rights can apply to an entire object or to attributes
-of the object. Access can be granted or denied. Either or
-both of the actions "grant" | "deny" may be used when
-creating or updating ldapACI.
-
-Each of the LDAP access permissions are discrete. One
-permission does not imply another permission. The
-permissions which apply to attributes and the entry parallel
-the type of ldap operations that can be performed.
-
-Permissions which apply to attributes:
-
- r Read Read attribute values
- w Write Modify-add values
- o Obliterate Modify-delete values
- s Search Search entries with specified attributes
- c Compare Compare attributes
- m Make Make attributes on a new entry below
- this entry
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 11]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- 1. r Read
-
- If granted, permits attributes and values to be
- returned in a read or search operation.
-
- 2. w Write
-
- If granted, permits attributes and values to be added
- in a modify operation.
-
- 3. o Obliterate
-
- If granted, permits attributes and values to be
- deleted in a modify operation.
-
- 4. s Search
-
- If granted, permits attributes and values to be
- included in a search operation.
-
- 5. c Compare
-
- If granted, permites attributes and value to be used
- in a compare operation.
-
- 6. m Make
-
- The attribute permission "m" is required for all
- attributes that are placed on an object when it is
- created. Just as the "w" and "o" permissions are used
- in the Modify operation, the "m" permission is used in
- the Add operation. Additionally, note that "w" and "o"
- have no bearing on the Add operation and "m" has no
- bearing on the Modify operation. Since a new object
- does not yet exist, the "a" and "m" permissions needed
- to create it must be granted on the new object's
- parent. This differs from "w" and "o" which must be
- granted on the object being modified. The "m"
- permission is distinct and separate from the "w" and
- "o" permissions so that there is no conflict between
- the permissions needed to add new children to an entry
- and the permissions needed to modify existing children
- of the same entry.
-
-Note: Modify-replace values of an attribute requires "w"
-and "o" permission.
-
-Permissions that apply to an entire entry:
-
-
- a Add Add an entry below this entry
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 12]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- d Delete Delete this entry
- e Export Export entry & subordinates to new
- location
- i Import Import entry & subordinates from some
- location
- n RenameDN Rename an entry's DN
- b BrowseDN Browse an entry's DN
- t ReturnDN Allows DN of entry to be disclosed in
- an operation result
-
-
- 1. a Add
-
- If granted, permits creation of an entry in the DIT
- subject to control on all attributes and values to be
- placed in the new entry at time of creation. In order
- to add an entry, permission must also be granted to
- add at least the mandatory attributes.
-
- 2. d Delete
-
- If granted, permits the entry to be removed from the
- DIT regardless of controls on attributes within the
- entry.
-
- 3. e Export
-
- If granted, permits an entry and its subordinates (if
- any) to be exported; that is, removed from the current
- location and placed in a new location subject to the
- granting of suitable permission at the destination.
- If the last RDN is changed, Rename is also required at
- the current location. In order to export an entry or
- its subordinates, there are no prerequisite
- permissions to contained attributed, including the RDN
- attributes; this is true even when the operation
- causes new attribute values to be added or removed as
- the result of the changes of RDN.
-
- 4. i Import
-
- If granted, permits an entry and its suordinates (if
- any) to be imported; that is, removed from some other
- location and placed a t the location to which the
- permission applies subject to the granting of suitable
- permissions at the source location. In order to
- import an entry or its subordinates, there are no
- prerequisite permissions to contained attributed,
- including the RDN attributes; this is true even when
- the operation causes new attribute values to be added
- or removed as the result of the changes of RDN.
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 13]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- 5. n RenameDN
-
- Granting Rename is necessary for an entry to be
- renamed with a new RDN, taking into account
- consequential changes to the distinguished names of
- subordinate entries, if any; if the name of the
- superior is unchanged, the grant is sufficient. In
- order to rename an entry, there are no prerequisite
- permissions to contained attributed, including the RDN
- attributes; this is true even when the operation
- causes new attribute values to be added or removed as
- the result of the changes of RDN.
-
- 6. b BrowseDN
-
- If granted, permits entries to be accessed using
- directory operations which do not explicitly provide
- the name of the entry.
-
- 7. t ReturnDN
-
- If granted, allows the distinguished name of the entry
- to be disclosed in the operation result.
-
-All permissions (for grant and deny) for an attribute/entry
-and a given subject MUST be contained within one ldapACI
-value, i.e. (in abbreviated form)
-
- ldapACI: ...grant OID.attr1 subjectA
- ldapACI: ...deny OID.attr1 subjectA
-
-must be ldapACI: ...grant ... deny... OID.attr1 subjectA
-
-Using the defined BNF it is possible for the permission
-string to be empty. The ACI
-
- ldapACI: subtree#grant#OID.attr1#group:cn=Dept XYZ,c=US
-
- ldapACI: subtree#grant:r,s#[all]#group:cn=Dept XYZ,c=US
-
-means that this group (Dept XYZ) is granted permission to
-read and search all attributes except OID.attr1 because
-OID.attr1 is more specific than "[all]".
-
-
-4.2.3 Attributes
-
-Attribute describes an attribute name in the form of a
-dotted decimal OID for that <attr>. If the string (OID)
-refers to an attribute not defined in the given server's
-schema, the server SHOULD report an error. "[entry]" means
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 14]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-the permissions apply to the entire object. This could mean
-actions such as delete the object, or add a child object.
-"[all]" means the permission set apply to all attributes of
-the entry.
-
-If the keyword "[all]" and another attribute are both
-specified within an ACI, the more specific permission set
-for the attribute overrides the less specific permission set
-for "[all]".
-
-
-4.2.4 Subjects and Associated Authentication
-
-The following subjects are defined and MUST be supported:
-
- - authzID, defined per [authmeth]
-
- - group, defined as the distinguished name of a
- groupOfNames or groupOfUniqueNames entry
-
- - role
-
- - subtree, defined as the distinguished name of a non-
- leaf node in the DIT
-
- - ipAddress,
-
- - public, defined as public access
-
- - this, defined as the user whose name matches that of
- the entry being accessed
-
-Other parties MAY define other subjects. It is the
-responsibility of those parties to provide the definition.
-
-A subject may be qualified by the type of authentication
-required for access to a given attribute(s) or entry. If no
-authnLevel is present, then no specific type of
-authentication is additionally required for access. If
-authnLevel is specified, then that type of authentication is
-additionally required for access. The authnLevels parallel
-the authentication mechanisms specified for LDAPv3: simple,
-SASL (any type of SASL mechanism), and a SASL-specific
-mechanism. The authnLevel of is not an acceptable mechanism
-for this case) as part of obtaining access.
-
-
-4.3 Grant/Deny Evaluation Rules
-
-The decision whether to grant or deny a client access to a
-particular piece of information is based on several pieces
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 15]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-of information found within the ldapaci value. Throughout
-the decision making process, there are guiding principals.
-
- - Specificity: More specific policies MUST override less
- specific ones (e.g. individual user entry in ACI takes
- precedence over group entry).
-
- - Deny takes precedence over Grant.
-
- - When there are conflicting ACI values, deny takes
- precedence over grant.
-
- - Deny is the default when there is no access control
- information.
-
-Precendence of Scope Types (highest to lowest)
-
- - entry
-
- - subtree
-
-Precedence of Subjects within a Scope (highest to lowest):
-
- - ipAddress
-
- - authzID, this
-
- - group, role, this, public
-
- - subtree, public
-
-Although other types MAY be defined given the BNF, use of
-the well-known types aids in interoperability and
-operational consistency.
-
-Access Decision algorithm:
-
- 1. Determine all the ldapACI values which could apply to
- the target DN which is being accessed. This is the DN
- of the entry which is being queried in a search,
- modified, deleted, etc. When determining all the
- ldapACI values, the scope field should be used. All
- ldapACI values with a scope of 'entry' take precedence
- over ldapACI values with a scope of 'subtree'.
-
- 2. Determine which ldapACI (of the set determined in step
- 1) apply to the bound DN. This is determined by
- looking at the subject (combination of subject type
- and subject value) and bind type. If no bind is in
- effect (this is possible in ldapv3), then treat this
- lack of bind as if bound as anonymous. Start with the
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 16]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- most specific subject type. If at any time, at least
- one ldapACI value exists for a specificity level, then
- processing stops; the exception here is 'this' because
- this may also be combined with group to use power of
- 'this'. Evaluation should take place on set of
- ldapACI values which are all of the same specificity
- level. Subjects of the same precedence are combined
- using union semantics.
-
- 3. Evaluate the remaining ldapACI values and determine a
- grant/deny decision. If conflicting ldapACI value
- exists for the same attribute, or attributes (i.e. one
- ldapACI grants permission and another denies
- permission), then deny takes precedence over grant.
- For example, if one is granted permission to
- "objectclass" in one ldapACI value by being a member
- of group cn=Admin, and denied permission by being a
- member of cn = NontrustedAdmins, then the bound user
- would not receive permission to objectclass.
-
- The rule of specificity also applies to the
- attributes. If one is denied permission to "[ all ]"
- attributes, but granted permission to "objectclass"
- then the more specific value of "objectclass" takes
- precedence over the less specific value of "[ all ] ".
- In this case the user would be granted permission to
- "objectclass" but denied permission to all other
- attributes.
-
-
-
-5. Required Permissions for each LDAP Operation
-
-This section defines the required permissions for each LDAP
-operation but even if these requirements are satisfied the
-server MAY refuse to carry out the operation due to other
-implementation specific security considerations. For
-example, a server may refuse to modify an entry because the
-database where that entry resides is in read only mode.
-Another example might be that although the access control is
-available to the userPassword attribute a server may refuse
-modifications due to some server specific policy governing
-access to passwords.
-
-Here, we specify the rights required by a user when
-performing an LDAP operation in terms of the LDAP
-permissions specified in section 6.1. Recall that "a, d,
-e, i, n, b,t" are permissions that apply to entries as a
-whole while permissions "r, s, w, o, c, m" apply to
-attributes within entries.
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 17]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-Required permissions for LDAP extended operations and LDAP
-controls are beyond the scope of this draft.
-
-There is a requirement that a user should not be able to
-infer the existence of data in the Directory, if the user
-does not have the required access rights to that data. An
-example of this requirement would be in a hosting
-environment where you would not want any users from the coke
-subtree to be able to even discover that the pepsi tree was
-hosted on the same server. This "discloseOnError" feature
-will be set once for server in the rootDSE advertised by the
-attribute discloseOnError. The default for discloseOnError
-is false (0). The lack of this attribute in the rootDSE is
-interpreted as the default. The details of its effects are
-addressed below, operation by operation.
-
-For the following, assume that the authorization identity of
-the user doing the operation is authzID.
-
-
-5.1 Bind Operation
-
-This draft does not require any permissions to allow a bind
-operation to proceed.
-
-
-5.2 Search Operation
-
-Recall that the parameters of the Search operation per RFC
-2251 [LDAPv3] Section 4.5 are:
-
- SearchRequest ::= [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2) },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeDescriptionList }
-
-Suppose a server is processing a search request from user
-authzID with parameters as above and is processing the entry
-with dn candidateDN to decide if it may be returned or not.
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 18]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-Then the permissions required by authzID that need to be
-evaluated are as follows:
-
-
- 1. permission "b" to the entry candidateDN
-
- If this permission is not granted then the dn
- candidateDN MUST not be returned nor any attribute
- type nor attribute value from this entry.
-
- If this permission is granted then the dn candidateDN
- MAY be returned.
-
- Note: The idea of the "b" permission is to say "a user
- has discovery rights" at a certain entry in the
- directory. Assuming that the further required
- permissions below are satisfied then having "b" right
- is enough to allow the server to return candidateDN.
- Of course candidateDN contains in it's components,
- attributes and attribute values for all the ancestors
- of candidateDN. This can lead to the slightly odd
- situation that we can discover the naming attribute of
- an entry and that attribute's value by virtue of
- having the required searching permissions to it's
- child but not by searching the entry directly.
-
- 2. permission "s" to each attribute appearing in a
- presence test during the evaluation of the search
- filter. permission "r" to each attribute appearing in
- non-presence tests (see rfc1960, section 3:
- equalityMatch, substrings, greaterOrEquial,
- lessOrEqual, present, approxMatch, extensibleMatch)
- during the evaluation of the search filter.
-
- The above statement covers the case where the
- attributes are being evaluated as part of an
- extensibleMatch (RFC 2251 section 4.5.1) which appears
- in the filter. In the case where the dnAttributes
- field of the extensibleMatch is true then we do not
- require any access checks to the attributes of the dn
- candidateDN as access to these is taken to be granted
- by the "b" permission, which has already been required
- above.
-
- If there is an attribute in a filter element to which
- the required permission is not granted then that
- filter element evaluates to "Undefined" of the three-
- valued-logic of X.511(93).
-
- Note A: Although both "r" and "s" permissions will
- typically be granted to attributes we keep both
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 19]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- permissions as there are cases where the distinction
- is useful. For example, the ability to grant the
- right to discover that a user entry contains a
- userPassword attribute, but not to read it's value
- ("s" but not "r"). The converse, granting "r" but not
- "s" permission is less easy to motivate.
-
- Note B: There is an unusual behaviour with respect to
- naming attributes illustrated in the following
- example:
-
- Suppose I have "b" rights to cn=fred,o=sun.com and "r"
- rights to attribute objectclass but not "r" rights to
- cn then with search filter (objectclass=*) I get back
- the dn and objectclass (and so can see the value of
- cn), but with a search filter of (cn=fred) I do not
- get anything.
-
- 3. permission "r" to each attribute in the attribute list
-
- AttributeDescriptionList (or all attributes in the
- entry candidateDN if AttributeDescriptionList is *)
- whose type and/or value will be returned.
-
- Note: The presence of an attribute in an entry is only
- ever volunteered by the server if "r" permission is
- granted to it, though a user may infer the presence of
- an attribute with "s" permission by using a presence
- test on that attribute in the search filter.
-
- 4. permission "t" to the entry candidateDN
-
- If this permission is not granted then the dn
- candidateDN MUST NOT be returned. If the server knows
- of an alias for the entry, this alias may be returned
- instead. If no alias name is available then the entry
- candidateDN MUST be omitted from the search results.
-
-
- 5. Disclose on error for the Search operation
-
- If every entry in the scope of the search fails to
- satisfy item 1 (browse right on the candidate entry)
- or item 2 (right to use the filter on that entry) and
- if discloseOnError is not granted to the baseObject
- entry then the operation MUST fail with a "no such
- object error" and the matchedDN of the LDAPResult MUST
- be set to "". If every entry in the scope of the
- search fails to satisfy items 1 or 2 above and
- discloseOnError is granted to the baseObject then the
- empty set of results is returned.
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 20]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-5.3 Modify Operation
-
-Recall that the parameters of the Modify operation per
-RFC2251 [LDAPv3] Section 4.6 are:
-
- ModifyRequest ::= [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- modification SEQUENCE OF SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2) },
- modification AttributeTypeAndValues } }
-
-
- AttributeTypeAndValues ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
-Then the permissions required by authzID that need to be
-evaluated are as follows:
-
-
- 1. permission "w" to each attribute being added to object
-
- If this permission is not granted to such an
- attribute, then the operation MUST fail. In this
- case, if discloseOnError is not granted to the entry
- then "no such object" error is returned; if
- discloseOnError is granted to the entry and a
- duplicate attribute value is being added then
- "attribute value already exists" error is returned; if
- discloseOnError is granted to the entry and no
- duplicate value is being added then an "insufficient
- access" error is returned.
-
- 2. permission "o" to each attribute for which a value is
- being deleted from object
-
- If this permission is not granted to such an attribute
- then the operation MUST fail. In this case, if
- discloseOnError is not granted to the entry then "no
- such object" error is returned; if discloseOnError is
- granted to the entry and the attribute or one of the
- values to be deleted does not exist then a "no such
- attribute or value" error is returned; if
- discloseOnError is granted to the entry and the
- attribute and all values specified to be deleted exist
- then an "insufficient access" error is returned.
-
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 21]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- 3. permissions "o" and "w" to each attribute being
- replaced in object
-
- If one of these these permissions is not granted to
- such an attribute then the operation MUST fail. In
- this case, if discloseOnError is not granted to the
- entry then a "no such object" error is returned; if
- discloseOnError is granted to the entry then
- "insufficient access" error is returned.
-
-
-5.4 Add Operation
-
-Recall that the parameters of the Add operation per RFC2251
-[LDAPv3] Section 4.7 are:
-
- AddRequest ::= [APPLICATION 8] SEQUENCE {
- entry LDAPDN,
- attributes AttributeList }
-
-
- AttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
-Then the permissions required by authzID that need to be
-evaluated are as follows:
-
- permission "a" to the parent of entry
-
- The access rights required for the creation of a root
- entry in the Directory are beyond the scope of this
- document. They will be vendor specific.
-
- 1. permission "m" to the parent of entry for each
- attribute being added to entry
-
-If any of these permissions are not granted then the
-operation MUST fail. In this case if discloseOnError is on
-and the entry to be added does not already exist then
-"insufficient access" is returned. If it does exist then
-"Entry already exists" is returned. If discloseOnError is
-off then "No such object" is returned (meaning the parent
-object).
-
-If they are all granted then the operation MAY proceed.
-
-Note: We require "m" permission to each attribute to prevent
-an entry from aquiring "unintended" rights (via group or
-role membership), to stop a "rogue" ACI being added that
-would prevent even admins deleting the entry and general
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 22]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-consistency with the MODIFY operation.
-
-Note: The access rights required for the creation of the
-first entry in the directory are beyond the scope of this
-document.
-
-
-5.5 Delete Operation
-
-Recall that the parameters of the Delete operation per
-RFC2251 [LDAPv3] Section 4.10 are:
-
- DelRequest ::= [APPLICATION 10] LDAPDN
-
-Then the permissions required by authzID that need to be
-evaluated are as follows:
-
-
- 1. permission "d" to the entry in the Delete request
-
-If this permission is not granted, then the operation MUST
-fail. In this case if discloseOnError is on and the entry
-to be deleted exists then "insufficient access" is returned.
-If it does not exist then "No such Object" is returned. If
-discloseOnError is off then "No such object" is returned
-(meaning the parent object).
-
-If this permission is granted, then the operation MAY
-proceed.
-
-Note: One could also require the "o" permission to be
-granted to allow the operation to proceed, but customer
-experience has shown that the requirement of the additional
-permission is not useful nor expected, and X.500 requires
-only the "d" permission.
-
-
-5.6 Modify DN Operation
-
-Recall that the parameters of the Modify DN operation per
-RFC2251 [LDAPv3] Section 4.6 are:
-
- ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN,
- newSuperior [0] LDAPDN OPTIONAL }
-
-Then the permissions required by authzID that need to be
-evaluated are as follows:
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 23]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- 1. If newSuperior is not present (ie. only the RDN is
- being renamed) then permission "n" to entry is
- required.
-
- 2. If newSuperior is present then permission "e" to entry
- and permission "i" to newSuperior are required.
-
-If any of these permissions are not granted then the
-operation MUST fail. In this case, if discloseOnError is on
-then an "insufficient access error" is returned. Otherwise,
-"No such object" is returned.
-
-If they are all granted then the operation MAY proceed.
-
-Note A: We do not require any additional permissions in the
-case where deleteoldrdn is TRUE.
-
-Note B: These permissions allow the naming attribute of an
-entry (or entries) to be changed even though "o" and "w"
-permissions are not available on the entry. Distinguishing
-the permissions like this allows us to grant permissions for
-the ModifyDN operation, but not the Modify operation and
-vice versa.
-
-
-5.7 Compare Operation
-
-Recall that the parameters of the Compare operation per
-RFC2251 [LDAPv3] Section 4.10 are:
-
- CompareRequest ::= [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion }
-
-Then the permissions required by authzID that need to be
-evaluated are as follows:
-
-
- 1. permission "c" to the attribute in entry on which the
- comparison is being made.
-
-If any of these permissions are not granted then the
-operation MUST fail. In this case, if discloseOnError is on
-then an "insufficient access error" is returned. Otherwise,
-"No such object" is returned.
-
-If they are all granted then the operation MAY proceed.
-
-
-
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 24]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-5.8 Abandon Operation
-
-Recall that the parameters of the Abandon operation per
-RFC2251 [LDAPv3] Section 4.6 are:
-
- AbandonRequest ::= [APPLICATION 16] MessageID
-
-authzID always has the right to send an Abandon Operation
-for an operation he previously initiated.
-
-
-5.9 Extended Operation
-
-Recall that the parameters of the Extended operation per
-RFC2251 [LDA{v3] Section 4.12 are:
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
-The access required for an Extended Operation is beyond the
-scope of this document. The required access will normally
-be defined by the implementor of the extended request.
-
-
-
-6. Required Permissions for Handling Aliases and References
-
-
-Use of aliases and referrals are part of LDAPv3. However,
-neither is particularly well-defined. Alias
-objects/attributes are defined in RFC 2256 as derived from
-X.500, but LDAPv3 does not explicitly define its semantics
-or behavior. X.500 does define alias semantics and behavior
-with respect to access control; we define its behavior in
-LDAPv3 based on the X.511, section 7.11.1. Referrals and
-knowledge information are still under design in LDAPv3; they
-are defined in X.500, however, X.500 punts on their
-semantics and behavior with respect to access control. We
-define their semantics and behavior in LDAPv3 in terms that
-should be independent of the future LDAPv3 definition of
-referrals and knowledge information.
-
-
-6.1 ACI Distribution
-
-Currently there is no LDAP standard defining how to
-distribute directory data between LDAP servers. Consequently
-this draft cannot fully specify the behavior of the Access
-Control Model in a distributed environment. The case of
-distribution via referrals is treated in the "Referrals"
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 25]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-section below. In the case of chaining (where one LDAP
-server forwards a request to another on behalf of a client)
-then it is server specific how the access control model
-behaves in this environment. Similarly it is server specific
-how the server determines whether the chaining of an
-operation is permitted in the first place. For example, the
-implementation may choose to regard the local naming context
-and the remote subordinate naming context as seperate Access
-Control Specific Areas, or it may regard the DIT as one
-Access Control Specific Area and implement mechanisms to
-propagate access control information between the two
-servers. The behavior of the Access Control Model in
-distributed environments such as these is beyond the scope
-of this draft.
-
-
-6.2 Aliases
-
-There are two things to protect with respect to aliases:
-the real name of the aliased object and the location of the
-server holding it.
-
-If alias de-referencing is required in the process of
-locating a target entry, no specifc permissions are
-necessary for alias de-referencing to take place. Access
-control is enforced at the object pointed to by the alias.
-
-If alias de-referencing would result in a
-continuationReference (e.g. from a search operation), then
-browse permission is required to the alias entry and read
-permission is required to the 'aliasedObjectName' attribute.
-Requiring these permission closes the hole of discovery.
-
-
-6.3 Referrals
-
-If a referral is to be followed, no specifc permissions are
-necessary for the ldap client to follow the referral. Access
-control is enforced at the referenced object. If a referral
-is returned, then browse is required on the entry and read
-permission is required to the attribute containing the
-referral (we cannot name this attribute exactly today
-because there are no RFCs on this - only drafts). If the
-server implements a default referral, then no special
-permissions are required to read and return that referral.
-Requiring these permissions closes the hole of discovery.
-In the default case, it is assumed that a default referral
-is public.
-
-
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 26]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-7. Controlling Access to Access Control Information
-
-The ldapACI attribute is used to specify control for who has
-permission to set/change access control information
-(ldapACI). The ldapACI attribute/OID is just another
-attribute described with a scope, set of rights and
-permissions, and subject as a value of the ldapACI
-attribute. (See the example in the "ACI Examples" section).
-
-If the policy for controlling the ldapACI attribute is not
-specified for any object in the tree, behavior is
-implementation defined. For instance, if no object anywhere
-in the tree defines the access for ldapACI within the
-ldapACI attribute, then the server could simply assert that
-the 'root DN' is considered the policy owner (controller for
-controlling access control) for all objects.
-
-
-
-8. ACI Examples
-
-Note that in the examples, the form "OID.<attrname>" refers
-to the OID in dotted decimal form for the attribute
-<attrname>. This shorthand notation is used only for the
-examples. In implementation, the dotted decimal form of the
-OID is used.
-
-
-8.1 Attribute Definition
-
-The following examples show the access required to control
-access to the ldapACI attribute. The first example shows
-controlling the access control on an individual entry and
-its attributes. The second example shows controlling the
-access control on a subtree.
-
- ldapACI: entry#grant:r,w#
- OID.ldapACI#authnLevel:any:role:cn=aciAdmin
-
- ldapACI: subtree#grant:r,w#
- OID.ldapACI#authnLevel:any:role:cn=aciAdmin
-
-The next example shows a ldapACI attribute where a group
-"cn=Dept XYZ, c=US" is being given permissions to read,
-search, and compare attribute attr1. The permission applies
-to the entire subtree below the node containing this ACI.
-Authentication of a specified type is not required.
-
- ldapACI:subtree#grant;r,s,c#
- OID.attr1#group:cn=Dept XYZ,c=US
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 27]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-The next example shows an ACI attribute where a role
-"cn=SysAdmins,o=Company" is being given permissions to add
-objects below this node and read, search, and compare
-attributes attr2 and attr3. The permission applies to the
-entire subtree below the node containing this ACI.
-
- ldapACI: subtree#grant:a#
- [entry]#role:cn=SysAdmins,o=Company
-
- ldapACI: subtree#grant:r,s,c#
- OID.attr2#role:cn=SysAdmins,o=Company
-
- ldapACI: subtree#grant:r,s,c#
- OID.attr3#role:cn=SysAdmins,o=Company
-
-
-8.2 Modifying the ldapACI Values
-
-Modify-Replace works as defined in the ldap operation
-modify. If the attribute value does not exist, create the
-value. If the attribute does exist, replace the value. If
-the ldapACI value is replaced, all ldapACI values are
-replaced.
-
-A given ldapACI for an entry:
-
- ldapACI: subtree#deny:r,w#[all]#group:cn=Dept ABC
-
- ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
-
-perform the following change:
-
- dn: cn=someEntry
- changetype: modify
- replace: ldapACI
- ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN
-
-The resulting ACI is:
-
-ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN
-
-( ldapACI values for Dept XYZ and ABC are lost through the
-replace )
-
-During an ldapmodify-add, if the ACI does not exist, the
-create the ACI with the specific ldapACI value(s). If the
-ACI does exist, then add the specified values to the given
-ldapACI. For example a given ACI:
-
-ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 28]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-with a modification:
-
- dn: cn=someEntry
- changetype: modify
- add: ldapACI
- ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
-
-would yield an multi-valued ACI of:
-
- ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
-
- ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
-
-To delete a particular ACI value, use the regular ldapmodify
-- delete syntax
-
-Given an ACI of:
-
- ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
- ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
-
- dn: cn = some Entry
- changetype: modify
- delete: ldapACI
- ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
-
-would yield a remaining ACI on the server of
-
-ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
-
-The attributes which are defined for access control
-interchange may be used in all LDAP operations.
-
-Within the ldapmodify-delete operation, the entire acl may
-be deleted by specifying
-
- dn: cn = some Entry
- changetype: modify
- delete: ldapACI
-
-In this case, the entry would then inherit its ACI from some
-other node in the tree depending on the server inheritance
-model.
-
-Similarly, if all values of ldapACI are deleted, then the
-access control information for that entry is defined by that
-implementation's inheritance model.
-
-
-
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 29]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-8.3 Evaluation
-
-These examples assume that the ldapACI entries listed in
-each example are the only ACI which applies to the entry in
-question; if backing-store ACI also exists, the effective
-policy may be different from that listed in each example.
-See section 10 for a discussion of the semantics of ldapACI
-entries when backing-store ACI administration is also used.
-
-Assume cn=jsmith is a member of group cn=G1. Assume
-cn=jsmith is a member of group cn=G2.
-
- Example #1
- dn: o=XYZ, c=US
- ldapACI: subtree#grant:r#attr1
- #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US
- ldapACI: subtree#grant:w#attr1
- #group:cn=G1,ou=ABC,o=XYZ,c=US
-
- What rights does cn=jsmith have to attr1 of o=XYZ,c=US?
- Read (r) access; authzID is higher precedence than
- group.
-
-
- Example #2
- dn: o=XYZ, c=US
- ldapACI: subtree#grant:r#attr2
- #group:cn=G1,ou=ABC,o=XYZ,c=US
- ldapACI: subtree#grant:w#attr2
- #group:cn=G2,ou=ABC,o=XYZ,c=US
-
- What rights does cn=jsmith have to attr2 of o=XYZ,c=US?
- Read-write (r,w) access; ACI is combined because both
- subjects (group) have same precedence.
-
-
- Example #3
- dn: o=XYZ, c=US
- ldapACI: subtree#grant:r,w#attr3
- #group:cn=G1,ou=ABC,o=XYZ,c=US
- ldapACI: subtree#deny:w#attr3#group:cn=G2,ou=ABC,o=XYZ,c=US
-
- What rights does cn=jsmith have to attr3 of o=XYZ, c=US?
- Read access; write is denied (deny has precedence over
- grant).
-
-
- Example #4
- dn: o=XYZ, c=US
- ldapACI: subtree#grant:w#attr4
- #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 30]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- ldapACI: subtree#grant:r#attr4#subtree:ou=ABC,ou=XYZ,c=US
-
- What rights does cn=jsmith have to attr4 of o=XYZ, c=US?
- Write (w); rights given to an authzID take precedence
- over those given to a subtree.
-
-
- Example #5
- dn: o=XYZ, c=US
- ldapACI: subtree#grant:m#OID.attr5
- #authzID-dn:cn=jsmith,o=ABC,c=US
- ldapACI: subtree#grant:m#OID.cn
- #authzID-dn:cn=jsmith,o=ABC,c=US
- ldapACI: subtree#grant:m#OID.sn
- #authzID-dn:cn=jsmith,o=ABC,c=US
- ldapACI: subtree#grant:a#[entry]
- #authzID-dn:#cn=jsmith,o=ABC,c=US
-
- What rights does cn=jsmith have to o=XYZ, c=US?
- Make(m) on attributes attr5, cn, and sn and Add(a)
- on the entry. These are the minimal yet sufficient
- permissions to create a new object,
- cn=New, o=XYZ, c=US with values for the attr5, cn,
- and sn attributes. This example illustrates how the
- "m" permission can be used to limit the attributes
- that can be created on a new entry.
-
- Example #6
- dn: c=US
- ldapACI: subtree#grant:m#[all]#subtree:c=US
- dn: o=XYZ, c=US
- ldapACI: subtree#grant:a#[entry]#
- authzID-dn:cn=jsmith,o=ABC,c=US
-
- What rights does cn=jsmith have to o=XYZ, c=US?
- Make(m) on attributes all attributes and Add(a) on the
- entry. These are sufficient permissions to create a new
- object, cn=New, o=XYZ, c=US with values any desired
- attributes. For administrators who do not wish to limit
- the attributes that can be created on new entries, this
- example shows how a single ldapACI at the top of the
- domain solves the problem.
-
-
-
-9. Operational Semantics of Access Control Operations
-
-The semantics of access control operations described in this
-document are defined operationally in terms of "histories".
-A history is a sequence of actions (x1, x2, ..., xN).
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 31]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-9.1 Types of actions
-
-We consider five types of actions:
-
- - LDAP Access Control Policy Update actions: invocations
- of ldap modify when used to add, delete, or replace the
- aci attribute; invocations of ldap add when used to add
- an entry with an aci attribute. A LDAP Access Control
- Policy Update action may replace the policy (by
- completely replacing the aci attribute with new policy
- information) or it may grant or deny specific rights
- while leaving others unaffected.
-
- - LDAP Access Control Policy Query operations:
- invocations of ldap search when used to retrieve the
- aci attribute; invocations of ldap search with the
- getEffectiveRightsRequest control; invocations of the
- ldapGetEffectiveRightsRequest extended operation.
-
- - Datastore Access Control Policy Update Actions: any
- operation implemented by the server which LDAP is using
- as its datastore which changes the access policy
- enforced with respect to attempts to access LDAP
- directory entries and their attributes.
-
- - LDAP Access Request operations: invocations of LDAP
- entry or attribute access operations (Read, Update,
- Search, Compare, etc...).
-
- - Other operations: anything else, including Datastore
- operations which do not change the access policy
- enforced by the server.
-
-
-9.2 Semantics of Histories
-
-The semantics of histories are defined as follows:
-
- - LDAP Update (Replace), LDAP Query
-
- The Query will show that the subject has all rights
- granted by the Update operation, and no rights not
- granted by the Update operation.
-
- - LDAP Update (Grant), LDAP Query
-
- The Query will show that the subject has all rights
- granted by the Update operation. The Query may show
- that the subject also has other rights not granted by
- the Update operation, depending on the policy in force
- before the Update operation.
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 32]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- - LDAP Update (Deny), LDAP Query
-
- The Query will show that the subject does not have any
- right denied by the Update operation. The Query may
- show that the subject has rights not denied by the
- Update operation, depending on the policy in force
- before the Update operation.
-
- - LDAP Update (Replace), LDAP Access Request
-
- The Request will succeed if it requires only rights
- granted to the requesting subject by the Update
- operation. The Request will fail if it requires any
- right not granted by the Update operation.
-
- - LDAP Update (Grant), LDAP Access Request
-
- The Request will succeed if it requires only rights
- granted to the requesting subject by the Update
- operation. The Request may succeed if it requires
- rights not granted by the Update operation, depending
- on the policy in force before the Update operation.
-
- - LDAP Update (Deny), LDAP Access Request
-
- The Request will fail if it requires any right denied
- to the requesting subject by the Update operation. If
- the Request requires only rights which were not denied
- by the Update operation, it may succeed, depending on
- the policy in force before the Update operation.
-
- - LDAP Update (Replace), Other, LDAP Query
-
- The Query will show that the subject has all rights
- granted by the Update operation, and no rights not
- granted by the Update operation.
-
- - LDAP Update (Grant), Other, LDAP Query
-
- The Query will show that the subject has all rights
- granted by the Update operation. The Query may show
- that the subject also has other rights not granted by
- the Update operation, depending on the policy in force
- before the Update operation.
-
- - LDAP Update (Deny), Other, LDAP Query
-
- The Query will show that the subject does not have any
- right denied by the Update operation. The Query may
- show that the subject has rights not denied by the
- Update operation, depending on the policy in force
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 33]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- before the Update operation.
-
- - LDAP Update (Replace), Other, LDAP Access Request
-
- The Request will succeed if it requires only rights
- granted to the requesting subject by the Update
- operation. The Request will fail if it requires any
- right not granted by the Update operation.
-
- - LDAP Update (Grant), Other, LDAP Access Request
-
- The Request will succeed if it requires only rights
- granted to the requesting subject by the Update
- operation. The Request may succeed if it requires
- rights not granted by the Update operation, depending
- on the policy in force before the Update operation.
-
- - LDAP Update (Deny), Other, LDAP Access Request
-
- The Request will fail if it requires any right denied
- to the requesting subject by the Update operation. If
- the Request requires only rights which were not denied
- by the Update operation, it may succeed, depending on
- the policy in force before the Update operation.
-
- - LDAP Update (Replace), Datastore Policy Update, LDAP
- Query
-
- The result of the Query is not defined.
-
- - LDAP Update (Grant), Datastore Policy Update, LDAP
- Query
-
- The result of the Query is not defined.
-
- - LDAP Update (Deny), Datastore Policy Update, LDAP Query
-
- The result of the Query is not defined.
-
- - LDAP Update (Replace), Datastore Policy Update, LDAP
- Access Request
-
- The result of the Access Request is not defined.
-
- - LDAP Update (Grant), Datastore Policy Update, LDAP
- Access Request
-
- The result of the Access Request is not defined.
-
- - LDAP Update (Deny), Datastore Policy Update, LDAP
- Access Request
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 34]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- The result of the Access Request is not defined.
-
-
-
-10. Access Control Parameters for LDAP Controls & Extended
-Operations
-
-This section defines the parameters used in the access
-control LDAP controls and extended operations in this
-document.
-
-targetDN specifies the initial directory entry in DN syntax
-on which the control or extended operation is performed.
-
-whichObject specifies whether the access control information
-(in the get effective rights control) which is retrieved is
-for the target directory entry (ENTRY) or the target
-directory entry and its subtree (SUBTREE).
-
-rights in the get effective rights control or extended
-operation response is of the form specified in the BNF for
-<rights>.
-
-subject is a LDAP string that defines the subject. Access
-control is get/set on a subject. The syntax of the subject
-is the same as the subject field in the BNF.
-
-
-
-11. Access Control Information (ACI) Controls
-
-The access control information controls provide a way to
-manipulate access control information in conjunction with a
-LDAP operation. One LDAP control is defined. This control
-allows access control information to be retrieved while
-manipulating other directory information for that entry.
-The control is:
-
- - getEffectiveRights to obtain the effective rights for a
- given directory entry(s) for a given subject during a
- ldap_search operation
-
-11.1 getEffectiveRights Control
-
-
-11.1.1 Request Control
-
-This control may only be included in the ldap_search
-message as part of the controls field of the
-LDAPMessage, as defined in Section 4.1.12 of [LDAPv3].
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 35]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-The controlType is set to <OID to be assigned>. The
-criticality MAY be either TRUE or FALSE (where absent is
-also equivalent to FALSE) at the client's option. The
-controlValue is an OCTET STRING, whose value is the BER
-encoding of a value of the following SEQUENCE:
-
- getEffectiveRightsRequest ::= SEQUENCE {
- effectiveRightsRequest SEQUENCE OF SEQUENCE {
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- subject <see <subject > in BNF> | "*"
- }
- }
-
-The effectiveRightsRequest is a set of sequences that state
-the whichObject (entry or entry plus subtree) and specifics
-of the control request to be performed. A "*" in the subject
-field specifies that all DN types are to be used in
-returning the effective rights. This control is applied to
-the filter and scope set by the ldap_search operation, i.e.
-base, one-level, subtree. So the attributes/values returned
-are defined by the ldap_search operation.
-
-11.1.2 Response Control
-
-This control is included in the ldap_search_response message
-as part of the controls field of the LDAPMessage, as defined
-in Section 4.1.12 of [LDAPv3].
-
-The controlType is set to <OID to be assigned>. There is no
-need to set the criticality on the response. The
-controlValue is an OCTET STRING, whose value is the BER
-encoding of a value of the following SEQUENCE:
-
- getEffectiveRightsResponse ::= {
- result ENUMERATED {
- success (0),
- operationsError (1),
- unavailableCriticalExtension (12),
- noSuchAttribute (16),
- undefinedAttributeType (17),
- invalidAttributeSyntax (21),
- insufficientRights (50),
- unavailable (52),
- unwillingToPerform (53),
- other (80)
- }
- }
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 36]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-The effective rights returned are returned with each entry
-returned by the search result. The control response for
-ldap_search is:
-
- PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE {
- rights <see <rights> in BNF>,
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- subject < see <subject> in BNF >
- }
-
-Although this extends the search operation, there are no
-incompatibilities between versions. LDAPv2 cannot send a
-control, hence the above structure cannot be returned to a
-LDAPv2 client. A LDAPv3 client cannot send this request to
-a LDAPv2 server. A LDAPv3 server not supporting this
-control cannot return the additional data.
-
-11.1.3 Client-Server Interaction
-
-The getEffectiveRightsRequest control requests the rights
-that MUST be in effect for requested directory
-entry/attribute based on the subject DN. The server that
-consumes the search operation looks up the rights for the
-returned directory information based on the subject DN and
-returns that rights information.
-
-There are six possible scenarios that may occur as a result
-of the getEffectiveRights control being included on the
-search request:
-
-
- 1. If the server does not support this control and the
- client specified TRUE for the control's criticality
- field, then the server MUST return
- unavailableCriticalExtension as a return code in the
- searchResponse message and not send back any other
- results. This behavior is specified in section 4.1.12
- of [LDAPv3].
-
- 2. If the server does not support this control and the
- client specified FALSE for the control's criticality
- field, then the server MUST ignore the control and
- process the request as if it were not present. This
- behavior is specified in section 4.1.12 of [LDAPv3].
-
- 3. If the server supports this control but for some
- reason such as cannot process specified family and the
- client specified TRUE for the control's criticality
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 37]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
- field, then the server SHOULD do the following: return
- unavailableCriticalExtension as a return code in the
- searchResult message.
-
- 4. If the server supports this control but for some
- reason such as cannot process specified family and the
- client specified FALSE for the control's criticality
- field, then the server should process as 'no rights
- returned for that family' and include the result
- Unavailable in the getEffectiveRightsResponse control
- in the searchResult message.
-
- 5. If the server supports this control and can return the
- rights per the family information, then it should
- include the getEffectiveRightsResponse control in the
- searchResult message with a result of success.
-
- 6. If the search request failed for any other reason,
- then the server SHOULD omit the
- getEffectiveRightsResponse control from the
- searchResult message.
-
-The client application is assured that the correct rights
-are returned for scope of the search operation if and only
-if the getEffectiveRightsResponse control returns the
-rights. If the server omits the getEffectiveRightsResponse
-control from the searchResult message, the client SHOULD
-assume that the control was ignored by the server.
-
-The getEffectiveRightsResponse control, if included by the
-server in the searchResponse message, should have the
-getEffectiveRightsResult set to either success if the rights
-are returned or set to the appropriate error code as to why
-the rights could not be returned.
-
-The server may not be able to return a right because it may
-not exist in that directory object's attribute; in this
-case, the rights request is ignored with success.
-
-
-12. Access Control Extended Operation
-
-An extended operation, get effective rights, is defined to
-obtain the effective rights for a given directory entry for
-a given subject. This operation may help with the
-management of access control information independent of
-manipulating other directory information.
-
-
-
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 38]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-12.1 LDAP Get Effective Rights Operation
-
-ldapGetEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE
-{
- requestName [0] <OID to be assigned>,
- requestValue [1] OCTET STRING OPTIONAL }
-
- where
-
- requestValue ::= SEQUENCE {
- targetDN LDAPDN,
- updates SEQUENCE OF SEQUENCE {
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- attr SEQUENCE {
- attr <see <attr> in BNF >
- },
- subject < see <subject> in BNF > | "*"
- }
- }
-
-
-The requestName is a dotted-decimal representation of the
-OBJECT IDENTIFIER corresponding to the request. The
-requestValue is information in a form defined by that
-request, encapsulated inside an OCTET STRING.
-
-The server will respond to this with an LDAPMessage
-containing the ExtendedResponse which is a rights list.
-
-ldapGetEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE
-{
- COMPONENTS OF LDAPResult,
- responseName [10] <OID to be assigned> OPTIONAL,
- effectiveRights [11] OCTET STRING OPTIONAL }
-
- where
-
- effectiveRights ::= SEQUENCE OF SEQUENCE {
- rights <see <rights> in BNF>,
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- subject < see <subject> in BNF >
- }
-
-If the server does not recognize the request name, it MUST
-return only the response fields from LDAPResult, containing
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 39]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-the protocolError result code.
-
-
-
-13. Security Considerations
-
-This document proposes protocol elements for transmission of
-security policy information. Security considerations are
-discussed throughout this draft. Because subject security
-attribute information is used to evaluate decision requests,
-it is security-sensitive information and must be protected
-against unauthorized modification whenever it is stored or
-transmitted.
-
-Interaction of access control with other directory functions
-(other than the ones defined in this document) are not
-defined in this document, but instead in the documents where
-those directory functions are defined. For example, the
-directory replication documents should address the
-interaction of access control with the replication function.
-
-
-
-14. References
-
-[LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory
-Access Protocol (v3)", RFC 2251, December 1997.
-
-[ECMA] ECMA, "Security in Open Systems: A Security
-Framework" ECMA TR/46, July 1988.
-
-[REQTS] Stokes, Byrne, Blakley, "Access Control Requirements
-for LDAP", RFC 2820, May 2000.
-
-[ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight
-Directory Access Protocol (v3)": Attribute Syntax
-Definitions, RFC 2252, December 1997.
-
-[UTF] M. Wahl, S. Kille, "Lightweight Directory Access
-Protocol (v3)": A UTF-8 String Representation of
-Distinguished Names", RFC 2253, December 1997.
-
-[Bradner97] Bradner, Scott, "Key Words for use in RFCs to
-Indicate Requirement Levels", RFC 2119.
-
-[AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R.
-Morgan, "Authentication Methods for LDAP", RFC 2829, May
-2000.
-
-[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax
-Specifications: ABNF", RFC 2234, November 1997.
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 40]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-ACKNOWLEDGEMENT
-
-This is to acknowledge the numerous companies and individuals who have
-contributed their valuable help and insights to the development of this
-specification.
-
-
-AUTHOR(S) ADDRESS
-
- Ellen Stokes Bob Blakley
- Tivoli Systems Tivoli Systems
- 6300 Bridgepoint Parkway 6300 Bridgepoint Parkway
- Austin, TX 78731 Austin, TX 78731
- USA USA
- mail-to: estokes@tivoli.com mail-to: blakley@tivoli.com
- phone: +1 512 436 9098 phone: +1 512 436 1564
- fax: +1 512 436 1199 fax: +1 512 436 1199
-
-
- Debbie Rinkevich Robert Byrne
- IBM Sun Microsystems
- 11400 Burnet Rd 29 Chemin du Vieux Chene
- Austin, TX 78758 Meylan ZIRST 38240
- USA France
- mail-to: djbrink@us.ibm.com mail-to: rbyrne@france.sun.com
- phone: +1 512 838 1960 phone: +33 (0)4 76 41 42 05
- fax: +1 512 838 8597
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 41]
-\f
-
-
-
-
-Internet-Draft Access Control Model 14 July 2000
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stokes, et al Expires 14 January 2001 [Page 42]
-\f
-
-
-
-
-
-
-
-
- CONTENTS
-
-
- 1. Introduction....................................... 2
-
- 2. The LDAPv3 Access Control Model.................... 2
-
- 3. Access Control Mechanism Attributes................ 5
- 3.1 Root DSE Attribute for Access Control
- Mechanism.................................... 5
- 3.2 Root DSE Attribute for Control of Disclosing
- Errors....................................... 5
- 3.3 Subentry Class Access Control Mechanism...... 6
-
- 4. The Access Control Information Attribute
- (ldapACI).......................................... 7
- 4.1 The BNF...................................... 8
- 4.1.1 ACI String Representation 8
- 4.1.2 ACI Binary Representation 10
- 4.2 The Components of ldapACI Attribute.......... 11
- 4.2.1 Scope 11
- 4.2.2 Access Rights and Permissions 11
- 4.2.3 Attributes 14
- 4.2.4 Subjects and Associated
- Authentication 15
- 4.3 Grant/Deny Evaluation Rules.................. 15
-
- 5. Required Permissions for each LDAP Operation....... 17
- 5.1 Bind Operation............................... 18
- 5.2 Search Operation............................. 18
- 5.3 Modify Operation............................. 21
- 5.4 Add Operation................................ 22
- 5.5 Delete Operation............................. 23
- 5.6 Modify DN Operation.......................... 23
- 5.7 Compare Operation............................ 24
- 5.8 Abandon Operation............................ 25
- 5.9 Extended Operation........................... 25
-
- 6. Required Permissions for Handling Aliases and
- References......................................... 25
- 6.1 ACI Distribution............................. 25
- 6.2 Aliases...................................... 26
- 6.3 Referrals.................................... 26
-
- 7. Controlling Access to Access Control
- Information........................................ 27
-
- 8. ACI Examples....................................... 27
- 8.1 Attribute Definition......................... 27
- 8.2 Modifying the ldapACI Values................. 28
- 8.3 Evaluation................................... 30
-
-
-
- - i -
-
-
-
-
-
-
-
-
-
-
-
- 9. Operational Semantics of Access Control
- Operations......................................... 31
- 9.1 Types of actions............................. 32
- 9.2 Semantics of Histories....................... 32
-
-10. Access Control Parameters for LDAP Controls &
- Extended Operations................................ 35
-
-11. Access Control Information (ACI) Controls.......... 35
- 11.1 getEffectiveRights Control................... 35
- 11.1.1 Request Control 35
- 11.1.2 Response Control 36
- 11.1.3 Client-Server Interaction 37
-
-12. Access Control Extended Operation.................. 38
- 12.1 LDAP Get Effective Rights Operation.......... 39
-
-13. Security Considerations............................ 40
-
-14. References......................................... 40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - ii -
-
-
-
-
-
-
-
-
-
-
-
-Full Copyright Statement
-
-Copyright (C) The Internet Society (2000).á All Rights
-Reserved.
-
-This document and translations of it may be copied and
-furnished to others, and derivative works that comment on or
-otherwise explain it or assist in its implementation may be
-prepared, copied, published and distributed, in whole or in
-part, without restriction of any kind, provided that the
-above copyright notice and this paragraph are included on
-all such copies and derivative works.á However, this
-document itself may not be modified in any way, such as by
-removing the copyright notice or references to the Internet
-Society or other Internet organizations, except as needed
-for the purpose of developing Internet standards in which
-case the procedures for copyrights defined in the Internet
-Standards process must be followed, or as required to
-translate it into languages other than English.
-
-The limited permissions granted above are perpetual and will
-not be revoked by the Internet Society or its successors or
-assigns.
-
-This document and the information contained herein is
-provided on an "AS IS" basis and THE INTERNET SOCIETY AND
-THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - iii -
-
-
-
-
+++ /dev/null
-
-
-LDAPEXT Working Group J. Sermersheim
-Internet Draft Novell, Inc
-Document: draft-ietf-ldapext-ldapv3-dupent-03.txt March 2000
-Category: Proposed Standard
-
-
- LDAP Control for a Duplicate Entry Representation of Search Results
-
-
-1. Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026 [1].
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts. Internet-Drafts are draft documents valid for a maximum of
- six months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet- Drafts
- as reference material or to cite them other than as "work in
- progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-2. Abstract
-
- This document describes a Duplicate Entry Representation control
- extension for the LDAP Search operation. By using the control with
- an LDAP search, a client requests that the server return separate
- entries for each value held in the specified attributes. For
- instance, if a specified attribute of an entry holds multiple
- values, the search operation will return multiple instances of that
- entry, each instance holding a separate single value in that
- attribute.
-
-3. Overview
-
- The Server-Side Sorting control [SSS] allows the server to order
- search result entries based on attribute values (sort keys). It
- does not allow one to specify behavior when an attribute contains
- multiple values. The default behavior, as outlined in 7.9 of
- [X.511], is to use the smallest value as the sort key.
-
- An application may need to produce an ordered list of entries,
- sorted by a multi-valued attribute, where each attribute value is
- represented in the list. In order to do this, a separate control is
- needed which causes the set of entries to be expanded sufficiently
- to represent each attribute value prior to sorting.
-
-
- Sermersheim Standards Track - Expires Sep 2000 Page 1
-\f
-LDAP Control for a Duplicate Entry Representation of Search Results
-
-
- This document describes controls, which allow duplicate entries in
- the result set of search, where each entry represents a distinct
- value of a given multiple valued attribute.
-
- An example of this would be a sorted list of all telephone numbers
- in an organization. Because any entry may have multiple telephone
- numbers, and the list is to be sorted by telephone number, the list
- must be able to contain duplicate entries, each with its own unique
- telephone number.
-
- Another example would be an application that needs to display an
- ordered list of all members of a group. It would use this control
- to create a result set of duplicate groupOfNames entries, each with
- a single, unique value in its member attribute.
-
- The key words "MUST", "SHOULD", and "MAY" used in this document
- carry the meanings described in [Bradner97].
-
-4. The Controls
-
- Support for the controls is advertised by the presence of their OID
- in the supportedControl attribute of a server's root DSE. The OID
- for the request control is "2.16.840.1.113719.1.27.101.1" and the
- OID for the response control is "2.16.840.1.113719.1.27.101.2".
-
-4.1 Request Control
-
- This control is included in the searchRequest message as part of the
- controls field of the LDAPMessage, as defined in Section 4.1.12 of
- [LDAPv3].
-
- The controlType is set to "2.16.840.1.113719.1.27.101.1". The
- criticality MAY be set to either TRUE or FALSE. The controlValue is
- an OCTET STRING, whose value is the BER encoding of the following
- type:
-
- DuplicateEntryRequest ::= AttributeDescriptionList
-
- The "AttributeDescriptionList" data type is described in 4.1.5 of
- [LDAPv3] and describes a list of 0 or more AttributeDescription
- types as also described in 4.1.5 of [LDAPv3]. Both definitions are
- repeated here for convenience:
-
- AttributeDescriptionList ::= SEQUENCE OF
- AttributeDescription
-
- AttributeDescription ::= <AttributeType> [ ";" <options> ]
-
- While processing a search request, a server implementation examines
- this list. If a specified attribute exists in an entry to be
- returned by search, one instance of that entry per attribute value
- is returned. In this case, the specified attribute in each entry
-
-
-Sermersheim Standards Track - Expires Sep 2000 Page 2
-\f
-LDAP Control for a Duplicate Entry Representation of Search Results
-
-
- holds a single, unique value from the original set of values of that
- attribute.
-
- An AttributeDescription should only occur once in the list. If an
- AttributeDescription is included in the DuplicateEntryRequest
- multiple times, the server should return an unwillingToPerform error
- in the DuplicateEntryResponse.
-
- When two or more attribute types are specified by this control, the
- number of duplicate entries is the combination of all values in each
- attribute. Because of the potential complexity involved in servicing
- multiple attribute types, server implementations MAY choose to
- support a limited number of attribute types in the control.
-
- There is a special case where either no attributes are specified, or
- an attribute description value of "*" is specified. In this case,
- all attributes are used. (The "*" allows the client to request all
- user attributes in addition to specific operational attributes).
-
-4.2 Response Control
-
- This control is included in the searchResultDone message as part of
- the controls field of the LDAPMessage, as defined in Section 4.1.12
- of [LDAPv3].
-
- The controlType is set to "2.16.840.1.113719.1.27.101.2". The
- criticality is FALSE (MAY be absent). The controlValue is an OCTET
- STRING, whose value is the BER encoding of the following SEQUENCE:
-
- DuplicateEntryResponse ::= SEQUENCE {
- result ENUMERATED {
- success (0),
- operations error (1), -- server internal failure
- timeLimitExceeded (3), -- time limit reached before
- -- attribute values could be
- -- processed
- sizeLimitExceeded (4), -- size limit reached as a
- -- result of this control
- adminLimitExceeded (11), -- result set too large for
- -- server to handle
- noSuchAttribute (16), -- unrecognized attribute
- -- description
- busy (51),
- unwillingToPerform (53),
- other (80) },
- attributeType AttributeDescription OPTIONAL }
-
- A result field is provided here to allow feedback in the case where
- the criticality of the request control is FALSE, and the server
- could not process the control - yet it could complete the search
- operation successfully. If the request control's criticality is
- TRUE, and the server cannot process the control, the resultCode of
- the LDAPResult is used to report the error.
-
-Sermersheim Standards Track - Expires Sep 2000 Page 3
-\f
-LDAP Control for a Duplicate Entry Representation of Search Results
-
-
-
- attributeType MAY be set to the value of the first attribute type
- specified by the DuplicateEntryRequest that was in error. The
- client MUST ignore the attributeType field if the result is success.
-
-5. Protocol Examples
-
-5.1 Simple example
-
- This example will show this control being used to produce a list of
- all telephone numbers in the "Acting" organizational unit of "Looney
- Tunes". Let's say the following three entries exist in this
- organization;
-
- dn: cn=Bugs Bunny,ou=Acting,o=Looney Tunes
- telephoneNumber: 555-0123
-
- dn: cn=Daffy Duck,ou=Acting,o=Looney Tunes
- telephoneNumber: 555-8854
- telephoneNumber: 555-4588
- telephoneNumber: 555-5884
-
- dn: cn=Porky Pig,ou=Acting,o=Looney Tunes
- telephoneNumber: 555-9425
- telephoneNumber: 555-7992
-
- First an LDAP search is specified with a baseDN of "ou=Acting,
- o=Looney Tunes ", subtree scope, filter set to "telephoneNumber=*".
- A DuplicateEntryRequest control is attached to the search,
- specifying "telephoneNumber" as the attribute description, and the
- search request is sent to the server.
-
- The set of search results returned by the server would then consist
- of the following entries:
-
- dn: cn=Bugs Bunny,ou=Acting,o=Looney Tunes
- telephoneNumber: 555-0123
-
- dn: cn=Daffy Duck,ou=Acting,o=Looney Tunes
- telephoneNumber: 555-8854
-
- dn: cn=Daffy Duck,ou=Acting,o=Looney Tunes
- telephoneNumber: 555-4588
-
- dn: cn=Daffy Duck,ou=Acting,o=Looney Tunes
- telephoneNumber: 555-5884
-
- dn: cn=Porky Pig,ou=Acting,o=Looney Tunes
- telephoneNumber: 555-9425
-
- dn: cn=Porky Pig,ou=Acting,o=Looney Tunes
- telephoneNumber: 555-7992
-
-
-Sermersheim Standards Track - Expires Sep 2000 Page 4
-\f
-LDAP Control for a Duplicate Entry Representation of Search Results
-
-
- Note that it is not necessary to use an attribute type in this
- control that is specified in the search filter. This example only
- does so, because the result was to obtain a list of telephone
- numbers.
-
-5.2 Specifying multiple attributes
-
- A more complicated example involving multiple attributes will result
- in more entries. If we assume these entries in the directory:
-
- dn: cn=Bugs Bunny,ou=Acting,o=Looney Tunes
- givenName: Bugs
- mail: bbunny@looneytunes.com
-
- dn: cn=Elmer Fudd,ou=Acting,o=Looney Tunes
- givenName: Elmer
- givenName: Doc
- mail: efudd@looneytunes.com
- mail: bunnyhunter@nra.org
-
- And both "mail" and "givenName" are specified as attribute types in
- this control, the resulting set of entries would be this:
-
- dn: cn=Bugs Bunny,ou=Acting,o=Looney Tunes
- givenName: Bugs
- mail: bbunny@looneytunes.com
-
- dn: cn=Elmer Fudd,ou=Acting,o=Looney Tunes
- givenName: Elmer
- mail: efudd@looneytunes.com
-
- dn: cn=Elmer Fudd,ou=Acting,o=Looney Tunes
- givenName: Elmer
- mail: bunnyhunter@nra.org
-
- dn: cn=Elmer Fudd,ou=Acting,o=Looney Tunes
- givenName: Doc
- mail: efudd@looneytunes.com
-
- dn: cn=Elmer Fudd,ou=Acting,o=Looney Tunes
- givenName: Doc
- mail: bunnyhunter@nra.org
-
-5.3 Listing the members of a groupOfNames
-
- This example shows how the controls can be used to turn a single
- groupOfNames entry into multiple duplicate entries. LetÆs say this
- is our groupOfNames entry:
-
- dn: cn=Administrators,o=acme
- cn: Administrators
- member: cn=aBaker,o=acme
- member: cn=cDavis,o=acme
-
-Sermersheim Standards Track - Expires Sep 2000 Page 5
-\f
-LDAP Control for a Duplicate Entry Representation of Search Results
-
-
- member: cn=bChilds,o=acme
- member: cn=dEvans,o=acme
-
- We could set our search base to "cn=Administrators,o=acme", filter
- to "objectClass=*", use an object scope (to restrict it to this
- entry) and send the duplicateEntryRequest control with "member" as
- its attribute value. The resulting set would look like this:
-
- dn: cn=Administrators,o=acme
- member: cn=aBaker,o=acme
-
- dn: cn=Administrators,o=acme
- member: cn=cDavis,o=acme
-
- dn: cn=Administrators,o=acme
- member: cn=bChilds,o=acme
-
- dn: cn=Administrators,o=acme
- member: cn=dEvans,o=acme
-
- This list can then be sorted by member and displayed (also by
- member) in a list.
-
-6 Relationship to other controls
-
- This control is intended (but not limited) to be used with the
- Server Side Sorting control [SSS]. By pairing this control with the
- Server Side Sorting control, One can produce a set of entries,
- sorted by attribute values, where each attribute value is
- represented in the sorted set. Server implementations should ensure
- that this control is processed before sorting the result of a
- search, as this control alters the result set of search.
-
- This control may also be used with the Virtual List View [VLV]
- control (which has a dependency on the Server Side Sort control).
- The nature of the dependency between the VLV control and the Sort
- control is such that the Sorting takes place first. Because the sort
- happens first, and because this control is processed before the sort
- control, the impact of this control on the VLV control is minimal.
- Some server implementations may need to carefully consider how to
- handle the typedown functionality of the VLV control when paired
- with this control. The details of this are heavily implementation
- dependent and are beyond the scope of this document.
-
-7. Notes for Implementers
-
- Both client and server implementations should be aware that using
- this control could potentially result in a very large set of search
- results. Servers MAY return an adminLimitExceeded result in the
- response control due to inordinate consumption of resources. This
- may be due to some a priori knowledge such as a server restriction
- of the number of attribute types in the request control that it's
-
-
-Sermersheim Standards Track - Expires Sep 2000 Page 6
-\f
-LDAP Control for a Duplicate Entry Representation of Search Results
-
-
- willing to service, or it may be due to the server attempting to
- service the control and running out of resources.
-
- Client implementations must be aware that search entries returned,
- when using this control will contain a subset of the values of any
- specified attribute.
-
-8. Acknowledgments
-
- The author gratefully thanks the input and support of participants
- of the LDAP-EXT working group.
-
-9. References
-
- [LDAPv3]
- Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access
- Protocol (v3)", Internet Standard, December, 1997.
- Available as RFC2251.
-
- [SSS]
- Wahl, M, A. Herron and T. Howes, "LDAP Control Extension for Server
- Side Sorting of Search Results", Internet Draft, March, 1998.
- Available as draft-ietf-ldapext-sorting-02.txt.
-
- [VLV]
- Boreham, D, Sermersheim, J, Anantha, A, Armijo, M, "LDAP Extensions
- for Scrolling View Browsing of Search Results", Internet Draft,
- June, 1999.
- Available as draft-ietf-ldapext-ldapv3-vlv-03.txt.
-
-
- [X.511]
- ITU-T Rec. X.511, "The Directory: Abstract Service Definition",
- 1993.
-
- [Bradner97]
- Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement
- Levels", Internet Draft, March, 1997.
- Available as RFC2119.
-
-10. Author's Address
-
- Jim Sermersheim
- Novell, Inc.
- 122 East 1700 South
- Provo, Utah 84606, USA
- jimse@novell.com
- +1 801 861-3088
-
-
-
-
-
-
-Sermersheim Standards Track - Expires Sep 2000 Page 7
+++ /dev/null
-Internet-Draft David Chadwick\r
-LDAPExt WG University of Salford \r
-Intended Category: Standards Track Sean Mullan\r
- Sun Microsystems\r
-Expires: 1 January 2001 1 July 2000\r
-\r
-\r
-Returning Matched Values with LDAPv3\r
-<draft-ietf-ldapext-matchedval-02.txt>\r
-\r
-\r
-STATUS OF THIS MEMO\r
-\r
-This document is an Internet-Draft and is in full conformance with \r
-all the provisions of Section 10 of RFC2026.\r
-\r
-Internet-Drafts are working documents of the Internet Engineering \r
-Task Force (IETF), its areas, and its working groups. Note that other\r
-groups may also distribute working documents as Internet-Drafts.\r
-\r
-Internet-Drafts are draft documents valid for a maximum of six months\r
-and may be updated, replaced, or obsoleted by other documents at any\r
-time. It is inappropriate to use Internet-Drafts as reference \r
-material or to cite them other than as "work in progress."\r
-\r
-The list of current Internet-Drafts can be accessed at\r
-http://www.ietf.org/ietf/1id-abstracts.txt.\r
-\r
-The list of Internet-Draft Shadow Directories can be accessed at\r
-http://www.ietf.org/shadow.html.\r
-\r
-This Internet-Draft expires on 1 January 2001. Comments and \r
-suggestions on this document are encouraged. Comments on this \r
-document should be sent to the LDAPExt working group discussion list:\r
- ietf-ldapext@netscape.com\r
-or directly to the authors.\r
-\r
-\r
-ABSTRACT\r
-\r
-This document describes a control for the Lightweight Directory \r
-Access Protocol v3 that is used to return a subset of attribute \r
-values from an entry, specifically, only those values that match a \r
-"values return" filter. Without support for this control, a client \r
-must retrieve all of an attribute's values and search for specific \r
-values locally.\r
-\r
-\r
-1. Introduction\r
-\r
-When reading an attribute from an entry using LDAP v2 [1] or LDAPv3 \r
-[2], it is normally only possible to read either the attribute type, \r
-or the attribute type and all its values. It is not possible to \r
-selectively read just a few of the attribute values. If an attribute \r
-holds many values, for example, the userCertificate attribute, or the \r
-subschema publishing operational attributes objectClasses and \r
-attributeTypes [3], then it may be desirable for the user to be able \r
-to selectively retrieve a subset of the values, specifically, those \r
-attribute values that match some user defined selection criteria. \r
-Without the control specified in this [ID/standard] a client must \r
-read all of the attribute's values and filter out the unwanted \r
-values, necessitating the client to implement the matching rules. It \r
-also requires the client to potentially read and process many \r
-irrelevant values, which can be inefficient if the values are large \r
-or complex, or there are many values stored per attribute.\r
-\r
-This Internet Draft specifies an LDAPv3 control to enable a user to \r
-return only those values that matched (i.e. returned TRUE to) one or \r
-more elements of a newly defined "values return" filter. This control \r
-can be especially useful when used in conjunction with extensible \r
-matching rules that match on one or more components of complex binary \r
-attribute values.\r
-\r
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", \r
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this \r
-document are to be interpreted as described in RFC 2119 [5].\r
-\r
-\r
-2. The valuesReturnFilter Control\r
-\r
-The valuesReturnFilter control MAY be critical or non-critical as \r
-determined by the user. It is only applicable to the Search \r
-operation, and SHALL be ignored by the server if it is present on any \r
-other LDAP operation (even if marked critical on such operations).\r
-\r
-The object identifier for this control is 1.2.826.0.1.3344810.2.3\r
-\r
-\r
-The controlValue is \r
-\r
- ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem\r
-\r
- SimpleFilterItem ::= CHOICE {\r
- equalityMatch [3] AttributeValueAssertion,\r
- substrings [4] SubstringFilter,\r
- greaterOrEqual [5] AttributeValueAssertion,\r
- lessOrEqual [6] AttributeValueAssertion,\r
- present [7] AttributeDescription,\r
- approxMatch [8] AttributeValueAssertion,\r
- extensibleMatch [9] SimpleMatchingAssertion }\r
-\r
- SimpleMatchingAssertion ::= SEQUENCE {\r
- matchingRule [1] MatchingRuleId OPTIONAL,\r
- type [2] AttributeDescription OPTIONAL,\r
- matchValue [3] AssertionValue}\r
-\r
-All the above data types have their standard meanings as defined in \r
-[2].\r
-\r
-If the server supports this control, the server MUST make use of the \r
-control as follows:\r
-\r
-(1) The Search Filter is first executed in order to determine \r
-which entries satisfy the Search criteria. The control has no \r
-impact on this step.\r
-\r
-(2) If the typesOnly parameter of the Search Request is TRUE, \r
-the control has no effect and the Search Request SHOULD be \r
-processed as if the control had not been specified.\r
-\r
-(3) If the attributes parameter of the Search Request consists \r
-of a list containing only the attribute with OID "1.1" \r
-(specifying that no attributes are to be returned), the control \r
-has no effect and the Search Request SHOULD be processed as if \r
-the control had not been specified.\r
-\r
-(4) For each attribute listed in the attributes parameter of the \r
-Search Request, the server MUST apply the control as follows:\r
-\r
-i) Every attribute value that evaluates TRUE against one or \r
-more elements of the ValuesReturnFilter is placed in the \r
-SearchResultEntry.\r
-ii) Every attribute value that evaluates FALSE or undefined \r
-against all elements of the ValuesReturnFilter is not \r
-placed in the SearchResultEntry. An attribute that has no \r
-values selected is returned with an empty set of vals.\r
-\r
-Editor's Note. There is possibly a more efficient but slightly more \r
-complex way of achieving the value filtering. An alternative is to \r
-remove the 'present' SimpleFilterItem (which obviously evaluates true \r
-for every attribute value of the 'present' attribute description), \r
-and to say that any attribute whose type is not mentioned in the \r
-ValuesReturnFilter is not filtered and has all its attribute values \r
-returned. Comments please.\r
-\r
-\r
-3. Relationship to X.500\r
-\r
-The control is a superset of the matchedValuesOnly boolean of the \r
-X.500 DAP [4] Search argument, as amended in the latest version [6].\r
-Close examination of the matchedValuesOnly boolean by the LDAPExt \r
-group revealed ambiguities and complexities in the MVO boolean that \r
-could not easily be resolved. For example, are only those attribute \r
-values that contributed to the overall truth of the filter governed \r
-by the MVO boolean, or all values of attributes in the filter \r
-governed by the MVO boolean, even if the filter item containing the \r
-attribute evaluated to false. For this reason the LDAP group decided \r
-to replace the MVO boolean with a simple filter that removes any \r
-uncertainty as to whether an attribute value has been selected or \r
-not. \r
-\r
-\r
-4. Examples\r
-\r
-(1) The first example simply shows how the control can be used to \r
-selectively read a subset of attribute values. \r
-\r
-The entry below represents a groupOfNames object class containing \r
-several members from different organizations.\r
-\r
-cn: Cross Organizational Standards Body\r
-member: cn=joe,o=acme\r
-member: cn=alice,o=acme\r
-member: cn=bob,o=foo\r
-member: cn=sue,o=bar\r
-\r
-An LDAP search operation is specified with a baseObject set to the\r
-DN of the entry, a baseObject scope, a filter set to \r
-"member=*o=acme", and the list of attributes to be returned set to \r
-"member". In addition, a ValuesReturnFilter control is set to \r
-"member=*o=acme".\r
-\r
-The search results returned by the server would consist of the \r
-following entry:\r
-\r
-cn: Cross Organizational Standards Body\r
-member: cn=joe, o=acme\r
-member: cn=alice, o=acme\r
-\r
-\r
-(2) The second example shows how the control can be set to match on \r
-attributes that are (mail) and are not (telephoneNumber) part of the \r
-search filter. It also shows how a user can filter some attribute \r
-values (mail) and not others (telephoneNumber).\r
-\r
-The entries below represent inetOrgPerson [7] object classes located\r
-below some distinguished name in the directory.\r
-\r
-cn: Sean Mullan\r
-mail: sean.mullan@sun.com\r
-mail: mullan@east.sun.com\r
-telephoneNumber: +1 781 442 0926\r
-telephoneNumber: 555-9999\r
-\r
-cn: David Chadwick\r
-mail: d.w.chadwick@salford.ac.uk\r
-\r
-An LDAP search operation is specified with a baseObject set to the\r
-DN of the entry, a subtree scope, a filter set to \r
-"(|(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk))", and \r
-the list of attributes to be returned set to "mail telephoneNumber". \r
-In addition, a ValuesReturnFilter control is set to \r
-"mail=sean.mullan@sun.com, mail=d.w.chadwick@salford.ac.uk, \r
-telephoneNumber=*"\r
-\r
-The search results returned by the server would consist of the \r
-following entries:\r
-\r
-cn: Sean Mullan\r
-mail: sean.mullan@sun.com\r
-telephoneNumber: +1 781 442 0926\r
-telephoneNumber: 555-9999\r
-\r
-cn: David Chadwick\r
-mail: d.w.chadwick@salford.ac.uk\r
-\r
-Note that the control has no effect on the values returned for the \r
-"telephoneNumber" attribute (all of the values are returned), since \r
-the control specified that all values should be returned.\r
-\r
-(3) The third example shows how one might retrieve a single attribute \r
-type schema definition for the "gunk" attribute with OID 1.2.3.4.5\r
-\r
-Assume the subschema subentry is held somewhere below the root entry \r
-with RDN "subschema subentry", and this holds an attributeTypes \r
-operational attribute holding the descriptions of the 35 attributes \r
-known to this server (each description is held as a single attribute \r
-value of the attributeTypes attribute). \r
-\r
-cn: subschema subentry\r
-objectClass: subschema\r
-attributeTypes: ( 2.5.4.3 NAME 'cn' SUP name )\r
-attributeTypes: ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE )\r
-attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY \r
-objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )\r
-attributeTypes: ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY \r
-generalizedTimeMatch ORDERING generalizedTimeOrderingMatch\r
-SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-\r
-MODIFICATION USAGE directoryOperation )\r
-attributeTypes: ( 2.5.21.6 NAME 'objectClasses' EQUALITY \r
-objectIdentifierFirstComponentMatch SYNTAX \r
-1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )\r
-attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch \r
-SUBSTR caseIgnoreSubstringsMatch SYNTAX \r
-1.3.6.1.4.1.1466.115.121.1.44{64} )\r
-attributeTypes: ( 2.5.21.5 NAME 'attributeTypes' EQUALITY \r
-objectIdentifierFirstComponentMatch SYNTAX \r
-1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )\r
-\r
-plus another 28 - you get the idea.\r
-\r
-\r
-The user creates an LDAP search operation with a baseObject set to \r
-root, a subtree scope, a filter set to "objectClass=subschema", the \r
-list of attributes to be returned set to "attributeTypes", and the \r
-ValuesReturnFilter set to "attributeTypes=1.2.3.4.5"\r
-\r
-The search result returned by the server would consist of the \r
-following entry:\r
-\r
-cn: subschema subentry\r
-attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch \r
-SUBSTR caseIgnoreSubstringsMatch SYNTAX \r
-1.3.6.1.4.1.1466.115.121.1.44{64} )\r
-\r
-(4) The final example shows how the control can be set to match on \r
-attributes that are not part of the search filter. For example, \r
-searching for all entries that have an email address in the\r
-sun.com domain, and returning the telephone number for any attribute\r
-values that start with "555". \r
-\r
-The entries below represent inetOrgPerson [7] object classes located\r
-below some distinguished name in the directory.\r
-\r
-cn: Sean Mullan\r
-mail: sean.mullan@sun.com\r
-mail: mullan@east.sun.com\r
-telephoneNumber: +1 781 442 0926\r
-telephoneNumber: 555-9999\r
-\r
-cn: David Chadwick\r
-mail: d.w.chadwick@salford.ac.uk\r
-\r
-An LDAP search operation is specified with a baseObject set to the\r
-DN of the entry, a subtree scope, a filter set to "mail=*sun.com", \r
-and the list of attributes to be returned set to "telephoneNumber". \r
-In addition, a ValuesReturnFilter control is set to\r
-"telephoneNumber=555*"\r
-\r
-The search results returned by the server would consist of the \r
-following entry:\r
-\r
-cn: Sean Mullan\r
-telephoneNumber: 555-9999\r
-\r
-\r
-5. Security Considerations\r
-\r
-This Internet Draft does not discuss security issues at all. \r
-\r
-Note that attribute values MUST only be returned if the access \r
-controls applied by the LDAP server allow them to be returned, and in \r
-this respect the effect of the ValuesReturnFilter control is of no \r
-consequence.\r
-\r
-Note that the ValuesReturnFilter control may have a positive effect \r
-on the deployment of public key infrastructures. Certain PKI \r
-operations, like searching for specific certificates, become more \r
-practical (when combined with X.509 certificate matching rules at the \r
-server) and more scalable, since the control avoids the downloading \r
-of potentially large numbers of irrelevant certificates which would \r
-have to be processed and filtered locally (which in some cases is \r
-very difficult to perform).\r
-\r
-\r
-6. Acknowledgements\r
-\r
-The authors would like to thank members of the LDAPExt list for their \r
-constructive comments on earlier versions of this draft, and in \r
-particular to Harald Alvestrand who first suggested having an \r
-attribute return filter and Bruce Greenblatt who first proposed a \r
-syntax for this control.\r
-\r
-7. Copyright\r
-\r
-Copyright (C) The Internet Society (date). All Rights Reserved.\r
-\r
-This document and translations of it may be copied and furnished to \r
-others, and derivative works that comment on or otherwise explain it \r
-or assist in its implementation may be prepared, copied, published \r
-and distributed, in whole or in part, without restriction of any \r
-kind, provided that the above copyright notice and this paragraph are \r
-included on all such copies and derivative works. However, this \r
-document itself may not be modified in any way, such as by removing \r
-the copyright notice or references to the Internet Society or other \r
-Internet organizations, except as needed for the purpose of \r
-developing Internet standards in which case the procedures for \r
-copyrights defined in the Internet Standards process must be \r
-followed, or as required to translate it into languages other than \r
-English.\r
-\r
-The limited permissions granted above are perpetual and will not be \r
-revoked by the Internet Society or its successors or assigns.\r
-\r
-This document and the information contained herein is provided on an \r
-"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING \r
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING \r
-BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION \r
-HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF \r
-MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
-\r
-\r
-8. References\r
-\r
-[1] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access \r
-Protocol", RFC 1777, March 1995.\r
-[2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access \r
-Protocol (v3)", Dec. 1997, RFC 2251\r
-[3] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory \r
-Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, Dec \r
-1997\r
-[4] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", \r
-1993.\r
-[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement \r
-Levels", RFC 2119, March 1997.\r
-[6] ISO/IEC 9594 / ITU-T Rec X.511 (2000) The Directory: Abstract \r
-Service Definition.\r
-[7] M. Smith. "Definition of the inetOrgPerson LDAP Object Class", \r
-Internet Draft <draft-smith-ldap-inetorgperson-03.txt>, April 1999.\r
-\r
-\r
-9. Authors Addresses\r
-\r
-David Chadwick\r
-IS Institute\r
-University of Salford\r
-Salford M5 4WT \r
-England\r
-\r
-Email: d.w.chadwick@salford.ac.uk\r
-\r
-\r
-Sean Mullan \r
-Sun Microsystems\r
-East Point Business Park\r
-Dublin 3\r
-Ireland\r
-Tel: +353 1 853 0655\r
-Email: sean.mullan@sun.com\r
-\r
-Internet-Draft Returning Matched Values with LDAPv3 1 July 2000\r
-\r
-\r
-1\r
-\r
+++ /dev/null
-
-Network Working Group M. Smith, Editor
-INTERNET-DRAFT G. Good
-Intended Category: Informational R. Weltman
-Expires: September 2000 Netscape Communications Corp.
- T. Howes
- Loudcloud, Inc.
-
- 7 March 2000
-
-
- Persistent Search: A Simple LDAP Change Notification Mechanism
- <draft-ietf-ldapext-psearch-02.txt>
-
-
-
-
-
-1. Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026. Internet-Drafts are working docu-
-ments of the Internet Engineering Task Force (IETF), its areas, and its
-working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-This draft document will be submitted to the RFC Editor as an Informa-
-tional document. Distribution of this memo is unlimited. Technical dis-
-cussion of this document will take place on the IETF LDAP Extension
-Working Group mailing list <ietf-ldapext@netscape.com>. Please send
-editorial comments directly to the editor <mcs@netscape.com>.
-
-Copyright (C) The Internet Society (1997-2000). All Rights Reserved.
-
-Please see the Copyright section near the end of this document for more
-information.
-
-
-
-
-
-Smith, et. al. Intended Category: Informational [Page 1]
-\f
-LDAP Persistent Search 7 March 2000
-
-
-2. Abstract
-
-This document defines two controls that extend the LDAPv3 [LDAP] search
-operation to provide a simple mechanism by which an LDAP client can
-receive notification of changes that occur in an LDAP server. The
-mechanism is designed to be very flexible yet easy for clients and
-servers to implement. Since the IETF is likely to pursue a different,
-more comprehensive solution in this area, this document will eventually
-be published with Informational status in order to document an existing
-practice.
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
-to be interpreted as described in RFC 2119 [KEYWORDS].
-
-
-
-3. General Approach
-
-The approach taken by the Persistent Search mechanism described in this
-document is to alter the standard LDAP search operation so that it does
-not end after the initial set of entries matching the search criteria
-are returned. Instead, LDAP servers keep the search operation going.
-This provides clients and servers participating in Persistent Search
-with an active channel through which entries that change (and additional
-information about the changes that occur) can be communicated.
-
-
-
-4. Persistent Search Control
-
-This control may be included in the Controls portion of an LDAPv3 Sear-
-chRequest message. The controlType is "2.16.840.1.113730.3.4.3".
-
- PersistentSearch ::= SEQUENCE {
- changeTypes INTEGER,
- changesOnly BOOLEAN,
- returnECs BOOLEAN
- }
-
-Upon receiving this control, a server that supports it MUST process this
-as a standard LDAPv3 search with the following exceptions:
-
-
- a) If changesOnly is TRUE, the server MUST NOT return any existing
- entries that match the search criteria. Entries are only
- returned when they are changed (added, modified, deleted, or
- subject to a modifyDN operation).
-
-
-
-Smith, et. al. Intended Category: Informational [Page 2]
-\f
-LDAP Persistent Search 7 March 2000
-
-
- b) The server MUST NOT return a SearchResult message. Instead, the
- search operation MUST be kept active until it is abandoned by
- the client or until the client unbinds.
-
-
- c) As changes are made to the server, the effected entries MUST be
- returned to the client if they match the standard search cri-
- teria and if the operation that caused the change is included in
- the changeTypes field. The changeTypes field is the logical OR
- of one or more of these values: add (1), delete (2), modify (4),
- modDN (8).
-
-
- d) If returnECs is TRUE, the server MUST return an Entry Change
- Notification control with each entry returned as the result of
- changes. This control is described in the next section.
-
-
-
-5. Entry Change Notification Control
-
-This control provides additional information about the change the caused
-a particular entry to be returned as the result of a persistent search.
-The controlType is "2.16.840.1.113730.3.4.7". If the client set the
-returnECs boolean to TRUE in the PersistentSearch control, servers MUST
-include an EntryChangeNotification control in the Controls portion of
-each SearchResultEntry that is returned due to an entry being added,
-deleted, or modified.
-
- EntryChangeNotification ::= SEQUENCE {
- changeType ENUMERATED {
- add (1),
- delete (2),
- modify (4),
- modDN (8)
- },
- previousDN LDAPDN OPTIONAL, -- modifyDN ops. only
- changeNumber INTEGER OPTIONAL -- if supported
- }
-
-changeType indicates what LDAP operation caused the entry to be
-returned.
-
-previousDN is present only for modifyDN operations and gives the DN of
-the entry before it was renamed and/or moved. Servers MUST include this
-optional field only when returning change notifications as a result of
-modifyDN operations.
-
-
-
-
-Smith, et. al. Intended Category: Informational [Page 3]
-\f
-LDAP Persistent Search 7 March 2000
-
-
-changeNumber is the change number [CHANGELOG] assigned by a server for
-the change. If a server supports an LDAP Change Log it SHOULD include
-this field.
-
-
-
-6. Intended Use
-
-Some of the scenarios that the Persistent Search mechanism described in
-this document is designed to support are described in this section.
-Other uses of the mechanism are possible as well, but please refer to
-the "Implementation Considerations" section for some issues to consider.
-
-
-6.1. Cache Consistency
-
-An LDAP client application with high performance needs may want to main-
-tain a temporary, local cache of information obtained through LDAP
-search, compare, or bind operations. To improve performance, the local
-cache is always consulted before sending a request to an LDAP server.
-The client application can use Persistent Search(es) against the change-
-log [CHANGELOG] (if one is available) or against one or more subtrees
-within the LDAP server to enable it to maintain consistency between the
-data in its local cache and the data stored in the LDAP server. A Per-
-sistent Search request where the changesOnly flag is FALSE can be used
-if it is desirable to prime the cache; otherwise changesOnly would typi-
-cally be set to TRUE in the request.
-
-Caches are used for reasons other than performance improvement as well.
-In some cases, they arise naturally out of a particular application's
-design. For example, an LDAP client designed for administration of
-information held in LDAP servers will undoubtedly generate screen
-displays that show information gleaned from an LDAP server. The screen
-display is a cache that is active and visible until the user of the
-application takes some action that causes different information to be
-displayed. A refresh button or similar control may be provided to the
-user to allow them to update the cached display. A Persistent Search
-request can be used instead by the administrative application to
-automatically refresh the screen display as soon as the underlying LDAP
-information changes.
-
-
-6.2. Synchronization
-
-Some LDAP clients such as those that execute on a portable computer may
-maintain a partial or complete offline copy of the entries stored in an
-LDAP server. While connected to the network, such a client can direct
-all queries to the copy of data it holds and use a Persistent Search to
-
-
-
-Smith, et. al. Intended Category: Informational [Page 4]
-\f
-LDAP Persistent Search 7 March 2000
-
-
-actively maintain the contents of the offline copy (alternatively, the
-client could direct requests to the LDAP server that is the source of
-the data). While disconnected from the network, the client must satisfy
-all queries using its offline copy of the data. When the client recon-
-nects to the network, it can synchronize its own copy of the data with
-the one stored on the LDAP server and proceed to actively maintain its
-offline copy by issuing a Persistent Search with the changesOnly flag
-set to FALSE against the server's changelog [CHANGELOG]. A search
-filter like "(changeNumber>=NUM)" where NUM is an integer one greater
-than the last change the client processed would be used to limit the
-entries returned to the set of changes the client has not yet seen.
-
-
-6.3. Triggered Actions
-
-An LDAP client application may want to take some action when an entry in
-the directory is changed. A Persistent Search request can be used to
-proactively monitor one or more LDAP servers for interesting changes
-that in turn cause specific actions to be taken by an application. For
-example, an electronic mail repository may want to perform a "create
-mailbox" task when a new person entry is added to an LDAP directory and
-a "delete mailbox" task when a person entry is deleted from an LDAP
-directory.
-
-
-
-7. Implementation Considerations
-
-Implementors of servers that support the mechanism described in this
-document should ensure that their implementation scales well as the
-number of active Persistent Search requests increases and as the number
-of changes made in the directory increases.
-
-Each active Persistent Search request requires that an open TCP connec-
-tion be maintained between an LDAP client and an LDAP server that might
-not otherwise be kept open. Therefore, client implementors are
-encouraged to avoid using Persistent Search for non-essential tasks and
-to close idle LDAP connections as soon as practical. Server implemen-
-tors are encouraged to support a large number of client connections if
-they need to support large numbers of Persistent Search clients.
-
-
-This specification makes no guarantees about how soon a server should
-send notification of a changed entry to a Persistent Search client.
-This is intentional as any specific maximum delay would be impossible to
-meet in a distributed directory service implementation. Server imple-
-mentors are encouraged to minimize the delay before sending notifica-
-tions to ensure that clients' needs for timeliness of change
-
-
-
-Smith, et. al. Intended Category: Informational [Page 5]
-\f
-LDAP Persistent Search 7 March 2000
-
-
-notification are met.
-
-
-
-8. Security Considerations
-
-In some situations, it may be important to prevent general exposure of
-information about changes that occur in an LDAP server. Therefore,
-servers that implement the mechanism described in this document SHOULD
-provide a means to enforce access control on the entries returned and
-MAY also provide specific access control mechanisms to control the use
-of the PersistentSearch and EntryChangeNotification controls.
-
-
-As with normal LDAP search requests, a malicious client can initiate a
-large number of Persistent Search requests in an attempt to consume all
-available server resources and deny service to legitimate clients. For
-this reason, servers that implement the mechanism described in the docu-
-ment SHOULD provide a means to limit the number of resources that can be
-consumed by a single client.
-
-
-
-9. Copyright
-
-Copyright (C) The Internet Society (1997-2000). All Rights Reserved.
-
-This document and translations of it may be copied and furnished to oth-
-ers, and derivative works that comment on or otherwise explain it or
-assist in its implementation may be prepared, copied, published and dis-
-tributed, in whole or in part, without restriction of any kind, provided
-that the above copyright notice and this paragraph are included on all
-such copies and derivative works. However, this document itself may not
-be modified in any way, such as by removing the copyright notice or
-references to the Internet Society or other Internet organizations,
-except as needed for the purpose of developing Internet standards in
-which case the procedures for copyrights defined in the Internet Stan-
-dards process must be followed, or as required to translate it into
-languages other than English.
-
-The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-This document and the information contained herein is provided on an "AS
-IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
-FORCE DISCLAIMS 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
-
-
-
-Smith, et. al. Intended Category: Informational [Page 6]
-\f
-LDAP Persistent Search 7 March 2000
-
-
-FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-10. Bibliography
-
-[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Require-
- ment Levels", RFC 2119, March 1997.
-
-[LDAP] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
-[CHANGELOG] G. Good, "Definition of an Object Class to Hold LDAP Change
- Record", INTERNET-DRAFT <draft-ietf-asid-changelog-01.txt>,
- July 1997.
-
-[PSEARCHAPI] M. Smith, "LDAP C API Extensions for Persistent Search",
- INTERNET-DRAFT <draft-ietf-ldapext-c-api-psearch-00.txt>,
- March 1998.
-
-
-
-11. Authors' Addresses
-
- Mark Smith
- Netscape Communications Corp.
- 501 E. Middlefield Rd., Mailstop MV068
- Mountain View, CA 94043
- USA
- +1 650 937-3477
- mcs@netscape.com
-
- Gordon Good
- Netscape Communications Corp.
- 501 E. Middlefield Rd., Mailstop MV068
- Mountain View, CA 94043
- USA
- +1 650 937-3825
- ggood@netscape.com
-
- Rob Weltman
- Netscape Communications Corp.
- 501 E. Middlefield Rd., Mailstop MV068
- Mountain View, CA 94043
- USA
- +1 650 937-3301
- rweltman@netscape.com
-
-
-
-
-Smith, et. al. Intended Category: Informational [Page 7]
-\f
-LDAP Persistent Search 7 March 2000
-
-
- Tim Howes
- Loudcloud, Inc.
- 615 Tasman Dr.
- Sunnyvale, CA 94089
- USA
- +1 650 321 4565
- howes@loudcloud.com
-
-
-
-12. Appendix A: Changes since draft-ietf-ldapext-psearch-01.txt
-
- "Status of this Memo" section: changed "Intended Category" to Infor-
- mational. Also updated boilerplate text to reflect current I-D
- guidelines and updated copyright to include the year "2000."
-
- "Abstract" section: added sentence that says why this will be pub-
- lished as Informational.
-
- "Entry Change Notification Control" section: added the word "only" to
- clarify that the previousDN field is only returned for modifyDN
- operations.
-
- "Authors' Addresses" section: updated Tim Howes' information.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Smith, et. al. Intended Category: Informational [Page 8]
-\f
-
-
-1. Status of this Memo............................................1
-2. Abstract.......................................................2
-3. General Approach...............................................2
-4. Persistent Search Control......................................2
-5. Entry Change Notification Control..............................3
-6. Intended Use...................................................4
-6.1. Cache Consistency...........................................4
-6.2. Synchronization.............................................4
-6.3. Triggered Actions...........................................5
-7. Implementation Considerations..................................5
-8. Security Considerations........................................6
-9. Copyright......................................................6
-10. Bibliography...................................................7
-11. Authors' Addresses.............................................7
-12. Appendix A: Changes since draft-ietf-ldapext-psearch-01.txt...8
+++ /dev/null
-IETF LDAPEXT Working Group Roland Hedberg
-Internet-Draft Catalogix
-Expires: January 12, 2000 July 12, 2000
-
-
-
-
-
- Referrals in LDAP Directories
- <draft-ietf-ldapext-refer-00.txt>
-
-
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other documents
- at any time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-
- This Internet-Draft will expire on January 12, 2000.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-
-
-
-
-
-
-
-
-
-
-
-Hedberg Expires September 30, 2000 [Page 1]
-
-Internet-Draft LDAP Knowledge references July 2000
-
-Abstract
-
- This document defines two reference attributes and associated "referral"
- object class for representing generic knowledge information in LDAP
- directories [RFC2251].
- The attribute uses URIs [RFC1738] to represent knowledge,
- enabling LDAP and non-LDAP services alike to be referenced.
- The object class can be used to construct entries in an LDAP directory
- containing references to other directories or services. This document
- also defines procedures directory servers should follow when supporting
- these schema elements and when responding to requests for which the
- directory server does not contain the requested object but may contain
- some knowledge of the location of the requested object.
-
-
-1. Background and intended usage
-
- The broadening of interest in LDAP directories beyond their use as front
- ends to X.500 directories has created a need to represent knowledge
- information in a more general way. Knowledge information is information
- about one or more servers maintained in another server, used to link
- servers and services together.
-
- This document is based on the following basic assumptions:
-
- - several naming domains
- The usage of LDAP as a access protocol to other than X.500 servers has
- created islands of directory service systems containing one or more
- LDAP servers. Each of these islands are free to pick their own naming
- domain. And that they also do; some use the old country,organization,
- organizationalUnit naming scheme[X.521], some use the newer domain name
- based naming scheme but these two are in no way the only ones in use. The
- existence of several naming domains are in itself no real problem as
- long as they produce unique names for the objects in the directory.
- Still naming schemes like the domain name based one, might easily create
- non-continues naming structures because some toplevel domain names
- might no find organizations that are interested and/or willing
- to manage them. Therefor tree transversal might not longer be possible
- except in parts of the whole tree.
-
- - authoritive structure vs directory structure
- In some instances even if a part of the tree is delegated to one
- organization, the organization doing the delegation might want to
- remain as the authority for the baseobject of the delegated tree.
-
- - support for onelevel searches
- At points in the tree where the responsibility for all or almost all
- of the children of a object is delegated to different organizations
- and resides in different directory servers a one-level search is not
- very efficient if not supported by special facilities in the directory
- as such.
-
-Hedberg Expires September 30, 2000 [Page 2]
-
-Internet-Draft LDAP Knowledge references July 2000
-
- -- directory server discovery
- LDAP servers that do not use dc nameing or are not registered with
- SRV records in the DNS are very hard to find.
-
- This document defines a general method of representing knowledge
- information in LDAP directories, based on URIs.
- Two types of knowledge reference are defined: refer and subRefer.
-
- The key words "MUST", "SHOULD", and "MAY" used in this document are to
- be interpreted as described in [RFC2119].
-
-2. Knowledge references
-
-2.1 The refer attribute
-
- ( 1.2.752.17.1.100
- NAME 'refer'
- DESC 'URL reference'
- EQUALITY caseExactIA5Match
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
- USAGE distributedOperation )
-
- The refer attribute type has IA5 syntax and is case sensitive.
- It is multivalued. Values placed in the attribute MUST conform to the
- specification given for the labeledURI attribute as defined in [RFC2079].
-
- The labeledURI specification defines a format that is a URI,
- optionally followed by whitespace and a label. This document does not
- make use of the label portion of the syntax. Future documents MAY enable
- new functionality by imposing additional structure on the label portion
- of the syntax as it appears in a refer attribute.
- If the URI contained in a refer attribute refers to an LDAP
- server, it must be in the LDAP URI format described in [RFC2255].
-
- When returning a referral result, the server must not return the label
- portion of the labeledURI as part of the referral. Only the URI portion
- of the refer attributes should be returned.
-
- The refer attribute can be further specified by the use of options as
- defined in section 4.1.5 of [RFC2251]. This document defines five
- options and their use. Future documents might defined other options.
-
- The options defined are:
- "me", "sup", "cross", "nssr" and "sub" .
-
- 'refer;me' is used to hold the reference of this server, and is always
- held in the root DSE
-
- 'refer;sup' is used to hold the reference of a server superior to this
- one in this global LDAP naming domain e.g. a server holding the dc=com,
- dc=se, or the c=se node. The 'refer;sup' is always held in the root DSE.
-
-Hedberg Expires September 30, 2000 [Page 3]
-
-Internet-Draft LDAP Knowledge references July 2000
-
- 'refer;cross' indicates that this is a cross reference pointing to another
- naming context within or outside this global LDAP naming domain.
-
- 'refer;sub' indicates that this is a subordinate reference pointing to
- a subordinate naming context in this global LDAP naming domain.
-
- 'refer;nssr' indicates that this is a non-specific subordinate reference
- pointing to a subordinate naming context in this global LDAP naming domain.
-
-
-3. Use of the knowledge attribute
-
- Except when the manageDsaIT control (documented in section 6 of this
- document) is present in the operation request, the refer attribute is not
- visible to clients, except as its value is returned in referrals or con-
- tinuation references.
-
- If the manageDsaIT control is not set, and the entry named in a request
- contains the refer attribute, and the entry is not the root DSE, the
- server returns an LDAPResult with the resultCode field set to "referral"
- and the referral field set to contain the value(s) of the refer attribute
- minus any optional trailing whitespace and labels that might be present.
-
- If the manageDsaIT control is not set, and an entry containing the ref
- attribute is in the scope of a one level or subtree search request, the
- server returns a SearchResultReference for each such entry containing
- the value(s) of the entry's refer attribute.
-
- When the manageDsaIT control is present in a request, the server will
- treat an entry containing the refer attribute as an ordinary entry, and
- the refer attribute as an ordinary attribute, and the server will not
- return referrals or continuation references corresponding to refer
- attributes.
-
-
-4 Behaviour specification
-
-4.1 Name resolution for any operation
-
- Clients SHOULD perform at least simple "depth-of-referral count" loop
- detection by incrementing a counter each time a new set of referrals is
- received. (The maximum value for this count SHOULD be twice the number
- of RDNs in the target object less one, to allow for ascending and
- descending the DIT.) Clients MAY perform more sophisticated loop
- detection, for example not chasing the same referral twice.
-
- Case 1: The target entry is not held by the server and is
- superior to some entry held by the server.
-
- If the server DSE contains a "refer;sup" attribute then
- the server will return an LDAPResult with the result code field set
-
-Hedberg Expires September 30, 2000 [Page 4]
-
-Internet-Draft LDAP Knowledge references July 2000
-
- to referral, and the referral field set to contain the value(s) of
- the "refer;sup" attribute minus any optional trailing whitespace and
- labels that might be present.
-
- Case 2: The target entry is not held by the server and is
- subordinate to some entry, held by the server, that contains a
- refer attribute.
-
- The server will return an LDAPResult with the result code field set
- to referral, and the referral field set to contain the value(s) of
- the refer attribute minus any optional trailing whitespace and labels
- that might be present.
-
- Case 3: The target entry is held by the server and contains a
- refer attribute without the 'nssr' option.
-
- The server will return an LDAPResult with the result code field set
- to referral, and the referral field set to contain the value(s) of
- the refer attribute minus any optional trailing whitespace and labels
- that might be present.
-
- Case 4: The target entry is not held by the server, and is not
- subordinate or superior to any object held by the server.
-
- If the server contains a "refer;cross" attribute
- in the root DSE with a baseobject that is either the same or
- superior to the target entry then
- the server will return an LDAPResult with the result code field set
- to referral, and the referral field set to contain the value(s) of
- these refer attributes minus any optional trailing whitespace and labels
- that might be present.
-
-
-4.2 Search evaluation
-
- For search operations, once the base object has been found and
- determined NOT to contain a refer attribute without the 'nssr'
- option, the search may progress.
-
-4.2.1 base-level
-
- If the entry matches the filter and does NOT contain a refer attribute
- it will be returned to the client as described in [RFC2251].
- If the entry matches the filter contains a refer attribute without
- the 'nssr' option it will be returned as a referral as described here.
-
- If a matching entry contains a refer attribute and the URI
- contained in the refer attribute is NOT an LDAP URI [RFC2255],
- the server should return the URI value contained in the refer
- attribute of that entry in a SearchResultReference.
-
-
-Hedberg Expires September 30, 2000 [Page 5]
-
-Internet-Draft LDAP Knowledge references July 2000
-
-
- If a matching entry contains a refer attribute in the LDAP
- URI syntax, the server will return an SearchResultReference
- containing the value(s) of the refer attribute minus any optional
- trailing whitespace and labels that might be present.
- The URL from the refer attribute must be modified before it is
- returned by adding or substituting a "base" scope into the URL. If the
- URL does not contain a scope specifier, the "base" scope specifier must
- be added. If the URL does contain a scope specifier, the existing scope
- specifier must be replaced by the "base" scope.
-
-4.2.2 One-level
-
- Any entries matching the filter and one level scope that
- do NOT contain a refer attribute are returned to the client normally as
- described in [RFC2251]. Any entries matching the filter and one level
- scope that contains a refer attribute without the 'nssr' option must
- be returned as referrals as described here.
-
- If a matching entry contains a refer attribute and the URI
- contained in the refer attribute is NOT an LDAP URI [RFC2255],
- the server should return the URI value contained in the refer
- attribute of that entry in a SearchResultReference.
-
- If a matching entry contains a refer attribute in the LDAP
- URI syntax, the server will return an SearchResultReference
- containing the value(s) of the refer attribute minus any optional
- trailing whitespace and labels that might be present.
- The URL from the refer attribute must be modified before it is
- returned by adding or substituting a "base" scope into the URL. If the
- URL does not contain a scope specifier, the "base" scope specifier must
- be added. If the URL does contain a scope specifier, the existing scope
- specifier must be replaced by the "base" scope.
-
-4.2.3 Subtree search evaluation
-
- Any entries, held by the server, matching the filter and
- subtree scope that do NOT contain a refer attribute or contains
- a refer attribute with the 'nssr' option are
- returned to the client normally as described in [RFC2251].
- Any entries matching the subtree scope and containing a refer
- attribute must be returned as referrals as described here.
-
- If a matching entry contains a refer attribute and the URI
- contained in that attribute is NOT an LDAP URI [RFC2255],
- the server should return the URI value contained in the refer
- attribute of that entry in a SearchResultReference.
-
-
-
-
-
-Hedberg Expires September 30, 2000 [Page 6]
-
-Internet-Draft LDAP Knowledge references July 2000
-
- If a matching entry contains a refer attribute in the LDAP
- URI syntax, the server will return an SearchResultReference
- containing the value(s) of the refer attribute minus any
- optional trailing whitespace and labels that might be present.
-
- N.B. in subtree search evaluation a entry containing a
- refer attribut with the 'nssr' option might appear twice in the
- result, first as a entry and then as a reference. A client
- following all references might therefore end up with a resultset
- containing two representations of the same entry, one from the
- server getting the original query and one from the server
- that the 'nssr' reference points to.
-
-
-5. The referral object class
-
- The referral object class is defined as follows.
-
- ( 1.2.752.17.2.10
- NAME 'referral'
- SUP top
- STRUCTURAL
- MAY ( refer ) )
-
- The referral object class is a subclass of top and may contain the
- refer attribute. The referral object class should, in general,
- be used in conjunction with the extensibleObject object class to support
- the naming attributes used in the entry's distinguished name.
-
- Servers must support the refer attributes through use of the
- referral object class. Any named reference must be of the referral
- object class and will likely also be of the extensibleObject object
- class to support naming and use of other attributes.
-
-
-6. The manageDsaIT control
-
- A client MAY specify the following control when issuing a search, com-
- pare, add, delete, modify, or modifyDN request.
-
- The control type is 2.16.840.1.113730.3.4.2. The control SHOULD be
- marked as critical. There is no value; the controlValue field is
- absent.
-
- This control causes entries with the knowledge reference attributes to be
- treated as normal entries, allowing clients to read and modify these entries.
-
-
-
-
-
-
-Hedberg Expires September 30, 2000 [Page 7]
-
-Internet-Draft LDAP Knowledge references July 2000
-
-
-7. Superior Reference
-
- This document defines two types of knowledge references that point to
- parts of the naming context that is above of beyone the part held by a server.
- The 'sup' option when referring to a LDAP server that holds a
- naming context that is closer to the root of the same naming context and
- 'other' when referring to a LDAP server that holds a naming
- context that belongs to a different naming domain then the one the
- server belongs to.
-
- Thus if the server receives a request for an operation where the
- target entry is a entry closer to the root than the naming
- context held the server and if the server holds a 'refer;sup' attribute
- in the DSE, then the server MUST return an LDAPResult with the result
- code field set to referral, and the referral field set to contain the
- value(s) of the 'refer;sub' attribute minus any optional trailing
- whitespace and labels that might be present.
-
- On the other hand if the server receives a request for an operation
- where the target entry is a entry that belongs to a other naming domain
- and if there is any 'refer;other' attributes in the DSE with a base entry
- that belongs to the same naming domain as the target entry and is
- closer to the root then the target entry, then the server SHOULD return
- an LDAPResult with the result code field set to referral, and the referral
- field set to contain the value(s) of the 'refer;other' attribute minus
- any optional trailing hitespace and labels that might be present.
-
-
-8. Security Considerations
-
- This document defines mechanisms that can be used to "glue" LDAP (and
- other) servers together. The information used to specify this glue
- information should be protected from unauthorized modification. If the
- server topology information itself is not public information, the
- information should be protected from unauthorized access as well.
-
-
-9. References
-
- [RFC1738]
- Berners-Lee, T., Masinter, L., and McCahill, M., "Uniform Resource
- Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of
- Minnesota, December 1994,
-
- [RFC2079]
- M. Smith, "Definition of an X.500 Attribute Type and an Object Class
- to Hold Uniform Resource Identifiers (URIs)", RFC 2079, January
- 1997.
-
-
-
-Hedberg Expires September 30, 2000 [Page 8]
-
-Internet-Draft LDAP Knowledge references July 2000
-
-
- [RFC2119]
- S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev-
- els", RFC 2119, March 1997. (Format: TXT=4723 bytes) (Also BCP0014)
- (Status: BEST CURRENT PRACTICE)
-
- [RFC2251]
- M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
- (v3)", RFC 2251, December 1997. 1997.
-
- [RFC2255]
- T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December, 1997.
- (Format: TXT=20685 bytes) (Status: PROPOSED STANDARD)
-
- [X500]
- ITU-T Rec. X.501, "The Directory: Models", 1993.
-
- [X521]
- ITU-T Rec. X.521, "---------------------", 1993.
-
-
-12. Acknowledgements
-
- This draft is heavily based on the previous drafts on knowledge
- references in LDAP written by Christopher Lukas, Tim Howes,
- Michael Roszkowski, Mark C. Smith, Mark Wahl and David Chadwick.
- Peter Valkenburg and Henny Bekker has also made valueable
- contributions.
-
-
-13. Authors Address
-
- Roland Hedberg
- Catalogix
- Dalsveien 53
- 0775 Oslo
- Norway
- EMail: Roland@catalogix.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hedberg Expires September 30, 2000 [Page 9]
-
-Internet-Draft LDAP Knowledge references July 2000
-
-
- Appendix A
-
- Example of usage.
- Information stored in a server.
-
- dn:
- objectclass: referral
- refer;me: ldap://hostCAT/dc=cat,dc=se
- refer;sup: ldap://hostSE/dc=se
- refer;cross: ldap://hostNO/dc=no
- refer;cross: ldap://hostNL/c=nl
-
- dn: dc=cat,dc=se
- objectclass: domain
- dc: cat
-
- dn: dc=one,dc=cat,dc=se
- objectclass: extendedObject
- objectclass: referral
- refer;nssr: ldap://hostCAT1/dc=one,dc=cat,dc=se
- ou: one
- l: umea
-
- dc: dc=two,dc=cat,dc=se
- objectclass: referral
- objectclass: extendedObject
- refer;sub: ldap://hostCAT2/dc=two,dc=cat,dc=se
-
- dn: dc=three,dc=cat,dc=se
- objectclass: referral
- objectclass: extendedObject
- refer;cross: ldap://hostCAT3/dc=cat,dc=nl
-
- dc: dc=four,dc=cat,dc=se
- objectclass: domain
- objectclass: extendedObject
- ou: four
- l: umea
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hedberg Expires September 30, 2000 [Page 10]
-
-Internet-Draft LDAP Knowledge references July 2000
-
-
- ==========================================
- A number of descriptive cases
- ==========================================
-
- case 1: One-level search, target object on the server
- search
- baseobject: dc=cat,dc=se
- scope: onelevel
- filter: (objectclass=*)
- attributes: ou
-
- returns
- searchResultEntry {
- dn: dc=one,dc=cat,dc=se
- ou: one
- }
- searchResultReference {
- ldapurl: ldap://hostCAT2/dc=two,dc=cat,dc=se
- }
- searchResultReference {
- ldapurl: ldap://hostCAT3/dc=cat,dc=nl
- }
- searchResultEntry {
- dn: dc=four,dc=cat,dc=se
- ou: four
- }
- searchResultDone {
- resultCode: success
- }
-
- case 2: Subtree search, target object on the server
- search
- baseobject: dc=cat,dc=se
- scope: subtree
- filter: (objectclass=*)
- attributes: ou
-
- returns
- searchResultEntry {
- dn: dc=one,dc=cat,dc=se
- ou: one
- }
- searchResultReference {
- ldapurl: ldap://hostCAT1/dc=one,dc=cat,dc=se
- }
- searchResultReference {
- ldapurl: ldap://hostCAT2/dc=two,dc=cat,dc=se
- }
-
-
-
-Hedberg Expires September 30, 2000 [Page 11]
-
-Internet-Draft LDAP Knowledge references July 2000
-
-
- searchResultReference {
- ldapurl: ldap://hostCAT3/dc=cat,dc=nl
- }
- searchResultEntry {
- dn: dc=four,dc=cat,dc=se
- ou: four
- }
- searchResultDone {
- resultCode: success
- }
-
- case 3: base search, target entry contains a 'refer;nssr' attribute
- search
- baseobject: dc=one,dc=cat,dc=se
- scope: base
- filter: (objectclass=*)
- attributes: ou
-
- returns
- searchResultEntry {
- dn: dc=one,dc=cat,dc=se
- ou: four
- }
- searchResultDone {
- resultCode: success
- }
-
- case 4: base search, target entry contains a 'refer;sub' attribute
- search
- baseobject: dc=two,dc=cat,dc=se
- scope: base
- filter: (objectclass=*)
- attributes: ou
-
- returns
- searchResultDone {
- resultCode: referral
- matchedDN: dc=two,dc=cat,dc=se
- referral: ldap://hostCAT2/dc=two,dc=cat,dc=se
- }
-
-
-
-
-
-
-
-
-
-
-
-Hedberg Expires September 30, 2000 [Page 12]
-
-Internet-Draft LDAP Knowledge references July 2000
-
-
- case 5: one-level search, target entry contains a 'refer;nssr' attribute
- search
- baseobject: dc=one,dc=cat,dc=se
- scope: onelevel
- filter: (objectclass=*)
- attributes: ou
-
- searchResultDone {
- resultCode: referral
- matchedDN: dc=one,dc=cat,dc=se
- referral: ldap://hostCAT1/dc=one,dc=cat,dc=nu
- }
-
- case 6: Search on area above the baseobject of the server
- search
- baseobject: dc=pi,dc=se
- scope: subtree
- filter: (objectclass=*)
- attributes: ou
-
- returns
- searchResultDone {
- resultCode: referral
- matchedDN: dc=se
- referral: ldap://hostSE/dc=se
- }
-
-
-
- case 7: Search on area beyond, but not below the baseobject
- of the server
- search
- baseobject: o=surfnet,c=nl
- scope: base
- filter: (objectclass=*)
-
- returns
- searchResultDone {
- resultCode: referral
- matchedDN: c=nl
- referral: ldap://hostNL/c=NL
- }
-
-
-
-
-
-
-
-
-
-Hedberg Expires September 30, 2000 [Page 13]
-
+++ /dev/null
-
-Extended Operations for Framing LDAP Operations
-Internet-Draft
-Intended Category: Standards Track
-Expires: September 10, 2000
-
-
- Ellen Stokes
- IBM Corporation
-
- Roger Harrison
- Novell, Inc.
-
- Gordon Good
- Netscape Communications Corp.
-
- March 10, 2000
-
- Extended Operations for Framing LDAP Operations
- Filename: draft-ietf-ldup-framing-00.txt
-
-Table of Contents
-
-1. Status of this Memo.............................................2
-2. Abstract........................................................2
-3. Overview........................................................2
-4. Protocol element definitions....................................3
-4.1 StartFramedProtocolRequest Extended Operation...................3
-4.2 StartFramedProtocolResponse Extended Operation..................3
-4.3 EndFramedProtocolRequest Extended Operation.....................4
-4.4 EndFramedProtocolResponse Extended Operation....................4
-5. Acknowledgments.................................................5
-6. References......................................................5
-7. Author's Addresses..............................................5
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stokes, Harrison and Good [Page 1]
-\f
-Internet-Draft LDUP Workgroup March 10, 2000
-
-
-1. Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet- Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-.
-
- This Internet Draft expires September 10, 2000.
-
-
-2. Abstract
-
- Certain types of LDAP applications can benefit from the ability to
- specify the beginning and end of a related group of operations. For
- example, the LDUP multimaster update protocol [ARCHITECTURE] requires
- that two servers agree to begin a session to transfer pending
- replication updates. This document provides a framework for
- constructing protocols that feature a framed set of related
- operations. It defines a pair of LDAPv3 extended operations that
- provide begin-end framing, and a pair of extended operations used to
- respond the begin-end framing operations. The nature of the actual
- LDAP operations carried inside these framing operations is not
- specified in this document.
-
- All protocol elements described here are LDAP Version 3 extended
- operations. LDAP Version 3 is described in RFC 2251 [LDAPv3].
-
- Certain terms used in this document are defined in the document "LDAP
- Replication Architecture" [ARCHITECTURE].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
- to be interpreted as described in RFC 2119 [KEYWORDS].
-
-3. Overview
-
- This document describes two LDAPv3 Extended Operations that are used
- to signal the beginning and end of a set of grouped operations, and
-
-
-
-Stokes, Harrison and Good [Page 2]
-\f
-Internet-Draft LDUP Workgroup March 10, 2000
-
-
- two LDAPv3 extended operations that are used to respond to these
- operations. These extended operations provide a framework that may be
- used when developing a protocol that requires begin-end framing.
-
-4. Protocol element definitions
-
-4.1 StartFramedProtocolRequest Extended Operation
-
- The StartFramedProtocolRequest extended operation indicates that the
- initiator wishes to begin transmission of a set of related LDAP
- operations. The requestValue of the StartFramedProtocolRequest
- extended operation contains an OID that describes the specific framed
- protocol being initiated, and a protocol-specific payload.
-
- An LDAPv3 Extended Request is defined in [LDAPv3] as follows:
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL
- }
-
- The requestName portion of the StartFramedProtocolRequest must be the
- OID "2.16.840.1.113719.1.142.100.1".
-
- The requestValue of the StartFramedProtocolRequest must be set to the
- BER-encoding of the following:
-
- StartFramedProtocolRequestValue ::= SEQUENCE {
- framedProtocolOID LDAPOID,
- framedProtocolPayload OPTIONAL OCTET STRING
- }
-
- The parameters in the requestValue of the StartFramedProtocolRequest
- are:
-
- - framedProtocolOID: An OID that uniquely identifies the protocol
- framed by this operation. - framedProtocolPayload: An octet
- string that contains protocol-specific
- information.
-
-
-4.2 StartFramedProtocolResponse Extended Operation
-
- The StartFramedProtocolResponse extended operation is sent in
- response to a StartFramedProtocolResponse extended operation.
-
- An LDAPv3 Extended Response is defined in [LDAPv3] as follows:
-
-
-
-
-Stokes, Harrison and Good [Page 3]
-\f
-Internet-Draft LDUP Workgroup March 10, 2000
-
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS of LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL
- }
-
- The responseName of the StartFramedProtocolResponse must be the OID
- "2.16.840.1.113719.1.142.100.2".
-
- The response of the StartFramedProtocolResponse is set to the BER-
- encoding of a protocol-specific response.
-
-4.3 EndFramedProtocolRequest Extended Operation
-
- The EndFramedProtocolRequest extended operation indicates the end a
- set of related LDAP operations. The requestValue of the
- EndFramedProtocolRequest extended operation contains a protocol-
- specific payload.
-
- An LDAPv3 Extended Request is defined in [LDAPv3] as follows:
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL
- }
-
- The requestName of the EndFramedProtocolRequest must be the OID
- "2.16.840.1.113719.1.142.100.4".
-
- The requestValue of the EndFramedProtocolRequest is set to the BER-
- encoding of a protocol-specific response.
-
-4.4 EndFramedProtocolResponse Extended Operation
-
- The EndFramedProtocolResponse extended operation is sent in response
- to an EndFramedProtocolRequest.
-
- An LDAPv3 Extended Response is defined in [LDAPv3] as follows:
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS of LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL
- }
-
- The responseName of the EndFramedProtocolResponse must be the OID
- "2.16.840.1.113719.1.142.100.5".
-
-
-
-
-Stokes, Harrison and Good [Page 4]
-\f
-Internet-Draft LDUP Workgroup March 10, 2000
-
-
- The response of the EndFramedProtocolResponse is set to the BER-
- encoding of a protocol-specific response.
-
-5. Acknowledgments
-
-The authors gratefully acknowledge the contributions of the IETF LDUP
-working group.
-
-6. References
-
-
-[KEYWORDS]
- S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev-
- els", Harvard University, RFC 2119, March 1997.
-
-
-[ARCHITECTURE]
- J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architec-
- ture", Internet-Draft, draft-ietf-ldup-model-02.txt, October 1999.
-
-
-[LDAPv3]
- M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
- (v3)", RFC 2251, December 1997.
-
-7. Author's Addresses
-
- Ellen Stokes
- IBM
- 11400 Burnet Rd
- Austin, TX 78758
- USA
- EMail: stokes@austin.ibm.com
- phone: +1 512 838 3725
- fax: +1 512 838 0156
-
- Roger Harrison
- Novell, Inc.
- 122 E. 1700 S.
- Provo, UT 84606
- USA
- EMail: roger_harrison@novell.com
- Phone: +1 801 861 2642
-
- Gordon Good
- Netscape Communications Corp.
- 501 E. Middlefield Rd.
- Mailstop MV068
-
-
-
-Stokes, Harrison and Good [Page 5]
-\f
-Internet-Draft LDUP Workgroup March 10, 2000
-
-
- Mountain View, CA 94043
- USA
- EMail: ggood@netscape.com
- Phone: +1 650 937-3825
-
-
-Appendix A - Complete ASN.1 Definition
-
-StartFramedProtocolRequest ::= ExtendedRequest
-
-StartFramedProtocolRequestValue ::= SEQUENCE {
- framedProtocolOID LDAPOID,
- framedProtocolPayload OPTIONAL OCTET STRING
-}
-
-StartFramedProtocolResponse ::= ExtendedResponse
-
-EndFramedProtocolRequest ::= ExtendedRequest
-
-EndFramedProtocolResponse ::= ExtendedResponse
-
-Full Copyright Statement
-
-Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-This document and translations of it may be copied and furnished to oth-
-ers, and derivative works that comment on or otherwise explain it or
-assist in its implementation may be prepared, copied, published and dis-
-tributed, in whole or in part, without restriction of any kind, provided
-that the above copyright notice and this paragraph are included on all
-such copies and derivative works. However, this document itself may not
-be modified in any way, such as by removing the copyright notice or
-references to the Internet Society or other Internet organizations,
-except as needed for the purpose of developing Internet standards in
-which case the procedures for copyrights defined in the Internet Stan-
-dards process must be followed, or as required to translate it into
-languages other than English.
-
-The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-This document and the information contained herein is provided on an "AS
-IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
-FORCE DISCLAIMS 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 FIT-
-NESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-Stokes, Harrison and Good [Page 6]
+++ /dev/null
-INTERNET-DRAFT
-draft-ietf-ldup-infomod-01.txt
- Ed Reed
- Reed-Matthews, Inc.
- March 9, 2000
-
- LDUP Replication Information Model
-
-
-1. Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-This Internet-Draft expires on May 11, 1999.
-
-
-2. Abstract
-
-[LDUP Model] describes the architectural approach to replication of
-LDAP directory contents. This document describes the information
-model and schema elements which support LDAP Replication Services
-which conform to [LDUP Model].
-
-Directory schema is extended to provide object classes, subentries,
-and attributes to describe areas of the namespace which are under
-common administrative authority, units of replication (ie, subtrees,
-or partitions of the namespace, which are replicated), servers which
-hold replicas of various types for the various partitions of the
-namespace, which namespaces are held on given servers, and the
-progress of various namespace management and replication operations.
-Among other things, this knowledge of where directory content is
-
-
-
-Reed [Page 1]
- Expires September 9, 2000 \f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-located will provide the basis for dynamic generation of LDAP
-referrals for clients who can follow them.
-
-The controlling framework by which the relationships, types, and
-health of replicas of the directory content will be defined so that,
-as much as possible, directory content is itself used to monitor and
-control the environment.
-
-Security information, including access control policy identifiers and
-information will be treated as directory content by the replication
-protocols when specified by the LDAPEXT group.
-
-The information model will describe required and optional house-
-keeping duties for compliant systems to implement, such as garbage
-collection of deleted objects, reconciliation of moved and renamed
-objects, update sequencing and transaction bracketing of changes, etc.
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119 [RFC2119]. The
-sections below reiterate these definitions and include some additional
-ones.
-
-
-2.1 Changes in this version
-
-LDAP Subentry definition is moved to its own document [SUBENTRY].
-
-LDAP Schedule Subentry definition is defined.
-
-LDAP Access Point removed in favor of just using the DN of the server
-holding the replica (so a new syntax isn't required).
-
-LDAP Change Sequence Number syntax eleminated in favor of just calling
-it a CaseIgnoreString, so new comparison rules aren't required.
-
-Deleted ldapSearchFilter definition from here. Sparse replicas is
-deferred. Might sparse be supported for single-master configurations
-(read-only, of course).
-
-Fractional are okay in multi-master configurations, but again, only on
-read-only replicas.
-
-Changed the naming convention upper-lower case usage to look less
-weird.
-
-Note:
-
-
-Reed [Page 2]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-Consistency discussion
-
-Schema document must clearly indicate that clients can and should
-inspect the replica subentries to understand the single-master/multi-
-master nature of the naming context to which they're talking.
-
-The paradigm change, to distributed data, needs to be exhaustively
-discussed in the profile documents. How old applications which assume
-single-master behave or misbehave in a multi-master environment is
-critical to make clear. Draw examples from SMP pre-emptive
-programming practices, from DNS vs host file models, etc.
-
-
-
-Decisions from wash ietf_
-
-1) define two simple schema classes _ event driven histeresis
- buckets, and cron-like thing. Then, the replica has a single
- value pointer to a schedule. More schedule things can be
- defined in the future.
-
-2) Create attribute ReplicaURI to provide service access point for
- that replica. No DSA entry requirement.
-
-3) Replica id table discussion should move to protocol spec.
-
-To do:
-1) define the cron schedule subentry class
-2) define the rest of the attributes used in the classes
-3) verify LDUP OID number with Novell (!) one more time
-4) verify all OIDs assigned
-5) verify all OIDs documented at the end of the document
-6) scrub editorial comments
-7) cross reference with arch document on schema element names
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Reed [Page 3]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-Table of Contents
-1. Status of this Memo .............................................1
-2. Abstract 1
-2.1 Changes in this version........................................2
-3. Introduction ....................................................4
-3.1 Scope 4
-3.2 Terms and Definitions..........................................5
-4. Data design: ....................................................5
-5. Directory Knowledge .............................................5
-6. Schema 6
-6.1 Data Structure Definitions.....................................6
-6.1.1 ldapChangeSequenceNumber..................................6
-6.2 Attribute Definitions..........................................7
-6.2.1 attributeExclusionFilter..................................7
-6.2.2 attributeInclusionFilter..................................8
-6.2.3 replicaURI................................................8
-6.2.4 replicationStatus.........................................9
-6.2.5 replicaType...............................................9
-6.2.6 SecsToWait Attributes....................................11
-6.2.6.1 secsToWaitCat1 ........................................11
-6.2.6.2 secsToWaitCat2 ........................................11
-6.2.6.3 secsToWaitCat3 ........................................11
-6.2.6.4 secsToWaitCat4 ........................................11
-6.2.6.5 secsToWaitCat5 ........................................11
-6.2.7 updateVector.............................................12
-6.3 Class Definitions.............................................12
-6.3.1 nameContext..............................................12
-6.3.2 replicaSubentry..........................................12
-6.3.3 replicaAgreementSubentry.................................13
-6.3.4 eventScheduledSubentry Class.............................14
-6.3.5 timeScheduledSubentry Class..............................15
-7. Object Identifier Assignments ..................................15
-8. Security Considerations ........................................16
-9. References .....................................................16
-10. Copyright Notice ...............................................17
-11. Acknowledgements ...............................................17
-12. Author's Address ...............................................18
-
-
-3. Introduction
-
-
-3.1 Scope
-
-This document describes schema of subentries representing replicas,
-replication agreements and their dependencies.
-
-
-
-Reed [Page 4]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-Management and status schema elements may be defined if there is
-sufficient consensus.
-
-Semantic interpretation of schema elements, including any special
-handling expectations are to be provided here.
-
-
-3.2 Terms and Definitions
-
-Definitions are provided in [LDUP Requirements], and may be reproduced
-here for the convenience of the reader.
-
-
-
-4. Data design:
-
-As described in [LDUP Model], knowledge of replicated portions of the
-directory information tree (DIT) is stored in the directory itself.
-
-An auxiliary class is defined to designate containers, or nodes, in
-the DIT which are the root-most, or base, of naming contexts
-[RFC2251]. Directory subentries [X501] are used to hold information
-about replicas and replica agreements.
-
-
-
-5. Directory Knowledge
-
-Information about what replicas exist, what they contain, their types,
-where they are stored, and how they may be contacted inevitably
-provides the basis for distributed directory knowledge. As namespaces
-from stand-alone servers are inter-connected with one another, this
-replica information can and will be used by name resolution operations
-to locate servers holding copies of specific objects, and to optimize
-distributed searches which span multiple Naming Contexts.
-
-However, the focus of this document is NOT to fully enable such
-distributed directory uses. Instead, we are focused on how portions
-of the namespace (Directory Information Tree - DIT) may be replicated,
-and how those replicas are configured and related to one another via
-Replication Agreements.
-
-As such, the following high level description (from [LDUP Model])of
-the information model envisioned is provided as reference for the
-reader before presenting the detailed specifications.
-
-Generally, the DSE Naming Context attribute of an LDAPv3 server names
-the Naming Contexts for which there are replicas on that server.
-
-Reed [Page 5]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-The Naming Context Auxiliary Class (nameContext) is added to container
-objects which may have separately defined replication policy.
-
-Immediately subordinate to a Naming Context object are the Replica
-Subentry containers which identify where the identified replica
-resides (ie, its LDAP Access Point), its type (Primary, Updateable,
-ReadOnly), if it is sparse, the LDAP search filter which defines what
-object classes it holds, and if it is fractional, the attributes it
-does or does not hold.
-
-Immediately subordinate in the namespace to a Replica Subentry are
-Replication Agreement leaf entries which each identify another
-Replica, the scheduling policy for replication operations (including
-times when replication is to be performed, when it is not to be
-performed, or the policies governing event-driven replication
-initiation).
-
-
-
-6. Schema
-
-
-6.1 Data Structure Definitions
-
-For the purposes of defining the encoding rules for attribute
-structures, the BNF definitions in section 4.1 of [RFC2252] will be
-used. They are based on the BNF styles of [RFC822].
-
-To avoid requiring new syntax support to be added unnecessarily to
-existing LDAPv3 directory service implementations (and the
-accompanying matching rules, etc. they would entail), a string
-encoding is defined for ldapChangeSequenceNumber which can use
-CaseIgnoreString matching rules for ordering and equality.
-
-6.1.1 ldapChangeSequenceNumber
-
-( 1.3.6.1.4.1.1466.115.121.1.TBD DESC 'LDAP Change Sequence Number' )
-
-Values in this syntax are encoded according to the following BNF.
-Note there MUST NOT be any whitespace separators, unless they are in
-replicaID, which must be encoded according to the instructions below.
-
-This encoding is specified so that the CaseIgnoreString equality and
-ordering rules will work correctly when replicaNumber is used.
-
-When replicaID is used, CaseIgnoreString comparison rules will not
-work unless each replicaID is exactly the same length with no padded
-
-
-Reed [Page 6]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-white spaces (because CaseIgnoreString suppresses duplicate adjacent
-white space when it compares two strings).
-
-LDAPChangeSequenceNumber = GeneralizedZTime "#" S1 "#" replicaID
- "#" S2
-GeneralizedZTime = yyyy | mm | dd | hh | mi | ss | "Z"
-yyyy = dddd <four digit year, e.g. 1998>
-mm = dd <two digit month of the year, e.g. 06>
-dd = dd <two digit day of month, e.g. 17>
-hh = dd <two digit hour of the day, inclusive range (00..23)>
-mi = dd <two digit minute of the hour, inclusive range (00..59)>
-ss = dd <two digit seconds of the minute, inclusive range (00..59)>
-replicaID = dstring
-S1, S2 = numericstring
-
-The GeneralizedTime is used as described (cf. [X680] section 39.3 case
-b) without separators or whitespace, and representing a coordinated
-universal time (i.e., Greenwich Mean Time, or GMT). All times
-referenced by this syntax MUST be normalized to GMT - no local times,
-nor time zone offsets are permitted. To simplify comparisons of two
-CSNs, the "Z" MUST be the UTF-8 capital-Z character.
-
-The ReplicaID represents the specific Replica of this Naming Context
-where the event associated with this LDAPChangeSequenceNumber
-occurred. Note that in actual transfer, the ReplicaID MAY be
-represented by a number (see the specification of the
-replicaLookupTable, above).
-
-S1 and S2 are sequence numbers which are used to order two events with
-the same Generalized Time and ReplicaID. In order to use string
-matching rules for equality and ordering with values with this
-encoding, the length of each field must be consistent. Thus, all
-instances of S1 MUST be represented with the same number of digits,
-using leading zeros as necessary. The same with S2 and replicaID.
-
-
-
-
-6.2 Attribute Definitions
-
-
-6.2.1 attributeExclusionFilter
-
-( 2.16.840.1.113719.142.4.1 NAME 'attributeExclusionFilter'
- SYNTAX OCTET STRING
- SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
-
-
-
-Reed [Page 7]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-The attributeExclusionFilter is intended to contain a list of
-attributes in the form of an AttributeDescriptionList as described in
-section 4.5.1. Search Request of [RFC2251] with the following
-interpretation: an empty attributeExclusionFilter means that no
-attributes are excluded; the special values "*" and "1.1" mean that
-ALL attributes are excluded.
-
-A non-empty attributeExclusionFilter attribute on a replica subEntry
-describes the attributes NOT PRESENT on entries held by that replica.
-Replicas MUST NOT accept changes for attributes they're not permitted
-to hold, per the attributeInclusionFilter and attributeExclusionFilter
-attributes on their replica subEntry.
-
-A non-empty attributeExclusionFilter attribute on a
-replicationAgreement subEntry describes which additional attributes
-are to be excluded from the updates to be sent from the supplier
-replica to the consumer replica.
-
-
-6.2.2 attributeInclusionFilter
-
-( {2.16.840.1.113719.142.4.2 NAME 'attributeInclusionFilter'
- SYNTAX OCTET STRING
- SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
-
-The attributeInclusionFilter is intended to contain a list of
-attributes in the form of an AttributeDescriptionList as described in
-section 4.5.1. Search Request of [RFC2251] with the following
-interpretation: an empty attributeInclusionFilter means that all
-attributes are included; the special value "*" means that ALL
-attributes are included; the special value "1.1" is meaningless and is
-ignored in this usage.
-
-A non-empty attributeInclusionFilter attribute on a replica subEntry
-describes the attributes that may be PRESENT on entries held by that
-replica. Replicas MUST NOT accept changes for attributes they're not
-permitted to hold, per the attributeIncludionFilter and
-attributeExclusionFilter attributes on their replica subEntry.
-
-
-6.2.3 replicaURI
-
-(2.16.840.1.113719.142.4.x NAME `replicaURI'
- DESC `how to connect to this replica'
- SYNTAX ldapURI
- USAGE dSAOperation )
-
-
-
-Reed [Page 8]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-6.2.4 replicationStatus
-
-(2.16.840.1.113719.142.4.3 NAME 'replicationStatus'
- DESC 'human readable status of last replication attempt'
- SYNTAX DirectoryString
- SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
-
-
-The replicationStatus attribute MAY be used to hold a human readable
-message describing the most recent replication session attempt for a
-replicationAgreement.
-
-For example, such a messages might include
-
-1) 19980805162203Z # Success #
-
-2) 19980805162322Z # Failure # Server too busy, try again
-
-3) 19980805170215Z # Failure # Unable to connect to DSA
-
-4) 19980806002301Z # Failure # Authentication failed
-
-5) 19980806003201Z # Failure # lost connection, reset by peer
-
-It is suggested, but not required, that the time of a replication
-attempt (completion, if successful or failure, if not), the result of
-the attempt, and any additional information about a failure be
-included in the string message.
-
-It is suggested, but not required, that the messages be stored with
-language tags (English, French, German, Japanese, Chinese, per [LANG
-TAG]) particularly if multiple translations of the error messages are
-available to the DSA implementers.
-
-Note that this is a single-valued attribute. Sequences of status
-entries SHOULD be written to log files or other persistent storage, or
-in multi-valued replication history attributes, but are not specified
-here.
-
-
-6.2.5 replicaType
-
-(2.16.840.1.113719.142.4.4 NAME 'replicaType'
- DESC 'Enum: 0-reserved, 1-Primary, 2-Updateable, 3-ReadOnly, all
-others reserved'
- EQUALITY integerMatch
- SYNTAX INTEGER
- SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
-
-Reed [Page 9]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-ReplicaType is a simple enumeration, used to identify what kind of
-replica is being described in a Replica object entry.
-
-A ReadOnly replica only accepts LDAP Search operations (to Read
-entries, list containers, and search for entries). Because no updates
-ever originate from ReadOnly replicas, they never have changes to send
-to another replica. However, a ReadOnly replica may be designated a
-supplier DSA in a replica agreement, if it is simply passing along
-information it receives from other Updateable replicas about entries
-and their changes.
-
-ReadOnly replicas may be incomplete replicas.
-
-An Updateable replica may accept both LDAP Search operations (to read,
-list, or search entries), as well as modification operations (to add,
-modify, or delete entries).
-
-The consequences of having incomplete updateable replicas are not
-fully understood. LDAP DSAs MAY require updateable replicas to be
-complete replicas.
-
-A Primary replica is an Updateable replica, but it is "more special"
-than other Updateable replicas. When LDAP application want to direct
-their operations to a single replica, so that the application can be
-sure that all application LDAP modification (add, delete, modify)
-operations will be immediately visible to application readers, the
-Primary replica is a good choice. Such a use would be consistent with
-High Confidence DAP option [X518]. One such application might be a
-management application which creates new naming contexts or joins two
-naming contexts into a single naming context. Another application
-might be one which creates new replicas, or replication agreements.
-
-There SHOULD be only one Primary replica defined for a naming context
-at any time. If applications, expecting there to be a Primary replica
-discover, by search or inspection of ReplicaType attributes of the
-defined Replicas of a naming context, find more than one _ they should
-realize that something is wrong.
-
-There MAY be NO primary replica defined for a naming context.
-
-Primary replicas MAY NOT be incomplete replicas.
-
-The way in which replicas change their type, as from ReadOnly to
-Updateable, or Updateable to Primary is outside the scope of this
-document.
-
-Section 5.1 "Replica Type" of [LDUP MODEL] details the permissible
-combinations of replica types and sparse/fractional replicas.
-
-Reed [Page 10]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-6.2.6 SecsToWait Attributes
-
-The secsToWait attributes document the number of seconds a replica is
-to wait after the occurrence of a "category n" change event before
-initiating a new replication session for replicationAgreements
-governed by an eventScheduledSubentry. The definition of a "category
-n" change event is implementation dependent, and may be defined
-differently by different directory servers. The absence of a value
-for any of these attributes MUST be interpreted as meaning "do not
-initiate a replication session for change events of this category".
-
-
-6.2.6.1 secsToWaitCat1
-
-( 2.16.840.1.113719.142.4.5.1 NAME 'secsToWaitCat1'
- SYNTAX INTEGER
- USAGE dSAOperation )
-
-
-6.2.6.2 secsToWaitCat2
-
-( 2.16.840.1.113719.142.4.5.2 NAME 'secsToWaitCat2'
- SYNTAX INTEGER
- USAGE dSAOperation )
-
-
-6.2.6.3 secsToWaitCat3
-
-( 2.16.840.1.113719.142.4.5.3 NAME 'secsToWaitCat3'
- SYNTAX INTEGER
- USAGE dSAOperation )
-
-
-6.2.6.4 secsToWaitCat4
-
-( 2.16.840.1.113719.142.4.5.4 NAME 'secsToWaitCat4'
- SYNTAX INTEGER
- USAGE dSAOperation )
-
-
-6.2.6.5 secsToWaitCat5
-
-( 2.16.840.1.113719.142.4.5.5 NAME 'secsToWaitCat5'
- SYNTAX INTEGER
- USAGE dSAOperation )
-
-
-
-
-Reed [Page 11]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-6.2.7 updateVector
-
-( 2.16.840.1.113719.142.4.6 NAME 'updateVector'
- SYNTAX ldapChangeSequenceNumberSyntax
- NO-USER-MODIFICATION USAGE dSAOperation )
-
-The attribute updateVector is a multi-valued attribute which contains
-information for a replica describing the latest changes received by
-the replica from other replicas.
-
-There may be only one ldapChangeSequenceNumber entry from each replica
-in the updateVector. That is to say, there is a unique value
-constraint on the ReplicaID component of entries in the list.
-
-
-6.3 Class Definitions
-
-
-6.3.1 nameContext
-
-( 2.16.840.1.113719.142.6.2.1 NAME 'nameContext' SUP top AUXILIARY )
-
-
-The nameContext auxiliary class, when present on an object, indicates
-the beginning, or root, of a naming context. The naming context is
-said to be rooted at the entry with the nameContext auxiliary class in
-its list of object classes. The root-most entry of a naming context
-is the entry with the nameContext auxiliary class in its list of
-object classes.
-
-Characteristics of the replication topology of a naming context are
-defined in the replicaSubentry sub-entries associated with the naming
-context.
-
-The attribute accessControlPolicyOID has been removed from here, and
-should be published as an ldapSubEntry subordinate to the nameContext,
-instead.
-
-The attribute nameContextCreationTimestamp used here in previous
-drafts has been eliminated as redundant. The ldapChangeSequenceNumber
-associated with the nameContext value in the list of objectClasses
-attribute serves the same purpose.
-
-
-6.3.2 replicaSubentry
-
-( 2.16.840.1.113719.142.6.3.1 NAME 'replicaSubentry' SUP ldapSubEntry
- STRUCTURAL
-
-Reed [Page 12]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
- MUST (cn, replicaURI, replicaType)
- MAY (attributeExclusionFilter, attributeInclusionFilter,
-description, updateVector) )
-
-Entries of type replicaSubentry MAY be named by their cn attribute.
-
-The attributes attributeExclusionFilter and attributeInclusionFilter,
-if present, govern which entries and attributes from the local naming
-context are to be sent (or not sent) to the replica named in replicaDN
-of replica agreements for this replica. The attributeExclusionFilter
-names attributes which SHOULD NOT be sent. The
-attributeInclusionFilter names attributes which SHOULD be sent.
-
-The attribute replicaURI contains information in ldapURI format that
-can be used to contact (ie, open a connection to) this replica.
-
-The attribute description contains a human-readable description of the
-sub-entry.
-
-The attribute updateVector contains a set of
-ldapChangeSequenceNumbers, one for each of the other replicas for this
-naming context, which records, from this replicas perspective, the
-last change event received from the other indicated replica.
-
-
-6.3.3 replicaAgreementSubentry
-
-( 2.16.840.1.113719.142.6.4.1 NAME 'replicaAgreementSubentry'
- SUP ldapSubEntry STRUCTURAL
- MUST ( cn )
- MAY ( attributeExclusionFilter, description, replicaDN,
-replicationMechanismOID, replicationStatus, scheduleDN ) )
-
-Entries of type replicaAgreementSubentry MAY be named by their cn
-attribute.
-
-The attributes attributeExclusionFilter, and ldapSearchFilter, if
-present, govern which entries and attributes from the local naming
-context are to be sent (or not sent) to the replica named in
-replicaDN. The attributeExclusionFilter names attributes SHOULD NOT be
-sent. Note there is no attributeInclusionFilter, because the list of
-attributes that may be sent may not be extended beyond those
-documented in the attributeInclusionFilter on the replicaSubentry.
-
-Processing of allowable changes to be sent is as follows:
-
-1) the attributeInclusionFilter from the replica subentry defines a
- set of attributes which SHOULD be sent, less exclusions;
-
-Reed [Page 13]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-2) the union of attributes excluded by the attributeExclusionFilter
- from the replicasubentry and the attributeExclusionFilter from the
- replicaAgreementSubentry defines a set of attributes which SHOULD
- NOT be sent;
-
-3) the subtraction of attributes which SHOULD NOT be sent by (2) from
- the attributes which SHOULD be sent by (1) constitute the set of
- attributes for which changes MAY be sent.
-
-The attribute description contains a human-readable description of the
-sub-entry.
-
-The attribute replicaDN of syntax DN names another sub-entry of type
-replicaSubentry to whom changes are to be sent. If there is no value
-for the replicaDN attribute on a replicaAgreementSubentry, the
-replicaAgreementSubentry is ignored. Absence of a value may occur
-briefly when replicas and replica agreements are first being created,
-or when the replica to which a replica agreement applies is being
-deleted.
-
-The attribute replicationStatus MAY be used to record the most recent
-result of an attempt to send changes to the replica named in
-replicaDN, whether success, or if failure, the nature of the problem
-encountered.
-
-The attribute schedule, if present, names one or more entries of type
-scheduleSubentry which govern the schedule for replication attempts.
-If not present, replication MUST be attempted when there are changes
-to be sent.
-
-
-6.3.4 eventScheduledSubentry Class
-
-( 2.16.840.1.113719.142.6.1.1 NAME 'eventScheduledSubentry'
- SUP ldapSubEntry STRUCTURAL
- MUST ( cn )
- MAY ( description, secsToWaitCat1, secsToWaitCat2, secsToWaitCat3,
-secsToWaitCat4, secsToWaitCat5 ) )
-
-Note that replication agreements using eventScheduledSubentry policy
-are, by definition, supplier-initiated.
-
-The description attribute may be used by the administrator to document
-or comment on this subentry.
-
-The secsToWaitCat1 attribute documents the number of seconds a replica
-is to wait after the occurrence of a "category 1" change event before
-initiating a new replication session for replicationAgreements
-
-Reed [Page 14]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-governed by this eventScheduledSubentry. The definition of a
-"category 1" change event is implementation dependent, and may be
-defined differently by different directory servers. The absence of a
-value for this attribute MUST be interpreted as meaning "do not
-initiate a replication session for change events of this category".
-
-The secsToWaitCat2 _ secsToWaitCat5 attributes are similarly defined
-for their respective categoriess of change events.
-
-6.3.5 timeScheduledSubentry Class
-
-( 2.16.840.1.113719.142.6.5.1 NAME 'timeScheduledSubentry'
- SUP ldapSubEntry STRUCTURAL
- MUST ( cn )
- MAY ( description ) )
-
-
-
-
-7. Object Identifier Assignments
-
-The LDUP OID prefix is
-
-ID ::= OBJECT IDENTIFIER
-
-ldup ID ::= { joint-iso-ccitt(2) country(16) us(840)
- organization(1) novell(113719) ldup(142) }
-
-The OID assignments defined in this document are:
-
-Attributes:
-attributeExclusionFilter ID ::= 2.16.840.1.113719.142.4.1
-attributeInclusionFilter ID ::= 2.16.840.1.113719.142.4.2
-replicationStatus ID ::= 2.16.840.1.113719.142.4.3
-replicaType ID ::= 2.16.840.1.113719.142.4.4
-secsToWaitClass1 ID ::= 2.16.840.1.113719.142.4.5.1
-secsToWaitClass2 ID ::= 2.16.840.1.113719.142.4.5.2
-secsToWaitClass3 ID ::= 2.16.840.1.113719.142.4.5.3
-secsToWaitClass4 ID ::= 2.16.840.1.113719.142.4.5.4
-secsToWaitClass5 ID ::= 2.16.840.1.113719.142.4.5.5
-updateVector ID ::= 2.16.840.1.113719.142.4.6
-
-Object Classes:
-eventScheduledSubentry ID ::= 2.16.840.1.113719.142.6.1.1
-nameContext ID ::= 2.16.840.1.113719.142.6.2.1
-replicaSubentry ID ::= 2.16.840.1.113719.142.6.3.1
-replicaAgreementSubentry ID ::= 2.16.840.1.113719.142.6.4.1
-timeScheduledSubentry ID ::= 2.16.840.1.113719.142.6.5.1
-
-Reed [Page 15]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-
-Note: Object Class OIDs have version numbers, Attribute OIDs don't.
-
-
-8. Security Considerations
-
-Many of the attributes and object classes described in this document
-should be considered _security sensitive_, and protected from
-unintended modification by LDAP servers. Generally, creating Naming
-Contexts, Replicas and Replica Agreement entries should only be
-allowed by directory administrators who are authorized to do so.
-
-The values of attributes defined here are intended to control the
-behavior of the directory service agents, themselves. Unintended
-modification of their values may result in incomplete replication of
-data (if ldapSearchFilter or attributeExclusionFilter are changed),
-inappropriate disclosure of information (if attributeInclusionFilter
-is changed), or updates may be lost (if updateVector is changed).
-
-To avoid depending to much on the ldapAccessPoint values for other
-replicas, connections between LDAP servers for the purpose of
-replication MUST ALWAYS be authenticated using an authentication
-mechanism appropriate for the nature of information to be exchanged.
-
-
-
-9. References
-
-[LANG TAG] _ M. Wahl, T. Howes, _Use of Language Codes in LDAP_,
-Internet draft, draft-ietf-ldapext-lang-01.txt
-
-[LDUP Model] - J. Merrells, E. Reed, U. Srinivisan, _An Abstract Model
-of LDAP Replication_, Internet draft, draft-merrells-ldup-model-01.txt
-
-[LDUP Requirements] - R. Weiser, E. Stokes _LDAP Replication
-Requirements_, Internet draft, draft-weiser-replica-req-02.txt, April
-1998
-
-[RFC2251] _ M. Wahl, T. Howes, S. Kille, _Lightweight Directory Access
-Protocol (v3)_, December 1997, RFC 2251
-
-[RFC2252] _ M. Wahl, A. Coulbeck, T. Howes, S. Kille, _Lightweight
-Directory Access Protocol (v3): Attribute Syntax Definitions_,
-December 1997, RFC 2252
-
-[X525] - ITU-T Recommendation X.525 (1997) | ISO/IEC 9594-9:1997,
-Information Technology _ Open Systems Interconnection _ The Directory:
-Replication
-
-Reed [Page 16]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-[X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995,
-Information technology _ Abstract Syntax Notation One (ASN.1):
-Specification of Basic Notation
-
-
-
-10. Copyright Notice
-
-Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it
-or assist in its implmentation may be prepared, copied, published and
-distributed, in whole or in part, without restriction of any kind,
-provided that the above copyright notice and this paragraph are
-included on all such copies and derivative works. However, this
-document itself may not be modified in any way, such as by removing
-the copyright notice or references to the Internet Society or other
-Internet organizations, except as needed for the purpose of developing
-Internet standards in which case the procedures for copyrights defined
-in the Internet Standards process must be followed, or as required to
-translate it into languages other than English.
-
-The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-This document and the information contained herein is provided on an
-"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS 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."
-
-
-11. Acknowledgements
-
-The use of subEntry object class to store Replica and Replication
-Agreement information is due primarily to the lucid explanation by
-Mark Wahl, Innosoft, of how they could be used and extended.
-
-The IETF takes no position regarding the validity or scope of any
-intellectual property 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; neither does it represent that it has made any
-effort to identify any such rights. Information on the IETF's
-procedures with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11. Copies of claims of
-
-Reed [Page 17]
- Expires September 9, 2000
-\f
-
-
-INTERNET-DRAFT 9 March 2000
- LDUP Replication Information Model
-
-rights made available for publication 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 implementors or users of this specification can be obtained from
-the IETF Secretariat.
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary
-rights which may cover technology that may be required to practice
-this standard. Please address the information to the IETF Executive
-Director.
-
-
-
-12. Author's Address
-
- Edwards E. Reed
- Reed-Matthews, Inc.
- 1064 East 140 North
- Lindon, UT 84042
- USA
- E-mail: eer@oncalldba.com
-
- LDUP Mailing List: ietf-ldup@idc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Reed [Page 18]
- Expires September 9, 2000
-\f
+++ /dev/null
-INTERNET-DRAFT
-
-draft-ietf-ldup-model-03.txt
-
-
- John Merrells
- Netscape Communications Corp.
- Ed Reed
- Reed-Matthews, Inc.
- Uppili Srinivasan
- Oracle, Inc.
- March 10, 2000
-
- LDAP Replication Architecture
-
-Copyright (C) The Internet Society (1998,1999, 2000).
-All Rights Reserved.
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or made obsolete by other documents at
-any time. It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-This draft, file name draft-ietf-ldup-model-03.txt, is intended to be
-become a Proposed Standard RFC, to be published by the IETF Working
-Group LDUP. Distribution of this document is unlimited. Comments
-should be sent to the LDUP Replication mailing list <ldup@imc.org> or
-to the authors.
-
-This Internet-Draft expires on 10 September 2000.
-
-
-
-
-
-
-
-Merrells, Reed, Srinivasan [Page 1]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-
-
-
-
-
-
-1 Abstract
-
-This architectural document outlines a suite of schema and protocol
-extensions to LDAPv3 that enables the robust, reliable, server-to-
-server exchange of directory content and changes.
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119 [RFC2119]. The
-sections below reiterate these definitions and include some additional
-ones.
-
-
-2 Table of Contents
-
-1 Abstract......................................................2
-2 Table of Contents.............................................2
-3 Introduction..................................................4
-3.1 Scope.........................................................4
-3.2 Document Objectives...........................................5
-3.3 Document Non-Objectives.......................................6
-3.4 Existing Implementations......................................6
-3.4.1 Replication Log Implementations.........................6
-3.4.2 State-Based Implementations.............................7
-3.5 Terms and Definitions.........................................7
-3.6 Consistency Models............................................8
-3.7 LDAP Constraints..............................................9
-4 Directory Model..............................................10
-4.1 Replica Type.................................................10
-4.1.1 Primary Replica........................................10
-4.1.2 Updatable Replica......................................10
-4.1.3 Read-Only Replica......................................10
-4.1.4 Fractional Replicas....................................10
-4.2 Sub-Entries..................................................11
-4.3 Glue Entries.................................................11
-4.4 Unique Identifiers...........................................11
-4.5 Change Sequence Number.......................................11
-4.5.1 CSN Composition........................................11
-4.5.2 CSN Representation.....................................12
-4.5.3 CSN Generation.........................................12
-4.6 State Change Information.....................................13
-4.1.1 Entry Change State Storage and Representation..........13
-4.1.2 Attribute Change State Storage.........................14
-
-Merrells, Reed, Srinivasan [Page 2]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-4.1.3 Attribute Value Change State Storage...................14
-4.2 LDAP Update Operations.......................................14
-5 Information Model............................................15
-5.1 Entries,
- Semantics and Relationships............................15
-5.2 Root DSE Attributes..........................................15
-5.3 Naming Context...............................................15
-5.4 Replica Object Class and Entries.............................16
-5.5 Lost and Found Entry.........................................16
-5.6 Replication Agreement Object Class and Entries...............16
-5.6.1 Replication Schedule...................................17
-6 Policy Information...........................................18
-6.1 Schema Knowledge.............................................18
-7 LDUP Update Transfer Protocol Framework......................18
-7.1 Replication Session Initiation...............................19
-7.1.1 Authentication.........................................19
-7.1.2 Consumer Initiated.....................................19
-7.1.3 Supplier Initiated.....................................19
-7.2 Start Replication Session....................................20
-7.2.1 Start Replication Request..............................20
-7.2.2 Start Replication Response.............................20
-7.3 Update Transfer..............................................20
-7.4 End Replication Session......................................20
-7.5 Integrity & Confidentiality..................................21
-8 LDUP Update Protocols........................................21
-8.1 Replication Updates and Update Primitives....................21
-8.2 Fractional Updates...........................................21
-9 LDUP Full Update Transfer Protocol...........................22
-9.1 Full Update Transfer.........................................22
-9.2 Replication Update Generation................................22
-9.3 Replication Update Consumption...............................22
-9.4 Full Update, End Replication Session.........................22
-9.5 Interrupted Transmission.....................................23
-10 LDUP Incremental Update Transfer Protocol....................23
-10.1 Update Vector................................................23
-10.2 Supplier Initiated, Incremental Update,
- Start Replication Session................................24
-10.3 Replication Update Generation................................24
-10.3.1 Replication Log Implementation.......................25
-10.3.2 State-Based Implementation...........................25
-10.4 Replication Update Consumption...............................25
-10.5 Update Resolution Procedures.................................25
-10.5.1 URP: Distinguished Names.............................26
-10.5.2 URP: Orphaned Entries................................26
-10.5.3 URP: Distinguished Not Present.......................26
-10.5.4 URP: Schema - Single Valued Attributes...............26
-10.5.5 URP: Schema - Required Attributes....................27
-10.5.6 URP: Schema - Extra Attributes.......................27
-
-
-Merrells, Reed, Srinivasan [Page 3]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-10.5.7 URP: Duplicate Attribute Values......................27
-10.5.8 URP: Ancestry Graph Cycle............................27
-10.6 Incremental Update, End Replication Session..................27
-10.7 Interrupted Transmission.....................................28
-11 Purging State Information....................................28
-11.1 Purge Vector.................................................28
-11.2 Purging Deleted Entries, Attributes, and Attribute Values....29
-12 Replication Configuration and Management.....................29
-13 Time.........................................................30
-14 Security Considerations......................................31
-15 Acknowledgements.............................................31
-16 References...................................................32
-17 Intellectual Property Notice.................................32
-18 Copyright Notice.............................................33
-19 Authors' Address.............................................33
-20 Appendix A - LDAP Constraints................................34
-20.1 LDAP Constraints Clauses.....................................34
-20.2 LDAP Data Model Constraints..................................35
-20.3 LDAP Operation Behaviour Constraints.........................36
-20.4 New LDAP Constraints.........................................37
-20.4.1 New LDAP Data Model Constraints......................37
-20.4.2 New LDAP Operation Behaviour Constraints.............37
-
-
-
-
-
-
-3 Introduction
-
-
-3.1 Scope
-
-This architectural document provides an outline of an LDAP based
-replication scheme. Further detailed design documents will draw
-guidance from here.
-
-The design proceeds from prior work in the industry, including
-concepts from the ITU-T Recommendation X.525 (1993, 1997) Directory
-Information Shadowing Protocol (DISP) [X525], experience with widely
-deployed distributed directories in network operating systems,
-electronic mail address books, and other database technologies. The
-emphasis of the design is on:
-
-1. Simplicity of operation.
-
-2. Flexibility of configuration.
-
-3. Manageability of replica operations among mixed heterogeneous
- vendor LDAP servers under common administration.
-
-
-Merrells, Reed, Srinivasan [Page 4]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-4. Security of content and configuration information when LDAP servers
- from more than one administrative authority are interconnected.
-
-A range of deployment scenarios are supported, including multi-master
-and single-master topologies. Replication networks may include
-transitive and redundant relationships between LDAP servers.
-
-The controlling framework used to define the relationships, types, and
-state of replicas of the directory content is defined. In this way the
-directory content can itself be used to monitor and control the
-replication network. The directory schema is extended to define object
-classes, auxiliary classes, and attributes that describe areas of the
-namespace which are replicated, LDAP servers which hold replicas of
-various types for the various partitions of the namespace, LDAP Access
-Points (network addresses) where such LDAP servers may be contacted,
-which namespaces are held on given LDAP servers, and the progress of
-replication operations. Among other things, this knowledge of where
-directory content is located could serve as the basis for dynamic
-generation of LDAP referrals.
-
-An update transfer protocol, which actually brings a replica up to
-date with respect to changes in directory content at another replica,
-is defined using LDAPv3 protocol extensions. The representation of
-directory content and changes will be defined by the LDAP Replication
-Update Transfer Protocol sub-team. Incremental and full update
-transfer mechanisms are described. Replication protocols are required
-to include initial population, change updates, and removal of
-directory content.
-
-Security information, including access control policy will be treated
-as directory content by the replication protocols. Confidentiality
-and integrity of replication information is required to be provided by
-lower-level transport/session protocols such as IPSEC and/or TLS.
-
-
-
-3.2 Document Objectives
-
-The objectives of this document are:
-
-a) To define the architectural foundations for LDAP Replication, so
- that further detailed design documents may be written. For
- instance, the Information Model, Update Transfer Protocol, and
- Update Resolution Procedures documents.
-
-b) To provide an architectural solution for each clause of the
- requirements document [LDUP Requirements].
-
-c) To preserve the LDAP Data Model and Operation Behavior
-constraints
- defined for LDAP in RFC 2251 [See Appendix A]
-
-d) To avoid tying the LDUP working group to the schedule of any other
- working group.
-
-e) Not to infringe upon known registered intellectual property rights.
-
-
-Merrells, Reed, Srinivasan [Page 5]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-
-
-
-3.3 Document Non-Objectives
-
-This document does not address the following issues, as they are
-considered beyond the scope of the Working Group.
-
-a) How LDAP becomes a distributed directory. There are many issues
- beyond replication that should be considered. Such as, support for
- external references, algorithms for computing referrals from the
- distributed directory knowledge, etc.
-
-b) Specifying management protocols to create naming contexts or new
- replicas. LDAP may be sufficient for this. The document describes
- how new replicas and naming contexts are represented, in the
- directory, as entries, attributes, and attribute values.
-
-c) How transactions will be replicated. However, the architecture
- should not knowingly prevent or impede them, given the Working
- Group's incomplete understanding of the issues at this time.
-
-d) The mapping or merging of disparate Schema definitions.
-
-e) Support of overlapping replicated regions.
-
-f) The case where separate attributes of an entry may be mastered by
- different LDAP servers. This might be termed a 'Split Primary'.
- Replica roles are defined in section 4.1.
-
-g) The specification of a replication system that supports Sparse
- Replication. A Sparse Replica contains a subset of the naming
- context entries, being modified by an Entry Selection Filter
- criteria associated with the replica. An Entry Selection Filter is
- an LDAP filter expression that describes the entries to be
- replicated. The design and implementation of this functionality is
- not yet well enough understood to specify here.
-
-
-
-3.4 Existing Implementations
-
-In order to define a standard replication scheme that may be readily
-implemented we must consider the architectures of current LDAP server
-implementations. Existing systems currently support proprietary
-replication schemes based on one of two general approaches: log-based
-or state-based. Some sections of this text may specifically address
-the concerns of one approach. They will be clearly marked.
-
-
-
-3.4.1R
- eplication Log Implementations
-
-Implementations based on the original University of Michigan LDAP
-server code record LDAP operations to a operation log. During a
-replication session operations are replayed from this log to bring the
-
-Merrells, Reed, Srinivasan [Page 6]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-Consumer replica up to date. Example implementations of this type at
-this time are the Innosoft, Netscape, and Open LDAP Directory Servers.
-
-
-
-3.4.2S
- tate-Based Implementations
-
-Directory Server implementations from Novell and Microsoft at this
-time do not replay LDAP operations from a operation log. When a
-replication session occurs each entry in the Replicated Area is
-considered in turn, compared against the update state of the Consumer,
-and any resultant changes transmitted. These changes are a set of
-assertions about the presence or absence of entries, attributes, and
-their values.
-
-
-
-3.5 Terms and Definitions
-
-The definitions from the Replication Requirements document have been
-copied here and extended.
-
-For brevity, an LDAP server implementation is referred to throughout
-as 'the server'.
-
-The LDAP update operations; Add, Delete, Modify, Modify RDN (LDAPv2)
-and Modify DN (LDAPv3), are collectively referred to as LDAP Update
-Operations.
-
-A Naming Context is a subtree of entries in the Directory Information
-Tree (DIT). There may be multiple Naming Contexts stored on a single
-server. Naming Contexts are defined in section 17 of [X501].
-
-A Naming Context is based at an entry identified as its root and
-includes all its subordinate entries down the tree until another
-Naming Context is encountered.
-
-A Replica is an instance of a replicated Naming Context.
-
-A replicated Naming Context is said to be single-mastered if there is
-only one Replica where it may be updated, and multi-mastered if there
-is more than one Replica where it may be updated.
-
-A Replication Relationship is established between two or more Replicas
-that are hosted on servers that cooperate to service a common area of
-the DIT.
-
-A Replication Agreement is defined between two parties of a
-Replication Relationship. The properties of the agreement codify the
-Unit of Replication, the Update Transfer Protocol to be used, and the
-Replication Schedule of a Replication Session.
-
-A Replication Session is an LDAP session between the two servers
-identified by a replication agreement. Interactions occur between the
-two servers, resulting in the transfer of updates from the supplier
-replica to the consumer replica.
-
-Merrells, Reed, Srinivasan [Page 7]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-
-The Initiator of a Replication Session is the initiating server.
-
-A Responder server responds to the replication initiation request from
-the Initiator server.
-
-A Supplier server is the source of the updates to be transferred.
-
-A Consumer server is the recipient of the update sequence.
-
-The Update Transfer Protocol is the means by which the Replication
-Session proceeds. It defines the protocol for exchanging updates
-between the Replication Relationship partners.
-
-A Replication Update is an LDAP Extended Operation that contains
-updates to be applied to the DIT. The Update Transfer Protocol carries
-a sequence of these messages from the Supplier to the Consumer.
-
-The Update Resolution Procedures repair constraint violations that
-occur when updates to a multi-mastered Replica collide.
-
-A Fractional Entry Specification is a list of entry attributes to be
-included, or a list of attributes to be excluded in a replica. An
-empty specification implies that all entry attributes are included.
-
-A Fractional Entry is an entry that contains only a subset of its
-original attributes. It results from the replication of changes
-governed by a Fractional Entry
-Specification.
-
-A Fractional Replica is a replica that holds Fractional Entries of its
-naming context.
-
-
-
-3.6 Consistency Models
-
-This replication architecture supports a loose consistency model
-between replicas of a naming context. It does not attempt to provide
-the appearance of a single copy of a replica. The contents of each
-replica may be different, but over time they will be converging
-towards the same state. This architecture is not intended to support
-LDAP Clients that require a tight consistency model, where the state
-of all replicas is always equivalent.
-
-Three levels of consistency are available to LDAP Clients, which are
-characterized by their deployment topologies. Single-Server, where
-there is just the naming context and no replicas. Single-master, where
-there are replicas, but only one may be updated. And, multi-master,
-where there is more than one replica to which LDAP update operations
-may be directed. The consistency properties of each model are rooted
-in their serialization of read and write operations.
-
-1) A single-server deployment of a naming context provides tight
-consistency to LDAP applications. LDAP Clients have no choice but to
-direct all their operations to a single server, serializing both read
-
-
-Merrells, Reed, Srinivasan [Page 8]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-and write operations.
-
-2) A single-mastered deployment of a naming context provides both
-tight and loose consistency to LDAP applications. LDAP Clients must
-direct all write operations to the single updateable replica, but may
-direct their reads to any of the replicas. A client experiences tight
-consistency by directing all its operations to the single updatable
-replica, and loose consistency by directing any read operations to any
-other replica.
-
-3) A multi-mastered deployment of a naming context can provide only
-loose consistency to LDAP applications. Across the system writes and
-reads are not serialized. An LDAP Client could direct their read and
-write operations to a single updateable replica, but they will not
-receive tight consistency as interleaved writes could be occurring at
-another replica.
-
-Tight consistency can be achieved in a multi-master deployment for a
-particular LDAP application if and only if all instances of its client
-are directed towards the same updateable replica, and the application
-data is not updated by any other LDAP application. Introducing these
-constraints to an application and deployment of a naming-context
-ensures that writes are serialized providing tight consistency for the
-application.
-
-Future work could make use of the architecture proposed in this
-document as a basis for allowing clients to request session guarantees
-from a server when establishing a connection.
-
-
-
-3.7 LDAP Constraints
-
-The LDAP-v3 Internet RFC [LDAPv3] defines a set of Data Model and
-Operation Behaviour constraints that a compliant LDAP server must
-enforce. The server must reject an LDAP Update Operation if its
-application to the target entry would violate any one of these LDAP
-Constraints. [Appendix A B contains the original text clauses from RFC
-2251, and also a summary.]
-
-In the case of a single-server or single-mastered naming context all
-LDAP Constraints are immediately enforced at the single updateable
-replica. An error result code is returned to an LDAP Client that
-presents an operation that would violate the constraints.
-
-In the case of a multi-mastered naming context not all LDAP
-Constraints can be immediately enforced at the updateable replica to
-which the LDAP Update Operation is applied. This loosely consistent
-replication architecture ensures that at each replica all constraints
-are imposed, but as updates are replicated constraint violations may
-arise
-that can not be reported to the appropriate client. Any constraint
-violations that occur are repaired by a set of update resolution
-procedures.
-
-Any LDAP client that has been implemented to expect immediate
-
-
-Merrells, Reed, Srinivasan [Page 9]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-enforcement of all LDAP Constraints may not behave as expected
-against a multi-mastered naming context.
-
-
-
-4 Directory Model
-
-
-This section describes extensions to the LDAP Directory Model that are
-required by this replication architecture.
-
-
-
-4.1 Replica Type
-
-Each Replica is characterized with a replica type. This may be
-Primary, Updatable, or Read-Only. A Read-Only Replica may be further
-defined as being Fractional.
-
-
-
-4.1.1
- Primary Replica
-
-The Primary Replica is a full copy of the Replica, to which all
-applications that require tight consistency should direct their LDAP
-Operations. There can be only one Primary Replica within the set of
-Replicas of a given Naming Context. It is also permissible for none
-of the Replicas to be designated the Primary. The Primary Replica MUST
-NOT be a Fractional Replica.
-
-
-4.1.2
- Updatable Replica
-
-An Updatable Replica is a Replica that accepts all the LDAP Update
-Operations, but is not the Primary Replica. There could be none, one,
-or many Updatable Replicas within the set of Replicas of a given
-Naming Context. An Updatable Replica MUST NOT be a Fractional Replica.
-
-
-
-4.1.3
- Read-Only Replica
-
-A Read-Only Replica will accept only non-modifying LDAP operations.
-All modification operations shall be referred to an updateable
-Replica. The server referred to would usually be a Supplier of this
-Replica.
-
-
-
-4.1.4
- Fractional Replicas
-
-Fractional Replicas must always be Read-Only. All LDAP Update
-Operations must be referred to an Updatable Replica. The server
-referred to would usually be a Supplier of this Fractional Replica.
-
-
-Merrells, Reed, Srinivasan [Page 10]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-4.2 Sub-Entries
-
-Replication management entries are to be stored at the base of the
-replicated naming context. They will be of a 'ldapSubentry'
-objectclass
-to exclude them from regular searches. Entries with the objectclass
-subentry are not returned as the result of a search unless the filter
-component "(objectclass=ldapSubentry)" is included in the search
-filter.
-
-
-
-4.3 Glue Entries
-
-A glue entry is an entry that contains knowledge of its name only. No
-other information is held with it. Such glue entries will be
-distinguished through a special object class defined for that purpose.
-Glue entries may be created during a replication session to repair a
-constraint violation.
-
-
-4.4 Unique Identifiers
-
-Distinguished names can change, so are therefore unreliable as
-identifiers. A Unique Identifier must therefore be assigned to each
-entry as it is created. This identifier will be stored as an
-operational attribute of the entry, named 'entryUUID'. The entryUUID
-attribute is single valued. A consistent algorithm for generating such
-unique identifiers should be defined for use in the LDUP standards
-documents that detail the LDUP information model and LDUP protocols.
-
-
-4.5 Change Sequence Number
-
-Change Sequence Numbers (CSNs) are used to impose a total ordering
-upon the causal sequence of updates applied to all the replicas of a
-naming context. Every LDAP Update Operation is assigned at least one
-CSN. A Modify operation MUST be assigned one CSN per modification.
-
-
-
-4.5.1
- CSN Composition
-
-A CSN is formed of four components. In order of significance they
-are; the time, a change count, a Replica Identifier, and a
-modification number. The CSN is composed thus to ensure the uniqueness
-of every generated CSN. When CSNs are compared to determine their
-ordering they are compared component by component. First the time,
-then the change count, then the replica identifier, and finally the
-modification number.
-
-The time component is a year-2000-safe representation of the real
-world time, with a granularity of one second.
-
-Because many LDAP Update Operations, at a single replica, may be
-
-Merrells, Reed, Srinivasan [Page 11]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-applied to the same data in a single second, the change count
-component of the CSN is provided to further order the changes. Each
-replica maintains a count of LDAP update operations applied against
-it. It is reset to zero at the start of each second, and is
-monotonically increasing within that second, incremented for each and
-every update operation. Should LDAP Update Operations occur at
-different replicas, to the same data, within the same single second,
-and happen to be assigned the same change count number, then the
-Replica Identifier is used to further order the changes.
-
-The Replica Identifier is the value of the RDN attribute on the
-Replica Subentry. The Replica Identifier could be assigned
-programmatically or administratively, in either case short values are
-advised to minimise resource usage. The IA5CaseIgnoreString syntax is
-used to compare and order Replica Identifier values.
-
-The fourth and final CSN component, the modification number, is used
-for ordering the modifications within an LDAP Modify operation.
-
-
-
-4.5.2
- CSN Representation
-
-The preferred CSN representation is:
- yyyy mm dd hh:mi:ssz # 0xSSSS # replica id # 0xssss
-
-The 'z' in the time stipulates that the time is expressed in GMT
-without any daylight savings time offsets permitted, and the 0xssss
-represents the hexadecimal representation of an unsigned
-integer.
-Implementations must support 16 bit change counts and should support
-longer ones (32, 64, or 128 bits).
-
-An example CSN would be " 1998081018:44:31z#0x000F#1#0x0000 ". The
-update assigned this CSN would have been applied at time
-1998081018:44:31z happened to be the 16th operation which was applied
-in that second, was made against the replica with identifier '1', and
-was the first modification of the operation that caused the change.
-
-
-
-4.5.3
- CSN Generation
-
-Because Change Sequence Numbers are primarily based on timestamps,
-clock differences between servers can cause unexpected change
-ordering. The synchronization of server clocks is not required, though
-it is preferable that clocks are accurate. If timestamps are not
-accurate, and a server consistently produces timestamps which are
-significantly older than those of other servers, its updates will not
-have effect and the real world time ordering of updates will not be
-maintained.
-
-However, an implementation may choose to require clock
-synchronisation. The Network Time Protocol [NTP] [SNTP] offers a
-protocol means by which heterogeneous server hosts may be time
-synchronised.
-
-Merrells, Reed, Srinivasan [Page 12]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-
-The modifications which made up an LDAP Modify operation are presented
-in a sequence. This must be preserved when the resultant changes of
-this operation are replicated.
-
-
-
-
-4.5.3.1 CSN Generation - Log Based Implementation
-
-
-The modification number component may not be required, since the
-ordering of the modifications within an LDAP Modify operation have
-been preserved in the operation log.
-
-
-4.5.3.2 CSN Generation - State Based Implementation
-
-
-The modification number component may be needed to ensure that the
-order of the modifications within an LDAP Modify operation are
-faithfully replicated.
-
-
-4.6 State Change Information
-
-State changes can be introduced via either LDAP Update Operations or
-via Replication Updates. A CSN is included with all changes made to an
-entry, its attributes, and attribute values. This state information
-must be recorded for the entry to enable a total ordering of updates.
-The CSN recorded is the CSN assigned to the state change at the server
-where the state change was first made. CSNs are only assigned to state
-changes that originate from LDAP Update Operations.
-
-Each of the LDAP Update Operations change their target entry in
-different ways, and record the CSN of the change differently. The
-state information for the resultant state changes are recorded at
-three levels. The entry level, attribute level, and attribute value
-level. The state change may be shown through.
-
-1) The creation of a deletion CSN for the entry, an attribute, or an
- attribute value.
-
-2) In the addition of a new entry, attribute or attribute value, and
- its existence CSN.
-
-3) An update to an existing attribute, attribute value, entry
- distinguished name, or entry superior name, and its update CSN.
-
-
-
-4.1.1
- Entry Change State Storage and Representation
-
-When an entry is created, with the LDAP Add operation, the CSN of the
-change is added to the entry as the value of an operational attribute
-
-
-Merrells, Reed, Srinivasan [Page 13]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-named 'createdEntryCSN', of syntax type LDAPChangeSequenceNumber.
-
- createdEntryCSN ::= csn
-
-Deleted entries are marked as deleted by the addition of the object
-class 'deletedEntry'. The attribute 'deletedEntryCSN', of syntax type
-LDAP Change Sequence Number, is added to record where and when the
-entry was deleted. Deleted entries are not visible to LDAP clients -
-they may not be read, they don't appear in lists or search results,
-and they may not be changed once deleted. Names of deleted entries
-are available for reuse by new entries immediately after the deleted
-entry is so marked. It may be desirable to allow deleted entries to be
-accessed and manipulated by management and data recovery applications,
-but that is outside the scope of this document.
-
- deletedEntryCSN ::= csn
-
-A CSN is recorded for both the RDN, and the Superior DN of the entry.
-
-
-4.1.2A
- ttribute Change State Storage
-
-When all values of an attribute have been deleted, the attribute is
-marked as deleted and the CSN of the deletion is recorded. The deleted
-state and CSN are stored by the server, but have no representation on
-the entry, and may not be the subject of a search operation. This
-state information must be stored to enable the Update Resolution
-Procedures to be performed.
-
-
-
-4.1.3
- Attribute Value Change State Storage
-
-The Modification CSN for each value is to be set by the server when it
-accepts a modification request to the value, or when a new value with
-a later Modification CSN is received via Replication. The modified
-value and the Modification CSN changes are required to be atomic, so
-that the value and its Modification CSN cannot be out of synch on a
-given server. The state information is stored by the server, but it
-has no representation on the entry, and may not be the subject of a
-search operation.
-
-When the value of an attribute is deleted the state of its deletion
-must be recorded, with the CSN of the modifying change. It must be
-stored to enable the Update Resolution Procedures to be performed.
-
-
-
-4.2 LDAP Update Operations
-
-The server must reject LDAP client update operations with a CSN that
-is older than the state information that would be replaced if the
-operation were performed. This could occur in a replication topology
-where the difference between the clocks of updateable replicas was too
-large. Result code 72, serverClocksOutOfSync, is returned to the
-client.
-
-Merrells, Reed, Srinivasan [Page 14]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-5 Information Model
-
-
-This section describes the object classes of the entries that
-represent the replication topology. The operational information for
-replication are administered through these entries. The LDUP Working
-Group will work towards defining an Internet standard to fully detail
-all these schema elements.
-
-
-5.1 Entries, Semantics and Relationships
-
-This section defines the organization of operational data for directory
-replication in terms of the relative placement of the entries that
-represent Naming Contexts, its Replicas, and their associated
-Replication agreements. This section also describes the purpose of
-these objects and abstractly describes their content.
-A Naming Context defines an area of DIT with independent replication
-policies. There are many mechanisms available to identify the set of
-Naming Contexts in a Directory, including through special auxiliary
-classes or through operational attributes in root DSE pointing to
-such entries. The LDUP information model standards will detail an
-appropriate mechanism.
-
-Entries representing the set of Replicas associated with a Naming
-Context are created immediately below (children) the Naming Context
-entries. Replica entries are defined as subentries and are
-intended to hold attributes that identify the Replica's LDAP Access
-Point, its Replica Type, and if it is a Fractional Replica, the
-attributes it does or does not hold. The attribute value of the entry's
-Relative Distinguished Name (RDN) is termed the Replica Identifier and
-is used as a component of each CSN associated with the replica.
-
-Immediately subordinate to each Replica Subentry are the entries
-representing the Replication Agreements between this replica and
-another replica on some other server in the network. A Replication
-Agreement entry is associated with exactly one remote replica.
-These entries are defined to hold attributes identifying
-the remote Replica associated with this agreement, the scheduling
-policy for replication operations, including times when replication is
-to be performed, when it is not to be performed, or the policies
-governing event-driven replication initiation another Replica, the
-scheduling policy for replication operations, including times when
-replication is to be performed, when it is not to be performed, or the
-policies governing event-driven replication initiation.
-
-
-
-5.2 Root DSE Attributes
-
-LDUP information model will define Root DSE attributes to identify the
-set of naming Contexts and replicas present in an LDAP server.
-
-5.3 Naming Context
-
-The LDUP Information Model will implement schema elements for
-
-Merrells, Reed, Srinivasan [Page 15]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-representing configuration and policy information common for all
-replicas of the Naming Context. Attributes for recording the location
-and time of creation of naming contexts may also be identified by the
-information model.
-
-In future LDAP Access Control standards would define mechanisms for
-identifying the ACL policy associated with a Naming Context as well as
-the syntax and semantics of its representation.
-
-
-5.4 Replica Object Class and Entries
-
-Each Replica is characterized by a replica type. This may be Primary,
-Updatable, or Read-Only. The latter two types may be further defined
-as being Fractional. The Replica entry will include a Fractional Entry
-Specification for a Fractional Replica.
-
-There is a need to represent network addresses of servers holding
-replicas participating in Replication Agreements. For this,
-the LDUP information model will define an attribute with an
-appropriate syntax to represent an LDAP server addresses with which to
-contact replicas.
-
-
-An Update Vector describes the point to which the Replica has been
-updated, in respect to all the other Replicas of the Naming Context.
-The vector is used at the initiation of a replication session to
-determine the sequence of updates that should be transferred.
-
-Enabling LDAP to be a fully distributed service is not an objective
-for the design of LDUP information model, though the information stored
-in replica entries could facilitate certain distributed operations.
-
-
-5.5 Lost and Found Entry
-
-When replicating operations between servers, conflicts may arise that
-cause a parent entry to be removed causing its child entries to become
-orphaned. In this case the Update Resolution Procedures will make the
-Lost and Found Entry the child's new superior.
-
-Each Replica Entry names it's Lost and Found Entry, which would
-usually be an entry below the Replica Entry itself. This well known
-place allows administrators, and their tools, to find and repair
-abandoned entries.
-
-
-
-5.6 Replication Agreement Object Class and Entries
-
-The Replication Agreement defines:
-
-1. The schedule for Replication Sessions initiation.
-
-2. The server that initiates the Replication Session, either the
- Consumer or the Supplier.
-
-Merrells, Reed, Srinivasan [Page 16]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-
-3. The authentication credentials that will be presented between
- servers.
-
-4. The network/transport security scheme that will be employed in
- order to ensure data confidentiality.
-
-5. The replication protocols and relevant protocol parameters to be
- used for Full and Incremental updates. An OID is used to identify
- the update transfer protocol, thus allowing for future extensions
- or bilaterally agreed upon alternatives.
-
-6. If the Replica is Fractional, the Fractional Entry Specification for
-the attributes to be included or excluded
-
-Permission to participate in replication sessions will be controlled,
-at least in part, by the presence and content of replica agreements.
-
-The Supplier must be subject to the access control policy enforced by
-the Consumer. Since the access control policy information is stored
-and replicated as directory content, the access control imposed on the
-Supplier by the Consumer must be stored in the Consumer's Replication
-Agreement.
-
-
-
-5.6.1
- Replication Schedule
-
-There are two broad mechanisms for initiating replication sessions:
-(1) scheduled event driven and (2) change event driven. The mechanism
-used to schedule replication operations between two servers is
-determined by the Schedule information that is part of the Replication
-Agreement governing the Replicas on those two servers. Because each
-Replication Agreement describes the policy for one direction of the
-relationship, it is possible that events propagate via scheduled
-events in one direction, and by change events in the other.
-
-Change event driven replication sessions are, by their nature,
-initiated by suppliers of change information. The server, which the
-change is made against, schedules a replication session in response to
-the change itself, so that notification of the change is passed on to
-other Replicas.
-
-Scheduled event driven replication sessions can be initiated by either
-consumers or suppliers of change information. The schedule defines a
-calendar of time periods during which Replication Sessions should be
-initiated.
-
-Schedule information may include both scheduled and change event
-driven mechanisms. For instance, one such policy may be to begin
-replication within 15 seconds of any change event, or every 30 minutes
-if no change events are received.
-
-
-
-
-
-Merrells, Reed, Srinivasan [Page 17]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-6 Policy Information
-
-
-Administrative policy information governs the behavior of the server
-This policy information needs to be consistently known and
-applied by all replicas of a Naming Context. It may be
-represented in the DIT as sub-entries, attributes, and attribute
-values. Auxiliary classes are a convenient way to hold such
-policy information and to uniformly replicate them among all its
-replicas. For a naming context to be faithfully reproduced, all
-applicable prescriptive policy information represented among its
-ancestral entries must also be replicated. In all cases such
-policy information is transmitted as if it were an element of
-the Replica root entry.
-
-Policy information is always replicated in the same manner as any
-other entries, attributes, and attribute values.
-
-
-
-6.1 Schema Knowledge
-
-Schema subentries should be subordinate to the naming contexts to
-which they apply. Given our model, a single server may hold replicas
-of several naming contexts. It is therefore essential that schema
-should not be considered to be a server-wide policy, but rather to be
-scoped by the namespace to which it applies.
-
-Schema modifications replicate in the same manner as other directory
-data. Given the strict ordering of replication events, schema
-modifications will naturally be replicated prior to entry creations
-which use them, and subsequent to data deletions which eliminate
-references to schema elements to be deleted. Servers MUST NOT
-replicate information about entries which are not defined in the
-schema. Servers should not replicate modifications to existing schema
-definitions for which there are existing entries and/or attributes
-which rely on the schema element.
-
-Should a schema change cause an entry to be in violation of the new
-schema, it is recommended that the server preserve the entry for
-administrative repair. The server could add a known object class to
-make the entry valid and to mark the entry for maintenance.
-
-
-
-7 LDUP Update Transfer Protocol Framework
-
-
-A Replication Session occurs between a Supplier server and Consumer
-server over an LDAP connection. This section describes the process by
-which a Replication Session is initiated, started and stopped.
-
-The session initiator, termed the Initiator, could be either the
-Supplier or Consumer. The Initiator sends an LDAP extended operation
-to the Responder identifying the replication agreement being acted on.
-The Supplier then sends a sequence of updates to the Consumer.
-
-Merrells, Reed, Srinivasan [Page 18]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-
-All transfers are in one direction only. A two way exchange requires
-two replication sessions; one session in each direction.
-
-
-7.1 Replication Session Initiation
-
-The Initiator starts the Replication Session by opening an LDAP
-connection to its Responder. The Initiator binds using the
-authentication credentials provided in the Replication Agreement.
-The LDUP Update Transfer Protocol will define the LDAP extended
-operation the Initiator should perform to initialize an LDUP session.
-For the sake of convenience, this extended LDAP operation for
-initializing a replication session is referred to as the "Start
-Replication" operation. Among other things, this operation will
-identify the role each
-server will perform, and what type of replication is to be performed.
-
-One server is to be the Consumer, the other the Supplier, and the
-replication may be either Full or Incremental.
-
-
-
-7.1.1
- Authentication
-
-
-The initiation of a Replication Session is to be restricted to
-privileged clients. The identity and the credentials for the client
-eligible for initiating a replication session will be defined as
-attributes within Replication Agreements.
-
-7.1.2
- Consumer Initiated
-
-The Consumer binds to the Supplier using the authentication
-credentials provided in the Replication Agreement. The Consumer sends
-the "Start Replication" extended request to begin the Replication
-Session. The Supplier returns a "Start Replication" extended response
-containing a response code. The Consumer then disconnects from the
-Supplier. If the Supplier has agreed to the replication session
-initiation, it binds to the Consumer and behaves just as if the
-Supplier initiated the replication.
-
-
-
-7.1.3
- Supplier Initiated
-
-The Supplier binds to the Consumer using the authentication
-credentials provided in the Replication Agreement. The Supplier sends
-the "Start Replication" extended request to begin the
-Replication Session. The Consumer returns a "Start Replication"
-extended
-response containing a response code, and possibly its Update Vector.
-If the Consumer has agreed to the Replication Session initiation, then
-the transfer protocol begins.
-
-
-
-Merrells, Reed, Srinivasan [Page 19]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-
-
-7.2 Start Replication Session
-
-7.2.1S
- tart Replication Request
-
-
-The LDUP Update Transfer Protocol would define an LDAP Extended
-Request, referred to in this document as "Start Replication Request",
-that is sent from the Initiator to Responder. The parameters of the
-"Start Replication Request" would identify the Replication Agreement
-associated with the session, the Update Transfer Protocol associated \
-with the replication session, and other state information necessary
-to resume replication between the two servers.
-
-
-7.2.2S
- tart Replication Response
-
-
-The LDUP Update Transfer Protocol would define an LDAP Extended
-Response, "Start Replication Response", sent in reply to a Start
-Replication Request, from the Responder to the Initiator. The
-parameters of the Start Replication Response include an response code,
-and an optional Update Vector.
-
-
-
-7.3 Update Transfer
-
-Each Update Transfer Protocol is identified by an OID. An LDUP
-conformant server implementation must support those update protocols
-that are
-defined as mandatory in the Update Transfer Protocol standard , and
-may support many others. A server will advertise its
-protocols in the Root DSE multi-valued attribute
-'supportedReplicationProtocols'.
-
-The Update Transfer Protocol would define the mechanisms for a
-Consumer to receive a complete (full) update or incremental update
-based on the current state of replication represented in the Update
-Vector. A full update is necessary for initializing a consumer
-replica upon establishment of replication agreements.
-
-
-
-7.4 End Replication Session
-
-A Replication Session is terminated by the "End Replication Request"
-initiated by the supplier. The purpose of this request and response
-is to secure the state of the Update Vector associated with the two
-replicas that participated in replication. This is necessary for
-proper resumption of replication during subsequent LDUP sessions
-
-
-
-
-Merrells, Reed, Srinivasan [Page 20]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-7.5 Integrity & Confidentiality
-
-Data integrity (ie, protection from unintended changes) and
-confidentiality (ie, protection from unintended disclosure to
-eavesdroppers) SHOULD be provided by appropriate selection of
-underlying transports, for instance TLS, or IPSEC. Replication MUST
-be supported across TLS LDAP connections. Servers MAY be configured
-to refuse replication connections over unprotected TCP connections.
-
-
-
-
-8 LDUP Update Protocols
-
-
-This Internet-Draft defines two transfer protocols for the supplier to
-push changes to the consumer. Other protocols could be defined to
-transfer changes, including those which pull changes from the supplier
-to the consumer, but those are left for future work.
-
-
-
-8.1 Replication Updates and Update Primitives
-
-Both LDUP Update Protocols define how Replication Updates are
-transferred from the Supplier to the Consumer. Each Replication Update
-consists of a set of Update Primitives that describe the state changes
-that have been made to a single entry. Each Replication Update is
-associated with a single entry identified by its UUID.
-
-
- The Update Transfer Protocol would define a set of Update Primitives
-each of which codifies an assertion about the state change of an entry
-that resulted from a directory update operation. The primitives will
-include sufficient data to allow recreation of corresponding state
-changes on the consumer's replica. An assertion based approach has
-been chosen in such a way that the Primitives are idempotent, meaning
-that re-application of a Primitive to an Entry will cause no change to
-the entry. This is desirable as it provides some resilience against
-some kinds of system failures.
-
-Each Update Primitive contains a CSN that represents an ordering among
-all such primitives generated anywhere in the
-network. This ordering information is used by the consumer to reconcile
-among those primitives that lead to consistency violation
-ier.
-
-
-8.2 Fractional Updates
-
-When fully populating or incrementally bringing up to date a
-Fractional Replica each of the Replication Updates must only contain
-updates to the attributes in the Fractional Entry Specification.
-
-
-
-Merrells, Reed, Srinivasan [Page 21]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-9 LDUP Full Update Transfer Protocol
-
-
-
-
-9.1 Full Update Transfer
-
-This Full Update Protocol provides a bulk transfer of the replica
-contents for the initial population of new replicas, and the
-refreshing of existing replicas. The LDUP Update Transfer protocol
-standard will define the ways for this transfer is initiated.
-
-The Consumer must replace its entire replica contents with that sent
-from the Supplier.
-
-The Consumer need not service any requests for this Naming Context
-whilst the full update is in progress. The Consumer could instead
-return a
-referral to another replica, possibly the supplier.
-
-
-
-9.2 Replication Update Generation
-
-The entire state of a Replicated Area can be mapped onto a sequence of
-Replication Updates, each of which contains a sequence of Update
-Primitives that describe the entire state of a single entry.
-
-The sequence of Replication Updates must be ordered such that no entry
-is created before its parent.
-
-
-
-9.3 Replication Update Consumption
-
-A Consumer will receive the Replication Updates, extract the sequence
-of Update Primitives, and must apply them to the DIB in the order
-provided.
-
-
-
-9.4 Full Update, End Replication Session
-
-
-A Full Update should also result in the replication of all appropriate
-LDUP meta data (which are part of the replicated naming context), such
-as the sub-entry representing the Replica being updated and the Update
-Vector associated with it.
-The Supplier could be accepting updates whilst the update is in
-progress. Once the Full Update has completed, an Incremental Update
-should be performed to transfer these changes.
-
-
-
-
-
-Merrells, Reed, Srinivasan [Page 22]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-9.5 Interrupted Transmission
-
-If the Replication Session terminates before the End Replication
-Request is sent, then the Replica could be in an inconsistent state.
- Until the replica is restored to a consistent
-state, the consumer might not permit LDAP Clients to access the
-incomplete replica. The Consumer could refer the Client to the
-Supplier Replica, or return an error result code.
-
-
-
-10 LDUP Incremental Update Transfer Protocol
-
-
-For efficiency, the Incremental Update Protocol transmits only those
-changes that have been made to the Supplier replica that the Consumer
-has not already received. In a replication topology with transitive
-redundant replication agreements, changes may propagate through the
-replica network via different routes.
-
-The Consumer must not support multiple concurrent replication sessions
-with more than one Supplier for the same Naming Context. A Supplier
-that attempts to initiate a Replication Session with a Consumer
-already participating as a Consumer in another Replication Session
-will receive appropriate error. .
-
-
-
-10.1 Update Vector
-
-The Supplier uses the Consumer's Update Vector to determine the
-sequence of updates that should be sent to the Consumer.
-
-Each Replica entry includes an Update Vector to record the point to
-which the replica has been updated. The vector is a set of CSN values,
-one value for each known updateable Replica. Each CSN value in the
-vector corresponds to the most recent change that occurred in an
-updateable replica that has been replicated to the replica whose
-replication state this Update Vector represents.
-
-For example, consider two updatable replicas of a naming context, one
-is assigned replica identifier '1', the other replica identifier '2'.
-Each is responsible for maintaining its own update vector, which will
-contain two CSNs, one for each replica. So, if both replicas are
-identical they will have equivalent update vectors.
-
-Both Update Vectors =
-
-{1998081018:44:31z#0x000F#1#0x0000, 1998081018:51:20z#0x0001#2#0x0000}
-
-Subsequently, at 7pm, an update is applied to replica '2', so its
-update vector is updated.
-
-Replica '1' Update Vector =
-
-{1998081018:44:31z#0x000F#1#0x0000, 1998081018:51:20z#0x0001#2#0x0000}
-
-Merrells, Reed, Srinivasan [Page 23]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-
-Replica '2' Update Vector =
-
-{1998081018:44:31z#0x000F#1#0x0000, 1998081019:00:00z#0x0000#2#0x0000}
-
-Since the Update Vector records the state to which the replica has
-been updated, a supplier server, during Replication Session
-initiation, can determine the sequence of updates that should be sent
-to the consumer. From the example above no updates need to be sent
-from replica '1' to replica '2', but there is an update pending from
-replica '2' to replica '1'.
-
-Because the Update Vector embodies knowledge of updates made at all
-known replicas it supports replication topologies that include
-transitive and redundant connections between replicas. It ensures that
-changes are not transferred to a consumer multiple times even though
-redundant replication agreements may exist. It also ensures that
-updates are passed across the replication network between replicas
-that are not directly linked to each other.
-
-It may be the case that a CSN for a given replica is absent, for one
-of two reasons.
-
-1. CSNs for Read-Only replicas might be absent because no changes will
- have ever been applied to that Replica, so there are no changes to
- replicate.
-
-2. CSNs for newly created replicas may be absent because no changes to
- that replica have yet been propagated.
-
-An Update Vector might also contain a CSN for a replica that no longer
-exists. The replica may have been temporarily taken out of service,
-or may have been removed from the replication topology permanently. An
-implementation may choose to retire a CSN after some configurable time
-period.
-
-
-
-10.2 Supplier Initiated, Incremental Update, Start Replication Session
-
-The Consumer Responder must return its Update Vector to the Supplier
-Initiator. The Supplier uses this to determine the sequence of
-Replication Updates that need to be sent to the Consumer.
-
-
-
-10.3 Replication Update Generation
-
-The Supplier generates a sequence of Replication Updates to be sent to
-the consumer. To enforce LDAP Constraint 20.1.6, that the LDAP Modify
-must be applied atomically, each Replication Update must contain the
-entire sequence of Update Primitives for all the LDAP Operations for
-which the Replication Update contains Update Primitives. Stated less
-formally, for each primitive the update contains, it must also contain
-all the other primitives that came from the same operation.
-
-
-Merrells, Reed, Srinivasan [Page 24]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-
-
-10.3.1 Replication Log Implementation
-
-A log-based implementation might take the approach of mapping LDAP
-Operations onto an equivalent sequence of Update Primitives. A
-systematic procedure for achieving this will be fully described in the
-standard document defining Update Reconciliation Procedures.
-
-The Consumer Update Vector is used to determine the sequence of LDAP
-Operations in the operation log that the Consumer has not yet seen.
-
-
-
-10.3.2 State-Based Implementation
-
-A state-based implementation might consider each entry of the replica
-in turn using the Update Vector of the consumer to find all the state
-changes that need to be transferred. Each state change (entry,
-attribute, or value - creation, deletion, or update) is mapped onto
-the equivalent Update Primitive. All the Update Primitives for a
-single entry might be collected into a single Replication Update.
-Consequently, it could contain the resultant primitives of many LDAP
-operations.
-
-
-
-10.4 Replication Update Consumption
-
-A Consumer will receive Replication Updates, extract the sequence of
-Update Primitives, and must apply them to the DIB in the order
-provided. LDAP Constraint 20.1.6 states that the modifications within
-an LDAP Modify operation must be applied in the sequence provided.
-
-Those Update Primitives must be reconciled with the current replica
-contents and any previously received updates. In short,,
-updates are compared to the state information associated with the item
-being operated on. If the change has a more recent CSN, then it is
-applied to the directory contents. If the change has an older CSN it
-is no longer relevant and its change must not be effected.
-
-If the consumer acts as a supplier to other replicas then the updates
-are retained for forwarding.
-
-
-
-10.5 Update Resolution Procedures
-
-The LDAP Update Operations must abide by the constraints imposed by
-the LDAP Data Model and LDAP Operational Behaviour, Appendix A. An
-operation that would violate at least one of these constraints is
-rejected with an error result code.
-
-The loose consistency model of this replication architecture and its
-support for multiple updateable replicas of a naming context means
-
-
-Merrells, Reed, Srinivasan [Page 25]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-that LDAP Update Operations could be valid at one replica, but not in
-another. At the time of acceptance, the accepting
-replica may not have received other updates that would cause a
-constraint to be violated, and the operation to be rejected.
-
-Replication Updates must never be rejected because of a violation of
-an LDAP Constraint. If the result of applying the Replication Update
-causes a constraint violation to occur, then some remedial action must
-be taken to satisfy the constraint. These Update Resolution Procedures
-are introduced here will be fully defined withinLDUP Update Resolution
-Procedures.
-
-
-
-10.5.1 URP: Distinguished Names
-
-LDAP Constraints 20.1.1 and 20.1.10 ensure that each entry in the
-replicated area has a unique DN. A Replication Update could violate
-this constraint producing two entries, with different unique
-identifiers, but with the same DN. The resolution procedure is to
-rename the most recently named entry so that its RDN includes its own
-unique identifier. This ensures that the new DN of the entry shall be
-unique.
-
-
-
-10.5.2 URP: Orphaned Entries
-
-LDAP Constraints 20.1.11 ensures that every entry must have a parent
-entry. A Replication Update could violate this constraint producing an
-entry with no parent entry. The resolution procedure is to create a
-Glue Entry to take the place of the absent parent. The Glue Entry's
-superior will be the Lost and Found Entry. This well known place
-allows administrators and their tools to find and repair abandoned
-entries.
-
-
-
-10.5.3 URP: Distinguished Not Present
-
-LDAP Constraints 20.1.8 and 20.1.9 ensure that the components of an
-RDN appear as attribute values of the entry. A Replication Update
-could violate this constraint producing an entry without its
-distinguished values. The resolution procedure is to add the missing
-attribute values, and mark them as distinguished not present, so that
-they can be deleted when the attribute values are no longer
-distinguished.
-
-
-
-10.5.4 URP: Schema - Single Valued Attributes
-
-LDAP Constraint 20.1.7 enforces the single-valued attribute schema
-restriction. A Replication Update could violate this constraint
-creating a multi-value single-valued attribute. The resolution
-
-
-Merrells, Reed, Srinivasan [Page 26]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-procedure is to consider the value of a single-valued attribute as
-always being equal. In this way the most recently added value will be
-retained, and the older one discarded.
-
-
-
-10.5.5 URP: Schema - Required Attributes
-
-LDAP Constraint 20.1.7 enforces the schema objectclass definitions on
-an entry. A Replication Update could violate this constraint creating
-an entry that does not have attribute values for required attributes.
-The resolution procedure is to ignore the schema violation and mark
-the entry for administrative repair.
-
-
-
-10.5.6 URP: Schema - Extra Attributes
-
-LDAP Constraint 20.1.3 and 20.1.7 enforces the schema objectclass
-definitions on an entry. A Replication Update could violate this
-constraint creating an entry that has attribute values not allowed by
-the objectclass values of the entry. The resolution procedure is to
-ignore the schema violation and mark the entry for administrative
-repair.
-
-
-
-10.5.7 URP: Duplicate Attribute Values
-
-LDAP Constraint 20.1.5 ensures that the values of an attribute
-constitute a set of unique values. A Replication Update could violate
-this constraint. The resolution procedure is to enforce this
-constraint, recording the most recently assigned CSN with the value.
-
-
-
-10.5.8 URP: Ancestry Graph Cycle
-
-LDAP Constraint 20.4.2.1 prevents against a cycle in the DIT. A
-Replication Update could violate this constraint causing an entry to
-become it's own parent, or for it to appear even higher in it's
-ancestry graph. The resolution procedure is to break the cycle by
-changing the parent of the entry closest to be the lost and found
-entry.
-
-
-
-10.6 Incremental Update, End Replication Session
-
-If the Supplier sent none of its own updates to the Consumer, then the
-Supplier's CSN within the Supplier's update vector should be updated
-with the earliest possible CSN that it could generate, to record the
-time of the last successful replication session. The Consumer will
-have received the Supplier's Update Vector in the replica sub-entry it
-holds for the Supplier replica.
-
-Merrells, Reed, Srinivasan [Page 27]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-
-The Consumer's resultant Update Vector CSN values will be at least as
-great as the Supplier's Update Vector.
-
-The Supplier may request that the Consumer return its resultant Update
-Vector so that the Supplier can update its replica sub-entry for the
-Consumer Replica. The Supplier requests this by setting a flag in the
-End Replication Request. The default flag value is TRUE meaning the
-Consumer Update Vector must be returned.
-
-
-
-10.7 Interrupted Transmission
-
-If the Replication Session terminates before the End Replication
-Request is sent then the Consumer's Update Vector may or may not be
-updated to reflect the updates received. The Start Replication request
-includes a Replication Update Ordering flag which states whether the
-updates were sent in CSN order per replica.
-
-If updates are sent in CSN order per replica then it is possible to
-update the Consumer Update Vector to reflect that some portion of the
-updates to have been sent have been received and successfully applied.
-The next Incremental Replication Session will pick up where the failed
-session left off.
-
-If updates are not sent in CSN order per replica then the Consumer
-Update can not be updated. The next Incremental Replication Session
-will begin where the failed session began. Some updates will be
-replayed, but because the application of Replication Updates is
-idempotent they will not cause any state changes.
-
-
-
-11 Purging State Information
-
-
-The state information stored with each entry need not be stored
-indefinitely. A server implementation may choose to periodically, or
-continuously, remove state information that is no longer required. The
-mechanism is implementation-dependent, but to ensure interoperability
-between implementations, the state information must not be purged
-until all known replicas have received and acknowledged the change
-associated with a CSN. This is determined from the Purge Vector
-[11.1].
-
-All the CSNs stored that are lower than the Purge Vector may be
-purged, because no changes with older CSNs can be replicated to this
-replica.
-
-
-
-11.1 Purge Vector
-
-The Purge Vector is an Update Vector constructed from the Update
-Vectors of all known replicas. Each replica has a sub-entry for each
-
-Merrells, Reed, Srinivasan [Page 28]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-known replica stored below its naming context. Each of those entries
-contains the last known update vector for that replica. The lowest CSN
-for each replica are taken from these update vectors to form the Purge
-Vector. The Purge Vector is used to determine when state information
-and updates need no longer be stored.
-
-
-
-11.2 Purging Deleted Entries, Attributes, and Attribute Values
-
-The following conditions must hold before an item can be deleted from
-the Directory Information Base.
-
-1) The LDAP delete operation has been propagated to all replication
-agreement partners.
-
-2) All the updates from all the other replicas with CSNs less than the
-CSN on the deletion have been propagated to the server holding the
-deleted entry (similarly for deleted attributes and attribute values).
-
-3) The CSN generator of the other Replicas must have advanced beyond
-the deletion CSN of the deleted entry. Otherwise, it is possible for
-one of those Replicas to generate operations with CSNs earlier than
-the deleted entry.
-
-
-12 Replication Configuration and Management
-
-
-Replication management entries, such as replica or replication
-agreement entries, can be altered on any updateable replica. These
-entries are implicitly included in the directory entries governed by
-any agreement associated with this naming context. As a result, all
-servers with a replica of a naming context will have access to
-information about all other replicas and associated agreements.
-
-The deployment and maintenance of a replicated directory network
-involves the creation and management of all the replicas of a naming
-context and replication agreements among these replicas. This section
-outlines, through an example, the administrative actions necessary to
-create a new replica and establish replication agreements. Typically,
-administrative tools will guide the administrator and facilitate these
-actions. The objective of this example is to illustrate the
-architectural relationship among various replication related
-operational information.
-
-A copy of an agreement should exist on both the supplier and consumer
-side for the replication update transfer protocol to be able to start.
-For this purpose, the root of the naming context, replica objects and
-the replication agreement objects are created first on one of the
-servers. A copy of these objects are then manually created on the
-second server associated with the agreement.
-
-The scenario below starts with a server (named DSA1) that holds an
-updateable replica of a naming context NC1. Procedures to establish
-an updateable replica of the naming context on a second server (DSA2)
-
-Merrells, Reed, Srinivasan [Page 29]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-are outlined.
-
-On DSA1:
-
-1) Add the context prefix for NC1 to the Root DSE attribute
- 'replicaRoot' if it does not already exist.
-
-2) Alter the 'ObjectClass' attribute of the root entry of NC1 to
- include the "namingContext" auxiliary class.
-
-3) Create a replica object, NC1R1, (as a child of the root of NC1) to
- represent the replica on DSA1. The attributes include replica type
- (updateable, read-only etc.) and DSA1 access point information.
-
-4) Create a copy of the replica object NC1R2 (after it is created on
- DSA2)
-
-5) Create a replication agreement, NC1R1-R2 to represent update
- transfer from NC1R1 to NC1R2. This object is a child of NC1R1.
-
-On DSA2:
-
-1) Add NC1's context prefix to the Root DSE attribute 'replicaRoot'.
-
-2) Create a copy of the root entry of NC1 as a copy of the one in DSA1
- (including the namingContext auxiliary class)
-
-3) Create a copy of the replica object NC1R1
-
-4) Create a second replica object, NC1R2 (as a sibling of NC1R1) to
- represent the replica on DSA2.
-
-5) Create a copy of the replication agreement, NC1R1-R2
-
-6) Create a replication agreement, NC1R2-R1, to represent update
- transfer from NC1R2 to NC1R1. This object is a sibling of NC1R1-
- R2.
-
-After these actions update transfer to satisfy either of the two
-agreements can commence.
-
-If data already existed in one of the replicas, the update transfer
-protocol should perform a complete update of the data associated with
-the agreement before normal replication begins.
-
-
-
-13 Time
-
-
-The server assigns a CSN for every LDAP update operation it receives.
-Since the CSN is principally based on time, the CSN is susceptible to
-the Replica clocks drifting in relation to each other (either forwards
-or backwards).
-
-The server must never assign a CSN older than or equal to the last CSN
-it assigned.
-
-Merrells, Reed, Srinivasan [Page 30]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-
-The server must reject update operations, from any source, which would
-result in setting a CSN on an entry or a value which is earlier than
-the one that is there. The error code serverClocksOutOfSync (72)
-should be returned.
-
-
-14 Security Considerations
-
-
-The preceding architecture discussion covers the server
-authentication, session confidentiality, and session integrity in
-sections 7.1.1 and 7.5
-
-The internet draft "Authentication Methods" for LDAP, provides a
-detailed LDAP security discussion. Its introductory passage is
-paraphrased below. [AUTH]
-
-A Replication Session can be protected with the following security
-mechanisms.
-
-1) Authentication by means of the SASL mechanism set, possibly backed
- by the TLS credentials exchange mechanism,
-
-2) Authorization by means of access control based on the Initiators
- authenticated identity,
-
-3) Data integrity protection by means of the TLS protocol or data-
- integrity SASL mechanisms,
-
-4) Protection against snooping by means of the TLS protocol or data-
- encrypting SASL mechanisms,
-
-The configuration entries that represent Replication Agreements may
-contain authentication information. This information must never be
-replicated between replicas.
-
-Updates to a multi-mastered entry may collide causing the Update
-Resolution Procedures [10.5] to reject or reverse one of the changes
-to the entry. The URP algorithms resolve conflicts by using the total
-ordering of updates imposed by the assignment of CSNs for every
-operation. As a consequence updates originating from system
-administrators have no priority over updates originating from regular
-system users.
-
-
-
-15 Acknowledgements
-
-
-This document is a product of the LDUP Working Group of the IETF. The
-contributions of its members is greatly appreciated.
-
-
-
-
-
-Merrells, Reed, Srinivasan [Page 31]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-16 References
-
-
-[AUTH] - M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
-"Authentication Methods for LDAP", Internet Draft, draft-ietf-ldapext-
-authmeth-02.txt, June 1998.
-
-[BCP-11] - R. Hovey, S. Bradner, "The Organizations Involved in the
-IETF Standards Process", BCP 11, RFC 2028, October 1996.
-
-[LDAPv3] - M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
-Protocol (v3)", RFC 2251, December1997.
-
-[LDUP Requirements] - R. Weiser, E. Stokes 'LDAP Replication
-Requirements', Internet Draft, draft-weiser-replica-req-02.txt,
-October, 1999
-
-[NTP] - D. L. Mills, "Network Time Protocol (Version 3)", RFC 1305,
-March, 1992.
-
-[RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate
-Requirement Levels", RFC 2119.
-
-[RFC2252] - M. Wahl, A. Coulbeck, T. Howes, S. Kille, 'Lightweight
-Directory Access Protocol (v3): Attribute Syntax Definitions', RFC
-2252, December 1997.
-
-[SNTP] - D. L. Mills, "Simple Network Time Protocol (SNTP) Version 4
-for IPv4, IPv6 and OSI", RFC 2030, University of Delaware, October
-1996.
-
-[TLS] - J. Hodges, R. L. "Bob" Morgan, M. Wahl, "Lightweight
-Directory Access Protocol (v3): Extension for Transport
-Layer Security", Internet draft, draft-ietf-ldapext-ldapv3-tls-01.txt,
-June 1998.
-
-[X501] - ITU-T Recommendation X.501 (1993), ) | ISO/IEC 9594-2:1993,
-Information Technology - Open Systems Interconnection - The Directory:
-Models
-
-[X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995,
-Information technology - Abstract Syntax Notation One (ASN.1):
-Specification of Basic Notation
-
-[X525] - ITU-T Recommendation X.525 (1997) | ISO/IEC 9594-9:1997,
-Information Technology - Open Systems Interconnection - The Directory:
-Replication
-
-
-17 Intellectual Property Notice
-
-
-The IETF takes no position regarding the validity or scope of any
-intellectual property 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
-
-
-Merrells, Reed, Srinivasan [Page 32]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-might or might not be available; neither does it represent that it has
-made any effort to identify any such rights. Information on the
-IETF's procedures with respect to rights in standards-track and
-standards-related documentation can be found in BCP-11. [BCP-11]
-Copies of claims of rights made available for publication 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 implementors or users of this specification
-can be obtained from the IETF Secretariat.
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary
-rights which may cover technology that may be required to practice
-this standard. Please address the information to the IETF Executive
-Director.
-
-
-18 Copyright Notice
-
-
- Copyright (C) The Internet Society (1998,1999). All Rights Reserved.
-
-This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it
-or assist in its implementation may be prepared, copied, published and
-distributed, in whole or in part, without restriction of any kind,
-provided that the above copyright notice and this paragraph are
-included on all such copies and derivative works. However, this
-document itself may not be modified in any way, such as by removing
-the copyright notice or references to the Internet Society or other
-Internet organizations, except as needed for the purpose of
-developing Internet standards in which case the procedures for
-copyrights defined in the Internet Standards process must be followed,
-or as required to translate it into languages other than English.
-
-The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-This document and the information contained herein is provided on an
-"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS 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.
-
-
-19 Authors' Address
-
-
- John Merrells
- Netscape Communications, Inc.
- 501 East Middlefield Road
- Mountain View
- CA 94043
- USA
- E-mail: merrells@netscape.com
-
-
-Merrells, Reed, Srinivasan [Page 33]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
- Phone: +1 650-937-5739
-
- Edwards E. Reed
- Reed-Matthews, Inc.
- 1064 East 140 North
- Lindon
- UT 84042
- USA
- E-mail: eer@oncalldba.com
- Phone: +1 801-796-7065
-
- Uppili Srinivasan
- Oracle, Inc.
- Redwood Shores
- CA
- USA
- E-mail: usriniva@us.oracle.com
- Phone: +1 650 506 3039
-
- LDUP Engineering Mailing List: ldup-repl@external.cisco.com
- LDUP Working Group Mailing List: ietf-ldup@imc.org
-
-
-20 Appendix A - LDAP Constraints
-
-
-20.1 LDAP Constraints Clauses
-
-This is an enumeration of the Data Model and Operation Behaviour
-constraint clauses defined in RFC 2251. [LDAPv3]
-
-1) Data Model - Entries have names: one or more attribute values from
- the entry form its relative distinguished name (RDN), which MUST be
- unique among all its siblings. (p5)
-
-2) Data Model - Attributes of Entries - Each entry MUST have an
- objectClass attribute. (p6)
-
-3) Data Model - Attributes of Entries - Servers MUST NOT permit
- clients to add attributes to an entry unless those attributes are
- permitted by the object class definitions. (p6)
-
-4) Relationship to X.500 - This document defines LDAP in terms of
- X.500 as an X.500 access mechanism. An LDAP server MUST act in
- accordance with the X.500 (1993) series of ITU recommendations when
- providing the service. However, it is not required that an LDAP
- server make use of any X.500 protocols in providing this service,
- e.g. LDAP can be mapped onto any other directory system so long as
- the X.500 data and service model as used in LDAP is not violated in
- the LDAP interface. (p8)
-
-5) Elements of Protocol - Common Elements - Attribute - Each attribute
- value is distinct in the set (no duplicates). (p14)
-
-6) Elements of Protocol - Modify Operation - The entire list of entry
- modifications MUST be performed in the order they are listed, as a
-
-Merrells, Reed, Srinivasan [Page 34]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
- single atomic operation. (p33)
-
-7) Elements of Protocol - Modify Operation - While individual
- modifications may violate the directory schema, the resulting entry
- after the entire list of modifications is performed MUST conform to
- the requirements of the directory schema. (p33)
-
-8) Elements of Protocol - Modify Operation - The Modify Operation
- cannot be used to remove from an entry any of its distinguished
- values, those values which form the entry's relative distinguished
- name. (p34)
-
-9) Elements of Protocol - Add Operation - Clients MUST include
- distinguished values (those forming the entry's own RDN) in this
- list, the objectClass attribute, and values of any mandatory
- attributes of the listed object classes. (p35)
-
-10) Elements of Protocol - Add Operation - The entry named in the
- entry field of the AddRequest MUST NOT exist for the AddRequest to
- succeed. (p35)
-
-11) Elements of Protocol - Add Operation - The parent of the entry to
- be added MUST exist. (p35)
-
-12) Elements of Protocol - Delete Operation - ... only leaf entries
- (those with no subordinate entries) can be deleted with this
- operation. (p35)
-
-13) Elements of Protocol - Modify DN Operation - If there was already
- an entry with that name [the new DN], the operation would fail.
- (p36)
-
-14) Elements of Protocol - Modify DN Operation - The server may not
- perform the operation and return an error code if the setting of
- the deleteoldrdn parameter would cause a schema inconsistency in
- the entry. (p36)
-
-
-
-20.2 LDAP Data Model Constraints
-
-The LDAP Data Model Constraint clauses as written in RFC 2251 [LDAPv3]
-may be summarised as follows.
-
-a) The parent of an entry must exist. (LDAP Constraint 11 & 12.)
-
-b) The RDN of an entry is unique among all its siblings. (LDAP
- Constraint 1.)
-
-c) The components of the RDN must appear as attribute values of the
- entry. (LDAP Constraint 8 & 9.)
-
-d) An entry must have an objectclass attribute. (LDAP Constraint 2 &
- 9.)
-
-e) An entry must conform to the schema constraints. (LDAP Constraint
-
-
-Merrells, Reed, Srinivasan [Page 35]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
- 3 & 7.)
-
-f) Duplicate attribute values are not permitted. (LDAP Constraint 5.)
-
-
-
-20.3 LDAP Operation Behaviour Constraints
-
-The LDAP Operation Behaviour Constraint clauses as written in RFC 2251
-[LDAPv3] may be summarised as follows.
-
-A) The Add Operation will fail if an entry with the target DN already
-exists. (LDAP Constraint 10.)
-
-B) The Add Operation will fail if the entry violates data constraints:
-
- a - The parent of the entry does not exist. (LDAP Constraint 11.)
-
- b - The entry already exists. (LDAP Constraint 10.)
-
- c - The entry RDN components appear as attribute values on the
- entry. (LDAP Constraint 9.)
-
- d - The entry has an objectclass attribute. (LDAP Constraint 9.)
-
- e - The entry conforms to the schema constraints. (LDAP
- Constraint 9.)
-
- f - The entry has no duplicated attribute values. (LDAP
-Constraint 5.)
-
-C) The modifications of a Modify Operation are applied in the order
-presented. (LDAP Constraint 6.)
-
-D) The modifications of a Modify Operation are applied atomically.
-(LDAP Constraint 6.)
-
-E) A Modify Operation will fail if it results in an entry that
-violates data constraints:
-
- c - If it attempts to remove distinguished attribute values.
- (LDAP Constraint 8.)
-
- d - If it removes the objectclass attribute. (LDAP Constraint 2.)
-
- e - If it violates the schema constraints. (LDAP Constraint 7.)
-
- f - If it creates duplicate attribute values. (LDAP Constraint
- 5.)
-
-F) The Delete Operation will fail if it would result in a DIT that
-violates data constraints:
-
- a - The deleted entry must not have any children. (LDAP
-Constraint 12.)
-
-
-
-Merrells, Reed, Srinivasan [Page 36]
- Expires 10 September 2000
-
-
-
-
-
-INTERNET-DRAFT LDAP Replication Architecture March 10, 2000
-
-
-G) The ModDN Operation will fail if it would result in a DIT or entry
-that violates data constraints:
-
- b - The new Superior entry must exist. (Derived LDAP Data Model
- Constraint A)
-
- c - An entry with the new DN must not already exist. (LDAP
- Constraint 13.)
-
- c - The new RDN components do not appear as attribute values on
- the entry. (LDAP Constraint 1.)
-
- d - If it removes the objectclass attribute. (LDAP Constraint 2.)
-
- e - It is permitted for the operation to result in an entry that
- violates the schema constraints. (LDAP Constraint 14.)
-
-
-
-20.4 New LDAP Constraints
-
-The introduction of support for multi-mastered entries, by the
-replication scheme presented in this document, necessitates the
-imposition of new constraints upon the Data Model and LDAP Operation
-Behaviour.
-
-
-
-20.4.1 New LDAP Data Model Constraints
-
-1) Each entry shall have a unique identifier generated by the UUID
-algorithm available through the 'entryUUID' operational attribute. The
-entryUUID attribute is single valued.
-
-
-
-20.4.2 New LDAP Operation Behaviour Constraints
-
-1) The LDAP Data Model Constraints do not prevent cycles in the
- ancestry graph. Existing constraints Data Model Constraint - 20.4.1
- - (a) and Operation Constraint - 20.4.2 - (B) would prevent this in
- the single master case, but not in the presence of multiple
- masters.
-
-2) The LDAP Data Model Constraints state that only the LDAP Modify
- Operation is atomic. All other LDAP Update Operations are also
- considered to be atomically applied to the DIB.
-
-
-
-
-
-
-
-
-
-Merrells, Reed, Srinivasan [Page 37]
- Expires 10 September 2000
-
-
+++ /dev/null
-
-LDUP Replication Update Protocol
-Internet-Draft
-Intended Category: Standards Track
-Expires: September 10, 2000
-
-
- Ellen Stokes
- IBM Corporation
-
- Gordon Good
- Netscape Communications Corp.
-
- March 10 2000
-
- The LDUP Replication Update Protocol
- Filename: draft-ietf-ldup-protocol-01.txt
-
-Table of Contents
-
-1. Status of this Memo.............................................2
-2. Abstract........................................................2
-3. Overview of Protocol............................................2
-4. High-level Description of Protocol Flow.........................3
-4.1 Supplier-initiated incremental replication protocol.............3
-4.2. Consumer-initiated replication protocol......................4
-5. Replication protocol element definitions........................5
-5.1 StartFramedProtocolRequest Extended Operation...................5
-5.2 StartFramedProtocolResponse Extended Operation..................6
-5.3 ReplicationUpdate Extended Operation............................7
-5.3.1 UniqueIdentifier.............................................8
-5.3.2 ReplicationPrimitive.........................................8
-5.3.2.1 AddEntryPrimitive.........................................8
-5.3.2.2 MoveEntryPrimitive........................................9
-5.3.2.3 RenameEntryPrimitive......................................9
-5.3.2.4 RemoveEntryPrimitive......................................9
-5.3.2.5 AddAttributeValuePrimitive................................10
-5.3.2.6 RemoveAttributeValuePrimitive.............................10
-5.3.2.7 RemoveAttributePrimitive..................................10
-5.4 EndFramedProtocolRequest Extended Operation.....................11
-5.5 EndFramedProtocolResponse Extended Operation....................11
-5.6 ReplicationUpdateResponse Extended Operation....................12
-6. Semantics of Full and Incremental Update protocols..............13
-7. Summary of response codes.......................................13
-8. Implications for log-based and state-based servers..............13
-9. Replication of access control and schema information............13
-10. Security Considerations.........................................14
-11. Glossary of Terms...............................................14
-12. Acknowledgments.................................................14
-13. References......................................................14
-14. Author's Addresses..............................................15
-
-
-
-Stokes and Good [Page 1]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
-1. Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet- Drafts as reference
- material or to cite them other than as "work in progress."
-
- To view the list Internet-Draft Shadow Directories, see
- http://www.ietf.org/shadow.html.
-
- This Internet Draft expires September 10, 2000.
-
-
-2. Abstract
-
- The protocol described in this document is designed to allow one LDAP
- server to replicate its directory content to another LDAP server. The
- protocol is designed to be used in a replication configuration where
- multiple updatable servers are present. Provisions are made in the
- protocol to carry information that allows the server receiving
- updates to apply a total ordering to all updates in the replicated
- system. This total ordering allows all replicas to correctly resolve
- conflicts that arise when LDAP clients submit changes to different
- servers that later replicate to one another.
-
- All protocol elements described here are LDAP Version 3 extended
- operations. LDAP Version 3 is described in RFC 2251 [LDAPv3].
-
- Certain terms used in this document are defined in the document "LDAP
- Replication Architecture" (draft-ietf-ldup-model-00.txt).
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
- to be interpreted as described in RFC 2119 [KEYWORDS].
-
-3. Overview of Protocol
-
- The LDAP Replication Architecture [ARCHITECTURE] describes the
- overall approach used in ensuring consistency of multiple updatable
- replicas of directory content. The protocol described in this
- document implements the approach desribed in that document.
-
-
-
-Stokes and Good [Page 2]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
- LDAP Version 3 extended operations are used to carry replicated
- content from one server to another. The extended operations defined
- in this document are used to initiate and end a replication session,
- and to exchange updates. These updates carry with them information
- that allows the receiving server to apply a total ordering to all of
- the updates in a replicated system. All servers that receive
- replication updates apply a consistent set of update resolution
- policies, described in [URP]. Consistent application of the update
- resolution policies ensures that all replicas eventually converge and
- contain the same directory data.
-
- This protocol is based upon the extended operations defined in
- [FRAMING].
-
- This protocol is intended to meet the requirements set forth in
- [REQ].
-
-4. High-level Description of Protocol Flow
-
- The following section provides a high-level overview of the
- replication protocol. Throughout this section, the supplier server is
- indicated by the letter "S" and the consumer server by the letter
- "C". The construct "S -> C" indicates that the supplier is sending an
- LDAPv3 extended operation to the consumer, and "C -> S" indicates
- that the consumer is sending an LDAPv3 extended operation to the
- supplier.
-
-4.1 Supplier-initiated incremental replication protocol
-
- S -> C: LDAP bind operation (identity and credentials
- used are implementation-defined)
-
- C -> S: Bind response
-
- S -> C: StartFramedProtocolRequest LDAPv3 extended
- operation. The parameters are:
-
- 1) The OID for the LDUP incremental replication protocol or the
- LDUP total update protocol, depending on whether an incremental
- or complete refresh of the replica is to be performed.
- 2) A protocol-specific payload containing:
- a) The root of replicated area (unambiguously
- identifies the replicated area)
- b) The supplier's replicaID
- c) The protocol initiation type - Supplier-Initiated
- in this case.
-
- C -> S: StartFramedProtocolResponse LDAPv3 extended operation. The
-
-
-
-Stokes and Good [Page 3]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
- parameters are:
-
- 1) A protocol-specific payload containing:
- a) A response code (see section 7)
- b) An optional update vector that is included
- if and only if the response code is REPL_SUCCESS.
-
- S -> C: The supplier may send zero or more ReplicationUpdate LDAPv3
- extended operations. The parameters are:
-
- 1) The UUID of the entry being updated
- 2) One or more Replication Primitives (The supplier
- may send as many of these as required to bring
- the consumer up to date)
-
- C -> S: At any time, the consumer may send an unsolicited
- ReplicationUpdateResponse LDAPv3 extended operation. The
- parameters are:
-
- 1) An optional update vector. If sent, this indicates that
- the consumer has committed all updates whose CSNs are
- covered by the transmitted update vector [see glossary
- for a definition of "covered by"].
- 2) An optional AbortUpdate boolean flag. If a supplier
- receives a ReplicationUpdateResponse from a consumer with
- the AbortUpdate flag set to true, the supplier server MUST
- immediately cease sending updates and terminate its
- connection to the consumer.
-
- S -> C: After all required updates have been sent to the consumer, the
- supplier sends an EndFramedProtocolRequest LDAPv3 extended
- operation.
-
- C -> S: The consumer responds by sending an EndFramedProtocolResponse
- LDAPv3 extended operation, and then closes the connection.
-
-4.2. Consumer-initiated replication protocol
-
- C -> S: LDAP bind operation (identity and credentials
- used are implementation-defined)
-
- S -> C: Bind response
-
- C -> S: StartFramedProtocolRequest LDAPv3 extended
- operation. The parameters are:
-
- 1) The OID for the LDUP incremental replication protocol or the
- LDUP total update protocol, depending on whether an incremental
-
-
-
-Stokes and Good [Page 4]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
- or complete refresh of the replica is to be performed.
- 2) A protocol-specific payload containing:
- a) The root of replicated area (unambiguously
- identifies the replicated area)
- b) The consumer's replicaID
- c) The protocol initiation type - Consumer-Initiated
- in this case.
-
- S -> C: StartFramedProtocolResponse LDAPv3 extended operation. The
- parameters are:
-
- 1) A protocol-specific payload containing:
- a) A response code (see section 7)
-
- S -> C: The supplier server disconnects from the consumer server,
- and then connects to the consumer, beginning a Supplier-
- Initiated protocol session (see section 4.1).
-
-
-5. Replication protocol element definitions
-
-5.1 StartFramedProtocolRequest Extended Operation
-
- The StartFramedProtocolRequest extended operation is sent by a replication
- initiator to a server to indicate that a replication session should
- commence. For supplier-initiated replication, the supplier sends this
- extended operation to the replication consumer to indicate that a
- replication session should commence. For consumer-initiated
- replication, the consumer sends this extended operation to the
- replication supplier to indicate that the supplier should initiate a
- replication session to the consumer as soon as possible.
-
- The StartFramedProtocolRequest extended operation is defined
- in [FRAMING]. When signaling the beginning of a replication
- session, then requestValue of the StartFramedProtocolRequest
- is set to the following:
-
- requestValue ::= SEQUENCE {
- framedProtocolOID LDAPOID,
- framedProtocolPayload OPTIONAL OCTET STRING
- }
-
- The framedProtocolOID of the StartReplicationRequest must be the OID
- for the LDUP incremental replication protocol,
- 2.16.840.1.113719.1.142.1.4.3, or the LDUP total update protocol,
- 2.16.840.1.113719.1.142.1.4.4. See section 7 for information on the
- semantic behavior of these update protocols. Implementations MUST
- support the two update protocols defined in this document.
-
-
-
-Stokes and Good [Page 5]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
- The framedProtocolPayload of the StartFramedProtocolRequestValue must
- be set to the BER-encoding of the following:
-
- framedProtocolPayload ::= SEQUENCE {
- replicaRoot LDAPDN,
- replicaID LDAPString,
- replicationInitiator ENUMERATED {
- supplier (0),
- consumer (1)
- }
- }
-
- The parameters in the framedProtocolPayload of the
- StartFramedProtocolRequestValue are:
-
- - replicaRoot: the distinguished name of the entry at the top of
- the replicated area, and uniquely identifies the unit of
- replication.
-
- - replicaID: the replica identifier of the replication initiator.
- Each replica of a given replicated area is identified by a unique
- identifier, described in [ARCHITECTURE].
-
- - replicationInitiator: used to differentiate between a supplier-
- initiated session and a consumer-initiated session. If the
- replicationInitiator contains the enumerated value <supplier>,
- then the initiator is the supplier, and the receiver of this
- operation should prepare to receive a set of replication updates
- (or should reject the operation is replication updates are not
- permitted for some reasonm, perhaps due to access control
- restrictions). If the replicationInitiator contains the
- enumerated value <consumer>, then the receiver should prepare to
- establish a supplier-initiated replication session with the
- consumer as soon as possible, updating the replicated are given by
- replicaRoot and using the update protocol given by
- replicationProtocolOID.
-
-5.2 StartFramedProtocolResponse Extended Operation
-
- The StartFramedProtocolResponse extended operation is sent in
- response to a StartFramedProtocolRequest extended operation.
-
- For a supplier-initiated session, the response field of the
- StartFramedProtocolResponse extended response indicates that the
- consumer is or is not prepared to accept a set of updates. If the
- consumer is prepared to accept updates, it sends a response field
- containing a success code and the consumer's replica update vector.
- If the consumer is unwilling or unable to accept updates, it sends a
-
-
-
-Stokes and Good [Page 6]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
- response field containing an error code.
-
- For a consumer-initiated session, the response field of the
- StartFramedProtocolResponse extended respons indicates that the
- supplier is or is not prepared to send a set of updates to the
- consumer. If the supplier is prepared to send updates to the
- consumer, it sends a response field containing a success code. If the
- supplier is unwilling or unable to send updates to the consumer, it
- sends a response field containing an error code. In both cases, the
- supplier disconnects from the consumer. If the supplier sent a
- success code to the consumer, it opens a connection to the consumer
- as soon as possible and initiates a supplier-initiated replication
- session.
-
- The StartFramedProtocolResponse extended operation is defined in
- [FRAMING]. When responding to a StartFramedProtocolRequest signaling
- the beginning of an LDUP replication session, the response field of
- the StartFramedProtocolResponse is set to the following:
-
- StartFramedProtocolResponseValue ::= SEQUENCE {
- responseCode LDUPResponseCode,
- replicaUpdateVector Attribute,
- }
-
- LDUPResponseCodes are defined in section 8.
-
- The replicaUpdateVector contains a replica update vector, as defined
- in [INFOMOD]. The update vector is encoded as a normal LDAP
- attribute, defined in [LDAPv3].
-
-
-5.3 ReplicationUpdate Extended Operation
-
-The ReplicationUpdate extended operation carries a set of replication
-primitives that represent the desired final state of a single entry.
-
-The ReplicationUpdate extended operation is defined as follows:
-
-An LDAPv3 Extended Request is defined in [LDAPv3] as follows:
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID
- requestValue [1] OCTET STRING OPTIONAL
- }
-
-The requestName of the ReplicationUpdate must be the OID
-2.16.840.1.113719.1.142.100.3.
-
-
-
-
-Stokes and Good [Page 7]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
-The requestValue of the ReplicationUpdate must be set to the BER-
-encoding of the following:
-
- requestValue ::= SEQUENCE {
- uniqueID UniqueIdentifier,
- updates SET OF ReplicationPrimitive
- }
-
-5.3.1 UniqueIdentifier
-
- The Distinguished Name of an entry may be changed (by renaming the
- entry), or the entry may not have a distinguished name (if it was
- deleted). The Unique Identifier provides an immutable name,
- independent of the current name or deletion status, for an entry. All
- replicated operations address entries by their Unique Identifiers.
-
- UniqueIdentifier ::= LDAPString
-
-
-5.3.2 ReplicationPrimitive
-
- A ReplicationPrimitive carries a single assertion about the the final
- state of an entry, attribute, or attribute value. There are seven
- types of primitives.
-
- ReplicationPrimitive ::= CHOICE {
- addEntryPrimitive AddEntryPrimitive,
- moveEntryPrimitive MoveEntryPrimitive,
- renameEntryPrimitive RenameEntryPrimitive,
- removeEntryPrimitive RemoveEntryPrimitive,
- addAttributeValuePrimitive AddAttributeValuePrimitive,
- removeAttributeValuePrimitive RemoveAttributeValuePrimitive,
- removeAttributePrimitive RemoveAttributePrimitive
- }
-
- Each primitive applies to the entry referred to by the
- uniqueIdentifier in the enclosing ReplicationUpdate extended
- operation.
-
- Each primitive carries an lLDAPChangeSequenceNumber that is used by
- the consumer server to correctly resolve update conflicts. [URP]
- describes the update reconciliation procedures.
-
-5.3.2.1 AddEntryPrimitive
-
- The AddEntryPrimitive is used to add a new entry.
-
- AddEntryPrimitive ::= [APPLICATION 0] SEQUENCE {
-
-
-
-Stokes and Good [Page 8]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
- csn lDAPChangeSequenceNumber,
- superior UniqueIdentifier,
- rdn RelativeLDAPDN
- }
-
- Parameters of the AddEntryPrimitive are:
-
- - csn: The change sequence number of the primitive.
-
- - superior: The unique identifier of the superior (parent) entry.
-
- - rdn: The relative distinguished name of the new entry.
-
-5.3.2.2 MoveEntryPrimitive
-
- The MoveEntryPrimitive is used to move an entry to a new location in
- the DIT.
-
- MoveEntryPrimitive ::= [APPLICATION 1] SEQUENCE {
- csn lDAPChangeSequenceNumber,
- superior UniqueIdentifier
- }
-
- Parameters of the MoveEntryPrimitive are:
-
- - csn: The change sequence number of the primitive.
-
- - superior: The unique identifier of the new superior (parent)
- entry.
-
-5.3.2.3 RenameEntryPrimitive
-
- The RenameEntryPrimitive is used to change the RDN of an entry.
-
- RenameEntryPrimitive ::= [APPLICATION 2] SEQUENCE {
- csn lDAPChangeSequenceNumber,
- rdn RelativeLDAPDN
- }
-
- Parameters of the RenameEntryPrimitive are:
-
- - csn: The change sequence number of the primitive.
-
- - rdn: The new relative distinguished name of the entry.
-
-5.3.2.4 RemoveEntryPrimitive
-
- The RemoveEntryPrimitive is used to delete an entry from the DIT.
-
-
-
-Stokes and Good [Page 9]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
- RemoveEntryPrimitive ::= [APPLICATION 3] SEQUENCE {
- csn lDAPChangeSequenceNumber
- }
-
- Parameters of the RemoveEntryPrimitive are:
-
- - csn: The change sequence number of the primitive.
-
-5.3.2.5 AddAttributeValuePrimitive
-
- The AddAttributeValuePrimitive is use to add a new attribute value to
- an entry.
-
- AddAttributeValuePrimitive ::= [APPLICATION 4] SEQUENCE {
- csn lDAPChangeSequenceNumber,
- type AttributeDescription,
- value AttributeValue
- }
-
- Parameters of the AddAttributeValuePrimitive are:
-
- - csn: The change sequence number of the primitive.
-
- - type: The type of the attribute being added.
-
- - value: The value being added. Multiple values are not permitted.
-
-5.3.2.6 RemoveAttributeValuePrimitive
-
- The RemoveAttributeValuePrimitive is used to remove a particular
- attribute value from an entry.
-
- RemoveAttributeValuePrimitive ::= [APPLICATION 5] SEQUENCE {
- csn lDAPChangeSequenceNumber,
- type AttributeDescription,
- value AttributeValue
- }
-
- Parameters of the RemoveAttributeValuePrimitive are:
-
- - csn: The change sequence number of the primitive.
-
- - type: The type of the attribute being removed.
-
- - value: The value being removed. Multiple values are not
- permitted.
-
-5.3.2.7 RemoveAttributePrimitive
-
-
-
-Stokes and Good [Page 10]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
- The RemoveAttributePrimitive is used to remove an attribute and all
- its values from an entry.
-
- RemoveAttributePrimitive ::= [APPLICATION 6] SEQUENCE {
- csn lDAPChangeSequenceNumber,
- type AttributeDescription
- }
-
- Parameters of the RemoveAttributePrimitive are:
-
- - csn: The change sequence number of the primitive.
-
- - type: The type of the attribute being removed.
-
-
-5.4 EndFramedProtocolRequest Extended Operation
-
- The EndFramedProtocolRequest extended operation is sent from the
- replication supplier to the replication consumer to indicate the end
- of the sequence of replication updates. In the event that the
- supplier is sending a total update, the requestValue field of the
- EndFramedProtocolRequest extended operation contains a replica update
- vector. The consumer server must replace its replica update vector,
- if present, with the one provided by the supplier. In the event that
- the supplier is sending an incremental update, the replica update
- vector is absent.
-
- The EndFramedProtocolRequest extended operation is defined in
- [FRAMING]. When used to signal the termination of an LDUP incremental
- or total update session, the requestValue field of the
- EndFramedProtocolRequest is set to the following:
-
- requestValue ::= SEQUENCE {
- replicaUpdateVector Attribute OPTIONAL,
- returnConsumerUpdateVector BOOLEAN
- }
-
- If returnConsumerUpdateVector is TRUE, the consumer server must
- return its current update vector to the supplier in the response
- field of the EndFramedProtocolResponse extended response (defined in
- section 5.5). Typically, the supplier will request the consumer's
- update vector for read-only replicas, since the read-only replica
- will never initiate a replication session, and will therefore never
- have the opportunity to provide its update vector to other servers.
-
-
-5.5 EndFramedProtocolResponse Extended Operation
-
-
-
-
-Stokes and Good [Page 11]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
- The EndFramedProtocolResponse extended operation is defined in
- [FRAMING]. It is used to respond to a EndFramedProtocolRequest. The
- response field of the EndFramedProtocolResponse extended operation is
- set to the following:
-
- response ::= SEQUENCE {
- replicaUpdateVector Attribute OPTIONAL
- }
-
- The replicaUpdateVector contains the consumer's current replica
- update vector, and is optional. The consumer server should only send
- the replicaUpdateVector if requested by the supplier server in the
- EndReplicationRequest extended operation.
-
-5.6 ReplicationUpdateResponse Extended Operation
-
-The ReplicationUpdateResponse extended operation is sent, unsolicited,
-by a consumer to a supplier when the consumer wishes the supplier to
-stop sending updates.
-
-An LDAPv3 extended response is defined in [LDAPv3] as follows:
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS of LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL
- }
-
-The responseName of the ReplicationUpdateResponse must be the OID [OID
-to be assigned].
-
-The response field of the ReplicationUpdateResponse must be set to the
-BER-encoding of the following:
-
- response ::= SEQUENCE {
- replicaUpdateVector Attribute OPTIONAL
- abortUpdate BOOLEAN
- }
-
-The parameters of the ReplicationUpdateResponse are:
-
-- An optional update vector. If sent, this indicates that the consumer
-has committed all updates whose CSNs are covered by the transmitted
-update vector [see glossary for a definition of "covered by"]. - An
-optional AbortUpdate boolean flag. If a supplier receives a
-ReplicationUpdateResponse from a consumer with the AbortUpdate flag set
-to true, the supplier server MUST immediately cease sending updates and
-terminate its connection to the consumer.
-
-
-
-Stokes and Good [Page 12]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
-6. Semantics of Full and Incremental Update protocols
-
-[To be written]
-
-7. Summary of response codes
-
-The following list describes the response codes that may be included in
-the StartFramedProtocolResponse, EndFramedProtocolResponse, and
-ReplicationUpdateResponse extended operations.
-
- LDUPResponseCode ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- insufficientAccessRights (50),
- busy (51),
- excessiveCSNSkew (200),
-
- other (80) },
- errorMessage LDAPString }
-
-The meanings of the response codes are as follows:
-
- success..................... As defined in [LDAPv3].
- operationsError............. As defined in [LDAPv3].
- protocolError............... As defined in [LDAPv3].
- insufficientAccessRights.... Access denied. The identity that the
- initiator provided in the bind request does
- not have sufficient privileges to perform
- the operation.
- busy........................ The replica is temporarily unable to accept
- updates.
- excessiveCSNSkew............ The consumer server has detected that the
- CSNs being generated by the supplier are
- too small (perhaps because the supplier's
- clock was set back). Updates from the
- supplier will not be applied.
- other....................... Some other error occurred.
-
-8. Implications for log-based and state-based servers
-
-To be written, or possibly incorporated into [ARCHITECTURE].
-
-9. Replication of access control and schema information
-
-To be written, or possibly incorporated into [ARCHITECTURE].
-
-
-
-
-Stokes and Good [Page 13]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
-10. Security Considerations
-
-To be written.
-
-11. Glossary of Terms
-
- Covered by: We say that a CSN is "covered by" an update vector if and
- only if the CSN is less than or equal to the component of the update
- vector corresponding to the replica ID in the CSN. In other words,
- given a CSN with components <t,S,r,s> and an update vector with CSNs
- <t0,S0,r0,s0>,<t1,S1,r1,s1>...<tn,Sn,Rn,sn>, then the CSN is covered
- by the RUV if and only if one of the following holds for some value
- i:
- a) r = ri and t < ti
- b) r = ri and t = ti and S < Si
- c) r = ri and t = ti and S = Si and s < si
-
-
-12. Acknowledgments
-
-To be written.
-
-13. References
-
-
-[ARCHITECTURE]
- J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architec-
- ture", Internet-Draft, draft-ietf-ldup-model-02.txt, October 1999.
-
-
-[FRAMING]
- E. Stokes, G. Good, "Extended Operations for Framing LDAP Bulk
- Update Operations", Internet-Draft, draft-ietf-ldup-framing-00.txt,
- March 2000.
-
-
-[INFOMOD]
- E. Reed, "LDAP Replication Information Model", Internet-Draft,
- draft-reed-ldup-infomod-00.txt, June 1999.
-
-
-[KEYWORDS]
- S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev-
- els", Harvard University, RFC 2119, March 1997.
-
-
-[LDAPv3]
- M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
-
-
-
-Stokes and Good [Page 14]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
- (v3)", RFC 2251, December 1997.
-
-
-[REQ]R. Weiser, E. Stokes, "LDAP V3 Replication Requirements",
- Internet-Draft, draft-ietf-ldup-replica-req-02.txt, October 1999.
-
-
-[URP]S. Legg, A. Payne, "LDUP Update Reconciliation Procedures",
- Internet-Draft, draft-ietf-ldup-urp-02.txt, October 1999.
-
-14. Author's Addresses
-
- Ellen Stokes
- IBM
- 11400 Burnet Rd
- Austin, TX 78758
- USA
- EMail: stokes@austin.ibm.com
- phone: +1 512 838 3725
- fax: +1 512 838 0156
-
- Gordon Good
- Netscape Communications Corp.
- 501 E. Middlefield Rd.
- Mailstop MV068
- Mountain View, CA 94043
- USA
- EMail: ggood@netscape.com
- Phone: +1 650 937-3825
-
- 15. Document Revision History
- (This section will be removed prior to this document's publication
- as a proposed standard)
-
- Differences between draft-ietf-ldup-protocol-00.txt and
- draft-ietf-ldup-protocol-01.txt:
-
- 1) The document was reworked to use the ldup framed protocol
- draft [FRAMING].
-
-
-Appendix A - Complete ASN.1 Definition
-
-To be written.
-
-Full Copyright Statement
-
-Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-
-
-Stokes and Good [Page 15]
-\f
-Internet-Draft LDUP Workgroup March 10 2000
-
-
-This document and translations of it may be copied and furnished to oth-
-ers, and derivative works that comment on or otherwise explain it or
-assist in its implementation may be prepared, copied, published and dis-
-tributed, in whole or in part, without restriction of any kind, provided
-that the above copyright notice and this paragraph are included on all
-such copies and derivative works. However, this document itself may not
-be modified in any way, such as by removing the copyright notice or
-references to the Internet Society or other Internet organizations,
-except as needed for the purpose of developing Internet standards in
-which case the procedures for copyrights defined in the Internet Stan-
-dards process must be followed, or as required to translate it into
-languages other than English.
-
-The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-This document and the information contained herein is provided on an "AS
-IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
-FORCE DISCLAIMS 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 FIT-
-NESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stokes and Good [Page 16]
+++ /dev/null
- INTERNET-DRAFT Russel F. Weiser
- Informational Draft Digital Signature Trust Co.
- Expires 21 April 2000 Ellen Stokes
- IBM
- 21 October 1999
-
-
-
-
-
- LDAP V3 Replication Requirements
-
- <draft-ietf-ldup-replica-req-02.txt>
-
-
-
- Status of this Memo
-
-
-
- This document is am Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other documents
- at any time. It is inappropriate to use Internet-Drafts as
- reference material or to cite them other than as ``work in
- progress.''
-
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/lid-abstracts.txt
-
-
- The list of Internet-Drafts Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-
-
-
- Abstract
-
-
- This document discusses the fundamental requirements for replication
- of data accessible via the LDAPv3 [RFC2251] protocol. It is intended
- to be a gathering place for general replication requirements needed
- to provide interoperability between informational directories.
-
-
- The key words MUST, MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
- Weiser & Stokes 21 April 2000 [PAGE 1]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
-
-
- Table of Contents
-
-
- 1.Introduction.....................................................3
- 2. Terminology.....................................................3
- 3. Objective.......................................................5
- 4. Applicability Statement.........................................5
- 5. Replication Model..............................................10
- 6. Replication Protocol...........................................12
- 7. Schema.........................................................13
- 8. Administration and Management Considerations...................13
- 9. Acknowledgement................................................14
- 10. References....................................................15
- 11. Author's Address..............................................15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Weiser & Stokes 21 April 2000 [Page 2]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
-
-
-
-
- 1. Introduction
-
-
- The ability to distribute directory information throughout the
- network provides a two fold benefit to the network: (1) increasing
- the reliability of the directory through fault tolerance, and
- (2) brings the directory content closer to the clients using the
- data. LDAPÆs acceptance as an access protocol for directory
- information is driving the need to distribute LDAP directory content
- among servers within enterprise and Internet. Currently LDAP does
- not define a replication mechanism and only generally mentions LDAP
- shadow servers (see [RFC2251] and [Changelog]) in passing. The
- requirements for replication are critical to the successful
- deployment and acceptance of LDAP in the market place.
-
-
-
- 2. Terminology
-
-
- For the purposes of this document, the following terminology
- definitions are used:
-
-
- Area of replication - A whole or portion of a directory tree(DIT)
- making up a distinct unit of data to be replicated. This may also be
- known as "unit of replication".
-
- Atomic operation - The ability to treat and contain several updates
- or attribute changes as a single operation for replication purposes
- to guarantee that the several updates or attribute changes are
- propagated to a replica as a single unit.
-
- Authoritative Master Replica - The Primary updateable replica of the
- replicated information.
-
-
- Conflict resolution - Deterministic procedures within replication
- protocols, utilized to resolve change information conflicts that may
- arise due to conflicting changes affecting a directory entry.
-
-
- Fractional replication - The capability to replicate a subset of
- attributes of any given entry.
-
- Incremental Update - The process of updating a replica, or copy, of
- a naming context, by updating only those fields or objects which
- have changed.
-
-
- Master Slave, or Single Master Replication - Replication model that
- assumes only one server, the master, allows write access to the
- replicated data. Note that Master-Slave replication can be
- considered a proper subset of multi-master replication.
-
-
-
- Weiser & Stokes 21 April 2000 [Page 3]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
-
-
- Multi-Master Replication - A replication model where entries can be
- written and updated on any of several updateable replica copies
- without requiring communication with other updateable replicas
- before the write or update is performed.
-
-
- Naming Context - Suffix of a Sub-tree. A sub-tree of entries held in
- a single server [X.500].
-
-
- One-way Replication - The process of synchronization in a single
- direction where the authoritative source information is provided to
- a replica.
-
-
- Partial Replication - The capability to replicate some subset of
- entries in a naming context.
-
-
- Propagation behavior - The general behavior of the actual
- synchronization process between a consumer and a provider of
- replication information.
-
- Read-only Replica - A read-only copy of a replicated directory. A
- read-only replica is assumed to be a slave replica of master slave
- or single master replication definition.
-
-
- Replica - A single instance of a whole or portion of the Directory
- tree (DIT) as defined by area of replication.
-
-
- Replica Ring - A set of servers, which hold in common the same DIT
- information as, defined by ôArea of replicationö. These servers may
- be managed under a single replication agreement that handles all
- members of the set of servers as a group.
-
-
- Replica Cycle - When a change or groups of changes need to be
- propagated to the other member of a replica ring. The process of
- contacting a replica member would be considered the beginning of a
- replication cycle; the termination of communications with a replica
- is the end of the cycle whether its due to an error or successful
- exchange of update records.
-
-
- Replication - The process of copying portions of naming context
- information and content between multiple LDAP servers, such that
- certain predefined portions of the information are available from
- different servers. Replication can occur between either homogeneous
- implementations across heterogeneous platforms (operating systems)
- or heterogeneous implementations supporting identical replication
- across heterogeneous platforms (operating systems).
-
-
- Sparse Replica - A incomplete copy of a sub-tree which maybe
- inclusive with updateable, or Read-only. See Partial replication and
-
-
-
-
- Weiser & Stokes 21 April 2000 [Page 4]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
- Fractional replication.
-
-
- Topology - Refers to the shape of the directed graph describing the
- relationships between replicas, as in the replicated directory
- topology.
-
-
- Two-way Replication - The process of synchronization where change
- information may flow bi-directionally between two replica.
-
- Update Propagation - Protocol-based process by which directory
- replicas are reconciled.
-
-
- Updateable Replica - A Non-authoritative read-writeable copy of the
- replicated information. Such that during conflict resolution a
- authoritative master takes precedents in resolving conflicts.
-
-
-
- 3. Objective
-
-
- The major objective is to provide an interoperable LDAP V3 directory
- synchronization protocol which is simple, highly efficient and
- flexible enough to support both multi-master and master-slave
- replication operations to meet the needs of both the internet and
- enterprise environments.
-
-
- 4. Applicability Statement
-
-
- Generally replication can be characterized by looking at data
- consistency models across existing technologies. This may provide
- insight to LDAP v3 replication requirements. The following is a
- brief examination of the following data models.
-
-
- Model 1: Tight Consistency -- Includes environments where all
- replicas must always contain exactly the same directory content. Two
- phase commit transaction models may be used to preserve transaction
- consistency.
-
-
- Model 2: Eventual Consistency or Transient Consistency -- Includes
- X.500 Directories, Bayou [XEROX], and NDS (Novell Directory
- Services) names service where definite knowledge of the global
- replica topology is provided through predetermined replication
- agreements. Such that every update propagates to every replica that
- it can reach via a path of stepwise eventual connectivity.
- Transaction consistency is preserved for transactions directed at
- the master server in X.500 implementations. NDS additionally
- provides deterministic consistency over time to all replicas due to
- its inherent replication policies.
-
-
-
-
- Weiser & Stokes 21 April 2000 [Page 5]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
- Model 3: Limited Effort Eventual Consistency -- Includes Xerox
- Clearinghouse [XEROX] that provides a statistical probability of
- convergence with global knowledge of replica topology. Similar to
- "Eventual Consistency", except where replicas may purge updates
- therefore dropping propagation changes when some replica time
- boundary is exceeded, thus leaving some changes replicated to a
- portion of the replica topology. Transactional consistency is not
- preserved, though some weaker constraints on consistency are
- available.
-
- Model 4: Loosest Consistency -- Includes opportunistic or simple
- cache where information is provided from the cache until stale.
-
-
- Model 5: Ad hoc -- A copy of a date store where no follow up checks
- are made for the accuracy/freshness of the data.
-
-
- Consistency models 2, and 3 involve the use of prearranged
- replication agreements or "Predefined Replication Agreements"
- between cooperating servers. The complexity of Model 1's use of 2-
- phase commit adds additional overhead that should not considered at
- this time. Models 4 and 5 involve unregistered replicas which
- "pull" updates from another directory server without that server's
- knowledge. These models can be considered to violate a directory's
- security policies. Therefore models 1, 4, and 5 are declared to be
- out of scope of this working group.
-
-
- So through further review of these consistency models two
- application areas can then be derived with even further
- characterizations of the data types usages.
-
- Eventual Consistency or Transient Consistency (Model 2) - This model
- provides policy configuration through security management
- parameters; the data is more dynamic and utilizes dynamic address
- information.
-
- Limited Effort Eventual Consistency (Model 3) - This model matches a
- white-pages environment which contains fairly static data and
- address information. This model mainly replicates message
- attributes.
-
- Therefore it is believed an LDAP replication should be flexible
- enough to cover the above range of capabilities. The generalized use
- of LDUP replication environment is to provide for the distribution
- of LDAP directory information in order to improve accessibility and
- consistency of the information held by the directory.
-
-
-
- 4.1 Replication Scenarios
-
-
-
-
-
- Weiser & Stokes 21 April 2000 [Page 6]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
- The following directory deployment examples are intended to
- substantiate and validate our replication requirements. It is
- assumed in all cases that directory implementations from different
- vendors are involved.
-
- 4.1.1 Extranet Example
-
-
- A company has a trading partner to whom it wishes to provide
- directory information. This information may be as simple as a
- corporate telephone directory, or as complex as an extranet work
- flow application. For performance reasons the company may wish to
- have a replica of its directory within the Partner Company, rather
- than simply exposed beyond its firewall.
-
-
- The requirements, which follow from this scenario, are:
-
- - One-way replication, single mastered.
- - Authentication of clients.
- - Common access control and access control identification.
- - Secure transmission of updates.
- - Selective attribute replication (Fractional Replication), so that
- only partial entries can be replicated.
-
-
-
- 4.1.2 Consolidation Example
-
-
- Company A acquires company B. In the transition period, whilst the
- organizations are merged, both directory services must coexist.
- Company A may wish to attach company B's directory to its own.
-
- The requirements, which follow from this scenario, are:
-
- - Multi-Master replication.
- - Common access control model. Access control model identification.
- - Secure transmission of updates.
- - Replication between DITs with potentially differing schema.
-
-
- 4.1.3 Replication Heterogeneous Deployment Example
-
- An organization may deliberately deploy multiple directory services
- within their enterprise to employ the differing benefits of each
- service. In this case multi-master replication will be required to
- ensure that the multiple updateable replicas of the DIT are
- synchronized. Some vendors may provide directory clients, which are
- tied to their own directory service.
-
-
- The requirements, which follow from this scenario, are:
-
-
- - Multi-Master replication
-
-
-
- Weiser & Stokes 21 April 2000 [Page 7]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
- - Common access control model and Access control model
- identification.
- - Secure transmission of updates.
- - Replication between DITs with potentially differing schemas.
-
- 4.1.4 Shared Name Space Example
-
-
- Two organizations may choose to cooperate on some venture and need a
- shared name space to manage their operation. Both organizations
- will require administrative rights over the shared name space.
-
- The requirements, which follow from this scenario, are:
-
- - Multi-Master replication.
- - Common access control model and Access control model
- identification.
- - Secure transmission of updates.
-
- 4.1.5 Supplier Initiated Replication
-
- A single master environment, which maintains a number of replicas of
- the DIT by pushing changes, based on a defined schedule.
-
-
- The requirements, which follow from this scenario, are:
-
- - Single-master environment.
- - Supplier-initiated replication.
- - Secure transmission of updates.
-
-
- 4.1.6 Consumer Initiated Replication
-
-
- Again a single mastered replication topology, but the replica
- initiates the replication exchange rather than the master. An
- example of this is a replica that resides on a laptop computer that
- may run disconnected for a period of time.
-
-
- The requirements, which follow from this scenario, are:
-
- - Single-master environment.
- - Consumer initiated replication.
- - Open scheduling (anytime).
-
- 4.1.7 Prioritized attribute replication
-
-
- The password attribute can provide an example of the requirement for
- prioritized attribute replication. A user is working in Utah and the
- administrator resides in California. The user has forgotten his
- password. So the user calls or emails the administrator to request a
- new password. The administrator provides the updated password (a
- change). Policy states that this attribute is critical and must be
-
-
-
- Weiser & Stokes 21 April 2000 [Page 8]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
- available to the user for login immediately (e.g. shortly) after the
- administrator changed it. Replication needs to occur immediately for
- critical attributes/objects.
-
-
- The requirements, which follow from this scenario, are:
-
- - Incremental replication of changes.
- - Automatic replication on change of certain attributes.
- - Replicate based on time/attribute semantics.
-
- 4.1.8 Bandwidth issues
-
-
- The replication of Server (A) R/W replica (a) in Katmandu is handled
- via a dial up phone link to Paris where server (B) R/W replica of
- (a) resides. Server (C) R/W replica of(a) is connected by a T1
- connection to server (B). Each connection has a different
- performance characteristic.
-
-
- The requirements, which follow from this scenario, are:
-
- - Minimize repetitive updates when replicating from multiple
- replication paths.
- - Incremental replication of changes.
- - Provide replication cycles to delay and/or retry when connections
- can not be reached.
- - Allowances for consumer initiated or supplier initiated
- replication.
-
-
- 4.1.9 Interoperable Administration and Management
-
- The administrator with administrative authority of the corporate
- directory which is replicated by numerous geographically dispersed
- LDAP servers from different vendors notices that the replication
- process is not completing correctly as the change log is continuing
- to grow and/or error message informs him. The administrator uses his
- $19.95 RepCo LDAP directory replication diagnostics tools to look at
- Root DSE replica knowledge on server 17 and determines that server
- 42 made by LDAPÆRUS Inc. is not replicating properly due to an
- Object conflict. Using his Repco Remote repair tools he connects to
- server 42 and resolves the conflict on the remote server.
-
-
- The requirements, which follow from this scenario, are:
-
- - Provides replication audit history.
- - Provisions for managing conflict resolution.
- - Provide LDAP access to predetermined agreements, topology and
- policy attributes.
- - Provide operations for comparing replicaÆs content for validity.
- - Provide LDAP access to status and audit information.
-
-
-
-
- Weiser & Stokes 21 April 2000 [Page 9]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
- 4.1.10 Enterprise Directory Replication Mesh
-
-
- A Corporation builds a mesh of directory servers within the
- enterprise utilizing LDAP servers from various vendors. Five servers
- are holding the same area of replication. The predetermined
- replication agreement(s) for the enterprise mesh are under a single
- management, and the security domain allows a single predetermined
- replication agreement to manage the 5 servers replication.
-
-
- The requirements, which follow from this scenario, are:
-
- - Predefined replication agreements that manage more than a single
- area of replication that is held on numerous servers.
- - Common support of replication management knowledge across vendor
- implementation.
- - Rescheduling and continuation of a replication cycle when one
- server in a replica ring is busy and/or unavailable.
-
- 5. Replication Model
-
-
- 5.1 LDAP Replication MUST be allowed to span different vendors
- directory services in order to provide interoperability.
-
- 5.2 All replicas MUST eventually be updated with the changed
- information, if specified by the replication policy.
-
-
- 5.3 Replication schedules MUST be configurable to allow for
- periodic replication, with the replication period determined by
- administrator of the replicated system.
-
-
- 5.4 Replication Model MUST enable replication cycle to be initiated
- on change or based on the number of pending changes.
-
- 5.5 The replication model MUST allow for administrative
- initiation of replication cycle for any replica that may have
- just come back online or was unavailable during previous
- replication cycles.
-
- 5.6 The replication model MUST support both master-slave and
- authoritative multi-updateable replica relationships.
-
-
- 5.7 All replicated information between the master database and its
- replica databases MUST be identical including all non-user
- modify operational attributes such as time stamps. Note this
- does not imply that the entire database is identical from
- replica to replica, but that the subset of data, chosen to
- replicate is identical from replica to replica. Some
- operational attributes may be dynamically evaluated; these
- attributes will not necessarily appear to be identical.
-
-
-
-
-
-
- Weiser & Stokes 21 April 2000 [Page 10]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
- 5.8 In distributed multi-vendor environment, LDAP replication MUST
- NOT require all copies of the replicated information be
- complete copies of the replicated object.
-
-
- 5.9 LDAP replication MUST encompass common schema objects and
- attributes, access control, and name space information.
-
-
- 5.10 Sub-tree Replication MUST be defined to allow for greater
- flexibility in replication topologies of the DIT as defined by
- the area of replication called partial replication.
-
-
- 5.11 Replication of critical values MUST be synchronized and have
- priority over non-critical values. An example of a critical
- value might be a password or certificate value.
-
- 5.12 Replication activities MUST occur within the context of a
- predefined replication agreement that addresses proper
- knowledge of access requirements and credentials between the
- synchronizing directories. Currently X.525 DISP [X.525]
- discusses this as a shadowing agreement including such
- information as unit of replication, update mode, and access
- point defining many of the policies between the master and a
- replica.
-
-
- 5.13 The acceptance and usage of the Internet requires that LDAP
- replication be available across disparate vendor directory
- services.
-
-
- 5.14 LDAP replication MUST provide scalability to both enterprise
- and Internet environments, e.g. an LDAP server may provide
- replication services to replicas within an enterprise as well
- as across the Internet.
-
-
- 5.15 The replication model MUST define deterministic policy such
- that replication cycle startup time conflicts between two or
- more competing master replicas may be resolved
- programmatically. An example might be automatic submission and
- rescheduling by one of the masters. In such a case, these
- replication "conflicts" MUST be resolved by the replication
- policy.
-
-
- 5.16 Any replication capable LDAP server MUST allow replication
- where the 2 replicating servers agree they can replicate. This
- may be accomplished through administrative agreements assuming
- compatible access control model and common schema are provided.
-
-
- 5.17 The replication model MUST be able to handle convergence and
- resurrection of attributes and objects. This is a consequence
- of delete and move with respect to the replication process.
-
-
-
-
- Weiser & Stokes 21 April 2000 [Page 11]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
- 5.18 It is not realistic to assume that all vendors have cooperating
- schemas, but that replication may be allowed between diverse
- schema. The Model MAY allow for replication between divergent
- schema of objects.
-
-
- 6. Replication Protocol
-
-
- 6.1 The act of replication SHOULD have minimal impact on both the
- system and network performance.
-
- 6.2 The replica synchronization SHOULD be handled in such a manner
- as to not saturate network with repetitive entry replication
- from multiple synchronization providers points.
-
-
- 6.3 Replication MUST only be allowed after the authentication and
- verification of authorization of both the replica and the
- source directory.
-
-
- 6.4 The transport for LDAP synchronization MUST allow for the
- integrity and confidentiality of each replicated server.
-
-
- 6.5 Replicated data MUST be transferable in a secure manner.
-
-
- 6.6 Replication protocol MUST provide for recovery and rescheduling
- of a replication cycle due to a replication initiation
- conflicts (e.g. consumer busy replicating with other servers)
- and or loss of connection(e.g. supplier cannot reach a
- replica). The replication protocol MUST include restarting at
- the last acknowledged update prior to interruption rather than
- re-sending updates it had already sent to a consuming replica.
-
-
- 6.7 LDAP replication MUST allow for full update to facilitate
- replica initialization and reset loading utilizing a
- standardized format such as LDIF [LDIF] format.
-
- 6.8 The replication standard SHOULD NOT limit the size of a
- replica. The area of replication is defined to be a whole or
- portion of a DIT, also allowing a portion of a naming context
- to be replicated. Incremental replication SHOULD be allowed.
-
- 6.9 The replication agreements MUST accommodate multiple servers
- receiving the same replica under a single predefined agreement.
-
-
- 6.10 The replication protocol MUST allow either a master or replica
- to initiate the replication process.
-
-
- 6.11 Additionally the initiator MUST be allowed to determine
- whether it will become a consumer or supplier during the
- synchronization startup process. This would allow a replica to
-
-
-
- Weiser & Stokes 21 April 2000 [Page 12]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
- be periodically connected and synchronized from remote sites at
- the local administrator's discretion.
-
-
- 6.12 Multiple LDAP changes to a single server: If transactional
- consistency is propagated during replication, then multiple LDAP
- changes submitted to a single server SHOULD BE treated as a
- single 'atomic unit of work'.
-
-
- 6.13 An LDAP Replication Standard SHOULD NOT limit the transaction
- rate of a replication session.
-
-
- 6.14 Entry change information MUST be purged or discarded in a
- timely manner when change information becomes outdated due to
- propagated to all replica members.
-
-
-
-
- 7. Schema
-
-
- 7.1 Replica knowledge MUST be provided as DSE attributes.
-
- 7.2 The Replication Protocol documents MUST define standard schema
- for representing replication agreements, and MUST define the
- semantics associated with modifying the attributes of
- replication agreements. The documents MUST also define a
- standard method for determining the location of these
- agreements accessible utilizing LDAP.
-
-
- 7.3 The Replication Protocol documents MUST define standard schema
- for publishing state information about a given replica, and
- MUST define a standard method for determining the location of
- this information.
-
-
- 7.4 A location independent management point MUST be defined to
- provide authorized administrators with well known access to the
- replication policies, regardless of network location.
-
-
- 7.5 Replication agreements of all servers containing replicated
- information MUST be accessible via LDAP.
-
-
- 7.6 All objects MUST be uniquely identifiable throughout the object
- lifetime .
-
-
-
-
- 8. Administration and Management Considerations
-
-
-
- 8.1 Replication policies MUST allow replication of changed
- information to be administratively postponed to a more
-
-
-
- Weiser & Stokes 21 April 2000 [Page 13]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
- convenient period.
-
-
- 8.2 Allowance for non-scheduled replication of a replica MUST be
- provided upon request such that the replica server has been
- down or unconnected for a period of time.
-
-
- 8.3 Each copy of a replica MUST maintain audit history information
- of which servers it has replicated with and which servers have
- replicated with it.
-
- 8.4 A replica MUST store conflicted versions of the replicated
- object to allow optional human review and intervention.
-
-
- 8.5 Access to replication predetermined agreements, topologies, and
- policies attributes MUST be provided through LDAP access.
-
-
- 8.6 The capability to check the differences between two replicas
- for the same information SHOULD be provided for. This should
- entail a client invoking an operation at some server, which
- causes that server to extract the contents from some other
- server it has a replication agreement with and report the
- differences back to the client as the result.
-
-
- 8.7 Authenticated access SHOULD be provided so that Administrative
- LDAP clients may query a server for the current state and
- replication history for each replica that the server maintains
- replication agreements with.
-
-
- 8.8 The ability to view replication conflicts, and override the
- resolution derived by the replication policy MUST be provided.
-
-
- 8.9 The deletion of sensitive data MUST be handled in an orderly
- manner so that at no time will that data be available without
- proper access control. That is, access control information
- (ACI) associated with sensitive data must be deleted after or
- simultaneously with the delete of the sensitive data. Likewise,
- when adding sensitive data, ACI MUST be added first or
- simultaneously with the addition of that data.
-
-
-
-
- 9. Acknowledgement
-
-
- This document is based on input from IETF members interested in LDUP
- Replication.
-
-
-
-
-
-
-
-
- Weiser & Stokes 21 April 2000 [Page 14]\f
-
-
- INTERNET-DRAFT LDAP Replication Requirements 21 October 1999
-
-
-
-
-
- 10. References
-
-
-
- [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access
- Protocal", RFC 2251.
-
-
- [RFC2119] S.Bradner, " Key words for use in RFCs to indicate
- Requirement Levels", RFC 2119.
-
-
- [LDIF] Gordon Good, "The LDAP Data Interchange Format (LDIF)",
- Internet draft, draft-ietf-asid-ldif-00.txt, November 1996.
-
-
- [Changelog] Gordon Good, "Definitions of an Object Class to Hold
- LDAP Change records", Internet Draft, draft-ietf-asid-changelog-
- 00.txt, November 1996.
-
-
- [X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993,
- Information Technology - Open Systems Interconnection - The
- Directory: Models
-
- [XEROX] Hauser, C. "Managing update conflicts in Bayou, a weakly
- connected replicated storage system". Palo Alto, CA: Xerox PARC,
- Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04]
-
-
-
- 11. Author's Address
-
-
- Russel F. Weiser
- Digital Signature Trust Co.
- One South Main Street
- Salt Lake City, Utah 84111
- USA
-
-
- E-mail: rweiser@digsigtrust.com
- Telephone: +1-801-983-4415
- Fax +1-801-983-4408
-
-
-
- Ellen J. Stokes
- IBM
- 11400 Burnet Rd.
- Austin, Texas 78758
- USA
-
- E-mail: stokes@austin.ibm.com
- Telephone: +1-512-838-3725
- Fax: +1-512-838-0156
-
-
-
-
-
- Weiser & Stokes 21 April 2000 [Page 15]\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT
-draft-ietf-ldup-subentry-03.txt
- Ed Reed
- Reed-Matthews, Inc.
- July 13, 2000
-
-LDAP Subentry Schema
-
-
-1. Status of this Memo
-
-This document is an Internet-Draft and is in full
-conformance with all provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet
-Engineering Task Force (IETF), its areas, and its working
-groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of
-six months and may be updated, replaced, or obsoleted by
-other documents at any time. It is inappropriate to use
-Internet-Drafts as reference material or to cite them other
-than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-The list of Internet-Draft Shadow Directories can be
-accessed at http://www.ietf.org/shadow.html.
-
-This Internet-Draft expires on January 13, 2001.
-
-
-2. Abstract
-
-This document describes an object class called ldapSubEntry
-which MAY be used to indicate operations and management
-related entries in the directory, called LDAP Subentries.
-This version of this document is updated with an assigned
-OID for the ldapSubEntry object class.
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
-"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
-and "OPTIONAL" in this document are to be interpreted as
-described in RFC 2119 [RFC2119]. The sections below
-reiterate these definitions and include some additional
-ones.
-
-
-Reed . [Page 1]
- Expires January 13, 2001 \f
-
-
-INTERNET-DRAFT 13 July 2000
- LDAP Subentry Schema
-
-3. Definition
-
-
-3.1 ldapSubEntry Class
-
-( 2.16.840.1.113719.2.142.6.1.1 NAME 'ldapSubEntry'
- DESC 'LDAP Subentry class, version 1'
- SUP top STRUCTURAL
- MAY ( cn ) )
-
-The class ldapSubEntry is intended to be used as a super-
-class when defining other structural classes to be used
-as LDAP Subentries, and as the structural class to which
-Auxiliary classes may be added for application specific
-subentry information. Where possible, the use of Auxiliary
-classes to extend ldapSubEntries is strongly preferred.
-
-The presence of ldapSubEntry in the list of super-classes
-of an entry in the directory makes that entry an LDAP
-Subentry. Object classes derived from ldapSubEntry are
-themselves considered ldapSubEntry classes, for the purpose
-of this discussion.
-
-LDAP Subentries MAY be named by their commonName attribute
-[LDAPv3]. Other naming attributes are also permitted.
-
-LDAP Subentries MAY be containers, unlike their [X.501]
-counterparts.
-
-LDAP Subentries MAY be contained by, and will usually be
-located in the directory information tree immediately
-subordinate to, administrative points and/or naming
-contexts. Further (unlike X.500 subentries), LDAP
-Subentries MAY be contained by other LDAP Subentries (the
-way organizational units may be contained by other
-organizational units). Deep nestings of LDAP Subentries
-are discouraged, but not prohibited.
-
-LDAP Subentries SHOULD be treated as "operational objects"
-in much the same way that "operational attributes" are not
-regularly provided in search results and read operations
-when only user attributes are requested).
-
-LDAP servers SHOULD implement the following special
-handling of ldapSubEntry entries:
-
-a) search operations which include a matching criteria
-"objectclass=ldapSubEntry" MUST include entries derived
-
-Reed . [Page 2]
- Expires January 13, 2001
- \f
-
-
-INTERNET-DRAFT 13 July 2000
- LDAP Subentry Schema
-
-from the ldapSubEntry class in the scope of their
-operations;
-
-b) search operations which do not include a matching
-criteria "objectclass=ldapSubEntry" MUST IGNORE entries
-derived from the ldapSubEntry class, and exclude them from
-the scope of their operations.
-
-The combination of SHOULD and MUST in the special handling
-instructions, above, are meant to convey this: Servers
-SHOULD support this special handling, and if they do they
-MUST do it as described, and not some other way.
-
-
-
-4. Security Considerations
-
-LDAP Subentries will frequently be used to hold data which
-reflects either the actual or intended behavior of the
-directory service. As such, permission to read such
-entries MAY need to be restricted to authorized users.
-More importantly, IF a directory service treats the
-information in an LDAP Subentry as the authoritative source
-of policy to be used to control the behavior of the
-directory, then permission to create, modify, or delete
-such entries MUST be carefully restricted to authorized
-administrators.
-
-
-
-5. References
-
-[LDAPv3] S. Kille, M. Wahl, and T. Howes, "Lightweight
-Directory Access Protocol (v3)", RFC 2251, December 1997
-
-[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993
-
-
-
-6. Copyright Notice
-
-Copyright (C) The Internet Society (1999). All Rights
-Reserved.
-
-This document and translations of it may be copied and
-furnished to others, and derivative works that comment on
-or otherwise explain it or assist in its implementation may
-be prepared, copied, published and distributed, in whole or
-
-Reed . [Page 3]
- Expires January 13, 2001
- \f
-
-
-INTERNET-DRAFT 13 July 2000
- LDAP Subentry Schema
-
-in part, without restriction of any kind, provided that the
-above copyright notice and this paragraph are included on
-all such copies and derivative works. However, this
-document itself may not be modified in any way, such as by
-removing the copyright notice or references to the Internet
-Society or other Internet organizations, except as needed
-for the purpose of developing Internet standards in which
-case the procedures for copyrights defined in the Internet
-Standards process must be followed, or as required to
-translate it into languages other than English.
-
-The limited permissions granted above are perpetual and
-will not be revoked by the Internet Society or its
-successors or assigns.
-
-This document and the information contained herein is
-provided on an "AS IS" basis and THE INTERNET SOCIETY AND
-THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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."
-
-
-7. Acknowledgements
-
-The use of subEntry object class to store Replica and
-Replication Agreement information is due primarily to the
-lucid explanation by Mark Wahl, Innosoft, of how they could
-be used and extended.
-
-The IETF takes no position regarding the validity or scope
-of any intellectual property 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; neither does it represent that it has made any
-effort to identify any such rights. Information on the
-IETF's procedures with respect to rights in standards-track
-and standards-related documentation can be found in BCP-11.
-Copies of claims of rights made available for publication
-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
-implementors or users of this specification can be obtained
-from the IETF Secretariat.
-
-
-
-Reed . [Page 4]
- Expires January 13, 2001
- \f
-
-
-INTERNET-DRAFT 13 July 2000
- LDAP Subentry Schema
-
-The IETF invites any interested party to bring to its
-attention any copyrights, patents or patent applications,
-or other proprietary rights which may cover technology that
-may be required to practice this standard. Please address
-the information to the IETF Executive Director.
-
-
-8. Author's Address
-
- Edwards E. Reed
- Reed-Matthews, Inc.
- 1064 E 140 North
- Lindon, UT 84042
- USA
- E-mail: eer@oncalldba.com
-
- LDUP Mailing List: ietf-ldup@imc.org
- LDAPEXT Mailing List: ietf-ldapext@netscape.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Reed . [Page 5]
- Expires January 13, 2001
- \f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT S. Legg
-draft-ietf-ldup-urp-03.txt Adacel Technologies
- A. Payne
- Telstra
- June 29, 2000
-
-
- LDUP Update Reconciliation Procedures
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- Status of this Memo
-
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This draft is published by the IETF LDUP Working Group. Distribution
- of this document is unlimited. Comments should be sent to the LDUP
- Replication mailing list <ldup@imc.org> or to the authors.
-
- This Internet-Draft expires on 29 December 2000.
-
- 1. Abstract
-
- This document describes the procedures used by LDAP [LDAPv3] or X.500
- [X500] directory servers to reconcile updates performed by
- autonomously operating directory servers in a distributed, replicated
- directory service.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 1]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- document are to be interpreted as described in RFC 2119 [RFC2119].
-
-
- 2. Table of Contents
-
- 1. Abstract 1
- 2. Table of Contents 2
- 3. Introduction 2
- 4. Model Extensions 3
- 4.1 Unique Identifier 3
- 4.2 Timestamps & Existence 3
- 4.3 Replication Primitives 4
- 4.4 Lost & Found 5
- 5. Replication Procedures 6
- 5.1 Processing LDAP, DAP or DSP Operations on the DIT 6
- 5.1.1 Add Entry 7
- 5.1.2 Remove Entry 8
- 5.1.3 Modify Entry 8
- 5.1.4 Modify DN 10
- 5.2 Generating Replication Primitives 10
- 5.3 Processing Replication Primitives on the DIT 12
- 5.3.1 Saving Deletion Records 13
- 5.3.2 Glue Entries 14
- 5.3.3 Generating Change Sequence Numbers 14
- 5.3.4 Comparison of Attribute Values 15
- 5.3.5 Entry Naming 15
- 5.3.6 Processing Add Attribute Value Primitive 18
- 5.3.7 Processing Remove Attribute Value Primitive 19
- 5.3.8 Processing Remove Attribute Primitive 20
- 5.3.9 Processing Add Entry Primitive 20
- 5.3.10 Processing Remove Entry Primitive 21
- 5.3.11 Processing Move Entry Primitive 22
- 5.3.12 Processing Rename Entry Primitive 23
- 6. Security Considerations 24
- 7. Acknowledgements 25
- 8. References 25
- 9. Intellectual Property Notice 26
- 10. Copyright Notice 26
- 11. Authors' Addresses 27
-
-
- 3. Introduction
-
- Each DAP, LDAP or DSP operation successfully performed by a directory
- server is subsequently reported to other directory servers with which
- it has a replication agreement as a set of one or more simple
- timestamped replication primitives. These primitives reflect the
- intended final state of an update operation rather than the specific
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 2]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- changes required to achieve that state.
-
- A directory server will receive replication primitives from its
- various agreement partners according to the agreement schedules.
- Those primitives MUST be reconciled with the current directory server
- contents. In broad outline, received replication primitives are
- compared to the timestamp information associated with the directory
- data item being operated on. If the primitive has a more recent
- timestamp a change in the directory contents is made (which may
- involve only the revision of the timestamp). If the directory server
- has other replication agreements then the change will be reflected in
- primitives sent during replication sessions for those other
- agreements. If the primitive has an older timestamp it is no longer
- relevant and is simply ignored.
-
- The Update Reconciliation Procedures are designed to produce a
- consistent outcome at all participating directory servers regardless
- of the order in which the primitives are received and processed. The
- primitives can also be safely replayed in the event that an exchange
- of replication information with another directory server is
- interrupted. This greatly simplifies the recovery mechanisms
- required in the replication protocol.
-
- 4. Model Extensions
-
- This section describes the extensions to the data model required to
- effect multi-master replication.
-
- 4.1 Unique Identifier
-
- A Unique Identifier is associated with each entry in the global DIT.
- This Unique Identifier MUST be globally unique for all time in the
- Directory. This can be achieved by defining a unique prefix for each
- directory server and then ensuring that the suffix of the Unique
- Identifier is locally unique.
-
- The Unique Identifier for an entry is held in the entryUUID
- operational attribute.
-
- Some pre-allocated global Unique Identifier values are used to
- indicate the X.500 global root entry, and the Lost & Found entry (see
- Section 4.4).
-
- 4.2 Timestamps & Existence
-
- The timestamp for a replication primitive or directory data item is
- in the form of a Change Sequence Number (CSN). The components of the
- CSN are, from most significant to least significant, a time in
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 3]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- seconds, a change count, a Replica Identifier and a modification
- number. Notionally a CSN is associated with an entry's Relative
- Distinguished Name (the Name CSN), the reference to its superior
- entry (the Parent CSN) and each of its attribute values (including
- the distinguished values and operational attribute values), to record
- the time of the most recent action on that part of the entry.
-
- The entry itself has a CSN (the Entry CSN) asserting the most recent
- time at which the entry was added. An entry is permitted to be
- removed and then re-added at one or more directory servers. In this
- context re-adding an entry means reusing the Unique Identifier of a
- removed entry and does not refer to the case of reusing the RDN of a
- removed entry. The reuse of a Unique Identifier can arise by the
- explicit action of a directory administrator to restore an entry that
- was mistakenly removed. The mechanism by which an administrator adds
- an entry with a reused Unique Identifier is outside the scope of the
- X.500 and LDAP standards since the Unique Identifier of an entry is
- not a user modifiable attribute. Note that from the perspective of a
- consumer directory server of a partial area of replication, an entry
- may appear to be removed and added several times because
- modifications to the entry change whether the entry satisfies the
- replication agreement specification for the area of replication.
-
- Additionally, a deletion record is kept for each of the recently
- deleted entries (entry deletion records), attributes (attribute
- deletion records), or attribute values (value deletion records). A
- deletion record contains a CSN and asserts that the associated
- directory object no longer existed at the particular time.
-
- 4.3 Replication Primitives
-
- Each update operation performed on an entry in a part of the DIT
- subject to one or more replication agreements MUST be subsequently
- reported as replication primitives to the replication partner
- directory servers of those agreements. The collection of primitives
- sent by a directory server to a replication partner will reflect both
- the results of locally processed user update requests and also of
- replicated updates received from other directory servers. A single
- update operation will decompose into one or more primitives.
-
- Common to all update primitives is an entry identifier argument, uid,
- containing the Unique Identifier of the target entry of the change,
- and a CSN argument, csn, to indicate the time of the change. In the
- case of adding a new entry, the Unique Identifier for the entry is
- allocated by the directory server in the course of processing the
- operation. Additional arguments are present depending on the type of
- replication primitive.
-
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 4]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- The p-add-entry(uid, csn, superior, rdn) primitive is used to
- describe the addition of a new entry with minimal contents. The
- superior argument contains the Unique Identifier of the immediate
- superior entry of the added entry. The rdn argument contains the
- Relative Distinguished Name of the added entry.
-
- The p-move-entry(uid, csn, superior) primitive is used to describe
- the moving of an entry to a new immediate superior in the DIT. The
- superior argument contains the Unique Identifier of the new superior
- entry.
-
- The p-rename-entry(uid, csn, rdn) primitive is used to describe a
- change to the Relative Distinguished Name of an entry. The rdn
- argument contains the new RDN for the entry.
-
- The p-remove-entry(uid, csn) primitive is used to describe the
- removal of an entry.
-
- The p-add-attribute-value(uid, csn, type, value) primitive is used to
- describe the addition of a single attribute value to an entry. The
- type argument contains the attribute type of the value and the value
- argument contains the attribute value.
-
- The p-remove-attribute-value(uid, csn, type, value) primitive is used
- to describe the removal of a single attribute value from an entry.
- The type argument contains the attribute type of the value and the
- value argument contains the attribute value.
-
- The p-remove-attribute(uid, csn, type) primitive is used to describe
- the removal of all values of an attribute from an entry. The type
- argument contains the removed attribute type.
-
- These primitives reflect the intended final state of an update
- operation rather than the specific changes required to achieve that
- state.
-
- 4.4 Lost & Found
-
- As a result of conflicting updates at two or more master directory
- servers, an entry may be left with a reference to a non-existent
- superior entry. Such an entry is called an orphaned entry. When
- this situation arises, the directory server creates a glue entry for
- the missing superior entry. This glue entry is made a subordinate of
- the specially nominated Lost & Found entry and the orphaned entry
- becomes a subordinate of the glue superior entry (see Section 5.3.2).
- Entries that exist in the Lost & Found subtree can still be modified
- by actions of the replication protocol since entries are identified
- by Unique Identifiers in the protocol, independent of their
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 5]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- positioning in the global DIT.
-
- Entries will also be explicitly moved to become immediate
- subordinates of the Lost & Found entry to prevent the formation of a
- loop in the superior-subordinate relationships in the DIT. This
- situation can only arise through conflicting move entry operations at
- two or more master directory servers.
-
- Entries that exist under the Lost & Found entry are able to be
- returned to a suitable position in the DIT by an administrator or
- user with appropriate access rights.
-
- 5. Replication Procedures
-
- The procedures defined in this section ensure the consistent and
- correct application of the results of DAP, LDAP or DSP operations
- across all replicating directory servers.
-
- 5.1 Processing LDAP, DAP or DSP Operations on the DIT
-
- A successful DAP, LDAP or DSP operation applied to a part of the DIT
- subject to a replication agreement will create or replace one or more
- CSNs on an entry or its contents, and create zero, one or more
- deletion records referencing the entry or its contents. The CSNs and
- deletion records generated from an operation are atomic with that
- operation. That is, either the operation succeeds, the CSNs are
- revised and the deletion records are stored, or the operation fails,
- no CSNs are revised and no deletion records are stored. In all
- cases, all current error conditions (i.e. reasons for rejecting an
- LDAP, DAP or DSP update operation) remain.
-
- At some later time, possibly immediately following the update or
- concurrently with it, the CSNs on entry contents and deletion records
- are used to generate the replication primitives that will report the
- update to other directory servers via a replication session.
-
- All the CSNs generated from a single update operation MUST use the
- same time, change count and Replica Identifier. The modification
- number is permitted to vary but MUST be assigned such that when the
- CSNs resulting from the operation, including those in the deletion
- records, are compared to the CSNs resulting from any other operation
- they are all strictly greater than or all strictly less than those
- other CSNs (i.e. in a global CSN ordering of the primitives
- resulting from all operations the primitives of each operation MUST
- be contiguous in that ordering). In order for the update to be
- consistently applied when replicated to other directory servers the
- CSNs generated during that update must generally be greater than any
- pre-existing CSNs on the updated entry's contents. It is expected
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 6]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- that directory servers will normally use the current time according
- to their system clocks in generating the CSNs for an operation.
- However in an environment where directory server clocks are not
- necessarily synchronized the current time may be older than existing
- CSNs on entry contents. The constraints the new CSNs MUST satisfy
- with respect to pre-existing CSNs on entry data are covered in the
- sections on each type of update operation. The Update Reconciliation
- Procedures allow a directory server to generate CSNs in advance of
- its current time to satisfy the constraints and proceed with the
- update.
-
- The LDUP Update Vector mechanism imposes the additional constraint
- that the CSN generated for an update operation MUST also be greater
- than the highest CSN generated by the directory server that has
- already been seen by any other directory server. An implementation
- that generates successively greater CSNs for each operation will
- satisfy this constraint.
-
- The following sections describe the additional actions carried out in
- processing each standard type of update operation in order to support
- replication. If a directory server implementation supports other
- non-standard update operations or alternative non-directory update
- protocols then, in so far as these operations alter replicated
- directory data, the implementation MUST generate and apply CSNs and
- deletion records that accurately reflect any change.
-
- A directory server implementation may also perform implicit updates
- in response to user update requests, e.g. to maintain the referential
- integrity of distinguished names. Appropriate CSNs and deletion
- records for these changes MUST also be generated.
-
- A detailed description of the replication processing for these other
- types of update is beyond the scope of this document.
-
-
- 5.1.1 Add Entry
-
- The LDAP Add operation [LDAPv3] or DAP addEntry operation [X511] is
- used to add a leaf entry to the DIT. A successful request will
- generate a CSN for the entry. The CSN on the entry's RDN, the CSN on
- the entry's superior reference, and the CSN on each distinguished and
- non-distinguished value added to the entry by the add entry operation
- are set to this same value. The affected values include any
- operational attribute values automatically generated by the directory
- server, e.g. creatorsName and createTimestamp. Note that the value
- of the createTimestamp attribute does not necessarily correspond to
- the time component of the CSN associated with that value.
-
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 7]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- The Unique Identifier generated for an entry created by a user
- request is required to be globally unique for all time, so there
- ought not be a pre-existing entry deletion record for the same Unique
- Identifier. However it is recognized that, in practice, directory
- administrators may need to restore a deleted entry using its original
- Unique Identifier (the mechanism used to achieve this is undefined
- and outside the scope of this specification). In this case the CSN
- for the entry MUST be generated such that it is greater than or equal
- to the CSN of any existing entry, attribute or value deletion
- records, and greater than any of the CSNs contained in an existing
- glue entry, for the same Unique Identifier.
-
- 5.1.2 Remove Entry
-
- The LDAP Delete operation [LDAPv3] or DAP removeEntry operation
- [X511] is used to remove a leaf entry from the DIT. If the request
- succeeds then an entry deletion record is stored containing the
- Unique Identifier of the removed entry. The CSN for the entry
- deletion record MUST be generated such that it is greater than the
- entry CSN of the removed entry.
-
- 5.1.3 Modify Entry
-
- The LDAP Modify operation (ModifyRequest) [LDAPv3] or DAP modifyEntry
- operation [X511] is used to perform a series of one or more
- modifications to an entry. If the request succeeds then zero, one or
- more new values with CSNs are added to the entry contents, and zero,
- one or more value or attribute deletion records are stored.
-
- The modifications described by the modification argument of the LDAP
- ModifyRequest have the following additional effects:
-
- a) The add alternative associates a CSN with each of the added
- attribute values.
-
- b) The delete alternative with no listed values generates an
- attribute deletion record for the removed attribute type.
-
- c) The delete alternative with listed values generates a value
- deletion record for each of the removed values.
-
- d) The replace alternative first generates an attribute deletion
- record for the removed attribute type. A CSN is then associated
- with each of the added values.
-
- The modifications described by the changes argument of the X.500
- modifyEntry operation have the following additional effects:
-
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 8]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- a) The addAttribute and addValues alternatives associate a CSN
- with each of the added attribute values. These two alternatives
- are equivalent from the point of view of URP since there is no CSN
- associated specifically with the attribute type.
-
- b) The removeAttribute alternative generates an attribute deletion
- record for the removed attribute type.
-
- c) The removeValues alternative generates a value deletion record
- for each of the removed values.
-
- d) The alterValues alternative first generates a value deletion
- record for each of the old values. Secondly, a CSN is associated
- with each of the new values.
-
- e) The resetValues alternative generates a value deletion record
- for each value actually removed.
-
- A successful ModifyRequest or modifyEntry operation will also result
- in changes to operational attributes of the entry. Like the explicit
- modifications to user attributes, CSNs are given to new operational
- attribute values and deletion records are stored for operational
- attribute values that are removed. The processing in each case
- depends on the semantics of the particular operational attribute type
- and can be deduced by considering an equivalent explicit modification
- request. In particular, the revision of the modifyTimestamp and
- modifiersName attributes is treated like the ModifyRequest replace
- alternative. Note that the value of the modifyTimestamp attribute
- does not necessarily correspond to the time component of the CSN
- associated with that value. The entryUUID operational attribute
- SHALL NOT be modified. Consequently attribute and value deletion
- records for the entryUUID attribute type are never generated.
-
- The CSNs generated by a modify operation MUST be greater than the CSN
- of any pre-existing attribute value that is removed, greater than or
- equal to the CSN of any pre-existing attribute deletion record or
- value deletion record applying to an added attribute value, and
- greater than or equal to the CSN of the entry.
-
- A further constraint applies to the modification number component of
- the CSNs generated by a single modify operation. The CSN generated
- for an added attribute value MUST be greater than or equal to the CSN
- on any applicable value deletion record or attribute deletion record
- already created by this same operation. This constraint is satisfied
- if the same modification number is used in all the CSNs generated by
- a single modify operation, or if the CSNs generated as the sequence
- of modifications in the operation are applied in order use
- monotonically increasing modification numbers. The modification
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 9]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- numbers need not be consecutive in this case.
-
- Whenever a new value is added to the entry contents any value
- deletion record for the same entry, attribute type and attribute
- value MAY be discarded.
-
- 5.1.4 Modify DN
-
- The LDAP Modify DN operation [LDAPv3] and DAP modifyDN operation
- [X511] are used to change the Relative Distinguished Name of an entry
- and/or to move an entry to a new superior in the DIT. If the entry
- is moved to a new superior in the DIT then the CSN on the entry's
- superior reference is replaced. If the entry's RDN is changed then
- the CSN on the entry's RDN is replaced. A value deletion record is
- stored for each of the formally distinguished attribute values
- removed from the entry as a consequence of the deleteOldRDN parameter
- (modifyDN) or deleteoldrdn parameter (ModifyDNRequest) being set to
- true. An entryUUID attribute value that is made non-distinguished
- SHALL NOT be removed from the entry regardless of the deleteOldRDN or
- deleteoldrdn flag and SHALL NOT have a corresponding value deletion
- record.
-
- If the CSN on the entry's superior reference is revised then the new
- value MUST be greater than the previous value. If the CSN on the
- entry's RDN is revised then the new value MUST be greater than the
- previous value of the CSN on the RDN. The CSNs for any value
- deletion records MUST be greater than the CSNs on the removed
- attribute values.
-
- 5.2 Generating Replication Primitives
-
- Each time a replication session is invoked, the supplier directory
- server generates and sends replication primitives for updates known
- to the supplier but not yet known to the consumer directory server.
- The supplier uses the Update Vector of the consumer to determine what
- to send. Conceptually, the supplier scans all the glue and non-glue
- entries and deletion records covered by the replication agreement
- with the consumer and generates primitives where the CSNs held by the
- supplier are greater than the CSN for the corresponding identified
- replica in the consumer's Update Vector. No replication primitives
- are generated for entries or entry contents that are outside the
- scope of the replication agreement.
-
- A p-add-entry primitive is generated for each entry whose entry CSN
- is greater than the Update Vector CSN for the same replica. The
- superior argument of the p-add-entry primitive contains the Unique
- Identifier of the immediate superior entry of the added entry. The
- rdn argument of the p-add-entry primitive contains the Relative
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 10]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- Distinguished Name of the created entry except that the value of the
- entryUUID attribute, if distinguished, is always omitted from the
- RDN. The superior and rdn arguments are provided even if the CSN on
- the superior reference or the RDN are greater than the CSN on the
- entry.
-
- A p-add-attribute-value primitive is generated for each distinguished
- value that has a CSN greater than the Update Vector CSN for the same
- replica and greater than the CSN on the RDN of its entry. A p-add-
- attribute-value primitive is generated for each non-distinguished
- value that has a CSN greater than the Update Vector CSN for the same
- replica. The values of operational attributes are treated in the
- same way as the values of user attributes. The p-add-attribute-value
- primitive uses the CSN of the corresponding value. There are no
- separate primitives generated for the distinguished values that have
- the same CSN as the CSN on their entry's RDN.
-
- If the CSN on an entry's RDN is greater than the Update Vector CSN
- for the same replica and greater than the CSN on the entry then a p-
- rename-entry primitive is generated. The CSN for this primitive is
- the CSN on the entry's RDN and the rdn argument contains the Relative
- Distinguished Name of the entry.
-
- If the CSN on the entry's superior reference is greater than the
- Update Vector CSN for the same replica and greater than the CSN on
- the entry then a p-move-entry primitive is generated. The CSN for
- this primitive is the CSN on the entry's superior reference and the
- superior argument contains the Unique Identifier of the immediate
- superior entry.
-
- A p-remove-attribute-value primitive is generated for each value
- deletion record having a CSN greater than the Update Vector CSN for
- the same replica. The primitive uses exactly the same arguments as
- the value deletion record.
-
- A p-remove-attribute primitive is generated for each attribute
- deletion record having a CSN greater than the Update Vector CSN for
- the same replica. The primitive uses exactly the same arguments as
- the attribute deletion record.
-
- A p-remove-entry primitive is generated for each entry deletion
- record having a CSN greater than the Update Vector CSN for the same
- replica. The primitive uses exactly the same arguments as the entry
- deletion record.
-
- Rather than scanning the DIT, an implementation MAY choose to
- generate replication primitives as the user update requests are being
- processed and put these primitives into a replication log in
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 11]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- preparation for sending during the next replication session. Any
- replication primitives generated from an operation in this way MUST
- be atomic with that operation. That is, either the operation
- succeeds, and primitives are added to the replication log, or the
- operation fails, and no primitives are added to the log. The
- replication log MAY be filtered prior to sending to eliminate any
- primitives that are superseded by later primitives in the log, and to
- eliminate any primitives having CSNs less than or equal to the
- relevant CSNs contained in a consumer directory server's Update
- Vector.
-
- In a log based implementation, the p-add-attribute-value primitive
- supersedes a p-remove-attribute-value primitive for the same entry,
- attribute type, attribute value and equal or older CSN. It
- supersedes another p-add-attribute-value primitive for the same
- entry, attribute type, attribute value and older CSN.
-
- The p-remove-attribute-value primitive supersedes a p-add-attribute-
- value primitive for the same entry, attribute type, attribute value
- and older CSN. It supersedes another p-remove-attribute-value
- primitive for the same entry, attribute type, attribute value and
- equal or older CSN.
-
- The p-remove-attribute primitive supersedes a p-add-attribute-value
- primitive for the same entry, attribute type and older CSN. It
- supersedes a p-remove-attribute-value or another p-remove-attribute
- primitive for the same entry, attribute type and equal or older CSN.
-
- The p-remove-entry primitive supersedes a p-add-attribute-value, p-
- add-entry, p-move-entry or p-rename-entry primitive for the same
- entry and older CSN. It supersedes a p-remove-attribute-value or p-
- remove-attribute or another p-remove-entry primitive for the same
- entry and equal or older CSN.
-
- The p-move-entry primitive supersedes another p-move-entry primitive
- for the same entry and older CSN.
-
- 5.3 Processing Replication Primitives on the DIT
-
- Each replication primitive received from another directory server
- during a replication session that is within the scope of the
- replication agreement is processed against the DIT. Replication
- primitives outside the scope of the replication agreement are
- rejected.
-
- This section defines some commonly used sub-procedures and the
- algorithms for processing each of the primitives. These algorithms
- are not intended to be implemented verbatim but instead describe the
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 12]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- behaviour an LDUP implementation MUST exhibit externally.
- Alternative equivalent processing logic is permitted.
-
- Components of primitives, entries, attributes and values are
- referenced with the `.' operator. In particular the notation X.csn
- refers to the CSN of the directory object X. The operators, < and >
- when applied to CSNs, use the convention of CSNs becoming greater
- with the progression of time, so older CSNs are less than younger
- CSNs. In the case where the CSN for object X has been discarded
- through the purging mechanism, X.csn is assumed to have the least
- possible CSN value. In some of the procedures a CSN will be
- explicitly purged. An implementation MAY instead keep the CSN but
- set it to some value that is old enough for it to be eligible for
- purging (e.g. the least possible CSN value) without affecting the
- correctness of the procedures.
-
- For an entry, E, the notation E.rdn refers to the entry's Relative
- Distinguished Name, E.dn refers to the entry's Distinguished Name,
- and E.superior refers to the Unique Identifier of the entry's
- superior in the DIT.
-
- 5.3.1 Saving Deletion Records
-
- It is necessary for a directory server to store deletion records to
- remember that some entry, attribute or attribute value has been
- deleted, for a period after the processing of the update operation or
- replication primitive causing the deletion.
-
- Value deletion records have the same parameters as the p-remove-
- attribute-value primitive. The StoreValueDeletion procedure creates
- a value deletion record from the actual arguments and stores it for
- later access by the various primitive processing procedures. When an
- attribute value is added to an entry, a value deletion record for the
- same entry, attribute type and value, and with an older CSN, MAY be
- discarded.
-
- Attribute deletion records have the same parameters as the p-remove-
- attribute primitive. The StoreAttributeDeletion procedure creates an
- attribute deletion record from the actual arguments and stores it for
- later access. When an attribute deletion record is stored any value
- deletion records for the same entry and attribute type, and with
- equal or older CSNs, MAY be discarded.
-
- Entry deletion records have the same parameters as the p-remove-entry
- primitive. The StoreEntryDeletion procedure creates an entry
- deletion record from the actual arguments and stores it for later
- access. When an entry deletion record is stored any value deletion
- records and attribute deletion records for the same entry, and with
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 13]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- equal or older CSNs, MAY be discarded.
-
- Since the deletion records have the same components as their
- associated remove primitives an implementation MAY choose to use the
- same internal structures for both.
-
- 5.3.2 Glue Entries
-
- Entries are permitted to be re-added and this can lead to situations
- where applicable primitives are received in the period after an entry
- is removed but before the arrival of the notification of it being
- re-added. In these cases a glue entry is created for the Unique
- Identifier to preserve relevant updates in the event that a p-add-
- entry primitive with an older CSN is later received for the same
- entry. A glue entry is upgraded to a normal entry by a subsequent
- p-add-entry primitive.
-
- A glue entry with no subordinate entries and containing only CSNs (on
- itself or its component parts) that are eligible to be purged MAY be
- removed. A glue entry is discarded if its contents are completely
- superseded by another p-remove-entry primitive.
-
- The CreateGlueEntry function is called when required to create a glue
- entry as a subordinate of Lost & Found. CreateGlueEntry takes a
- single parameter which is the Unique Identifier for the glue entry.
- The Unique Identifier, in the form of the entryUUID attribute, also
- becomes the RDN for the glue entry. No CSNs are associated with the
- entry, the entry's superior reference, or the entry's name (or
- equivalently they are set to the least possible CSN value).
-
- 5.3.3 Generating Change Sequence Numbers
-
- There are circumstances where conflicts arise in the processing of a
- replication primitive. It is necessary in these cases for the
- directory server processing the primitives to make corrective changes
- and emit additional primitives to ensure that all other directory
- servers reach the same consistent state. The GenerateNextCSN
- function is used to obtain a CSN for the corrective change. An
- implementation that generates replication primitives as the user
- update requests are being processed and puts them into a replication
- log MUST take the additional step of creating a primitive to convey
- the corrective change to other directory servers. Implementations
- that generate primitives by scanning entries will pick up the
- corrective change automatically.
-
- As is the case for CSNs generated from DAP, DSP or LDAP operations,
- the CSN for the corrective change is typically generated from the
- current clock time of the directory server. The conditions imposed
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 14]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- for the correct operation of the LDUP Update Vector MUST also be
- satisfied.
-
- GenerateNextCSN takes a single CSN parameter. In addition to all
- other conditions, the CSN generated by the function MUST be greater
- than this parameter. Since the CSN parameter passed to
- GenerateNextCSN is always an actual CSN from some directory object
- stored in the local directory server, an implementation MAY choose to
- allocate CSNs from an incrementing internal CSN register that is
- reset after each replication session to a value greater than the
- largest CSN seen so far, and thereby be safely able to disregard the
- parameter to GenerateNextCSN.
-
- 5.3.4 Comparison of Attribute Values
-
- Values in primitives, in deletion records or in entries are compared
- using the equality matching rule for the associated attribute type
- where that type is permitted to be multi-valued. This means that two
- values that are considered equal may nonetheless have minor
- differences. For example, two commonName values may be equal, but
- use different letter case and have different numbers of leading or
- trailing spaces. Whenever a CSN for some value is refreshed the
- value is also refreshed using the exact value from the primitive so
- that all directory servers use exactly the same representation for
- the value.
-
- Compared values for a single-valued attribute type are all considered
- to be equal even though they may be significantly different according
- to that attribute type's equality matching rule. In effect the
- equality operator, `=', in the following procedures is
- unconditionally true when used to compare values of a single-valued
- attribute type. Whenever a CSN for the value of a single-valued
- attribute is refreshed the value is also refreshed using the value
- from the primitive. One significant consequence is that an entry
- whose RDN contains a value of a single-valued attribute type is
- effectively renamed by a p-add-attribute-value primitive with a more
- recent value for the attribute type.
-
- A value in an entry that is replaced by the exact representation from
- a primitive retains its distinguished or non-distinguished status.
- This includes replaced values of single-valued attribute types.
-
- 5.3.5 Entry Naming
-
- Independent changes at two or more directory servers can lead to the
- situation of two distinct entries having the same name. The
- procedure, CheckUniqueness(E, S, R), takes an entry and determines
- whether it is uniquely named. If not, it disambiguates the names of
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 15]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- the entries by adding the Unique Identifier (i.e. the entryUUID
- attribute) of each of the conflicting entries to their own RDN.
-
- The procedure CheckUniqueness is called in each circumstance where
- the Relative Distinguished Name of an entry might conflict with
- another entry, either because the entry has been renamed or because
- it has been moved to a new superior. An entry can be renamed
- directly by a p-rename-entry primitive, or as a side-effect of other
- primitives causing changes to distinguished values. While each move
- or rename of an entry potentially causes a conflict with some other
- entry already having the new Distinguished Name, it also potentially
- removes a previous conflict on the old Distinguished Name. To enable
- the CheckUniqueness function to remove the Unique Identifier from an
- entry's RDN when it is no longer needed, the old name for an entry is
- passed through the second and third parameters. The parameter, S, is
- the Unique Identifier of the old superior entry of E, and the
- parameter, R, is the old RDN of E. CheckUniqueness ignores
- distinguished entryUUID values when comparing entry RDNs. The
- function BaseRDN(rdn) returns its argument minus any distinguished
- entryUUID values, to support these comparisons.
-
- CheckUniqueness(E, S, R)
- {
- make E.uid non-distinguished
- IF there exists exactly one subordinate entry, C, of S
- where BaseRDN(C.rdn) = BaseRDN(R)
- make C.uid non-distinguished
- IF E.rdn is empty
- make C.uid distinguished
- ELSE IF there exists a subordinate entry, C, of E.superior
- where E <> C AND BaseRDN(C.rdn) = BaseRDN(E.rdn)
- {
- make C.uid distinguished
- make E.uid distinguished
- }
- }
-
- Because updates are performed in isolation at multiple directory
- servers in a multimaster configuration it is possible to encounter a
- situation where there is a request to delete a distinguished value in
- an entry. The recommended practice in these circumstances is to
- remove the distinguished value and call CheckUniqueness to correct
- any resulting name conflicts. An implementation MAY instead reassert
- the existence of the distinguished value with a more recent CSN to
- avoid altering the entry's RDN. This option is only available to
- updatable replicas. Read-only replicas MUST remove the distinguished
- value. The function ProtectDistinguished() returns true for an
- updatable part of the DIT in a directory server that implements this
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 16]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- option, and false otherwise. directory servers exercising this
- option MUST generate a p-add-attribute-value primitive so that other
- directory servers are guaranteed to also reassert the distinguished
- value. Directory servers that implement the option will correctly
- interwork with servers that do not.
-
- The primitives p-add-entry and p-rename-entry contain common elements
- that are applied to the Relative Distinguished Name of an entry in
- the same way. This common processing is described in the RenameEntry
- procedure. The parameters to this procedure are the entry, E, and
- the p-add-entry or p-rename-entry primitive specifying the new RDN.
- The procedure assumes that the entry does not currently contain any
- distinguished values. It is the responsibility of the calling
- procedure to first reset any pre-existing distinguished values to
- non-distinguished. The procedure then resets the CSNs and sets the
- distinguished flags for existing values and adds distinguished values
- if necessary. The CSN for the entry's RDN, as distinct from the CSNs
- on each of the distinguished values making up the RDN, is also set.
-
- RenameEntry(E, P)
- {
- FOREACH AttributeTypeAndValue, N, in P.rdn
- IF there exists an attribute value, V, in E of type N.type
- where V = N.value
- {
- IF P.csn > V.csn
- {
- replace V with N.value if they are not identical
- V.csn := P.csn
- }
- make V distinguished
- }
- ELSE IF ProtectDistinguished()
- {
- V := N.value
- add V to E as a distinguished value
- V.csn := P.csn
- FOREACH attribute deletion record (uid, type, csn)
- where (uid = P.uid AND type = N.type)
- IF csn > V.csn
- V.csn := csn
- FOREACH value deletion record (uid, type, value, csn)
- where (uid = P.uid AND type = N.type AND value = N.value)
- IF csn > V.csn
- V.csn := csn
- V.csn := GenerateNextCSN(V.csn)
- }
- ELSE IF no attribute deletion record (uid, type, csn) exists
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 17]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- where (uid = P.uid AND type = N.type AND csn > P.csn)
- AND no value deletion record (uid, type, value, csn) exists
- where (uid = P.uid AND type = N.type AND
- value = N.value AND csn > P.csn)
- {
- V := N.value
- add V to E as a distinguished value
- V.csn := P.csn
- }
- E.rdn.csn := P.csn
- }
-
-
- 5.3.6 Processing Add Attribute Value Primitive
-
- This section details the algorithm for processing the p-add-
- attribute-value (P.uid, P.type, P.value, P.csn) primitive, which
- describes the addition of a single attribute value. If P.type is the
- entryUUID attribute type then the primitive MUST be rejected.
-
- IF no value deletion record (uid, type, value, csn) exists where
- (uid = P.uid AND type = P.type
- AND value = P.value AND csn > P.csn)
- AND no attribute deletion record (uid, type, csn) exists where
- (uid = P.uid and type = P.type AND csn > P.csn)
- AND no entry deletion record (uid, csn) exists where
- (uid = P.uid AND csn > P.csn)
- {
- IF entry, E, with uid = P.uid does not exist
- E := CreateGlueEntry(P.uid)
- IF P.csn >= E.csn
- IF attribute value V, of type P.type
- where V = P.value exists in E
- {
- IF P.csn > V.csn
- {
- V.csn := P.csn
- R := E.rdn
- replace V with P.value if they are not identical
- IF V is distinguished
- AND P.type is a single-valued attribute type
- CheckUniqueness(E, E.superior, R)
- }
- }
- ELSE
- {
- V := P.value
- Add V to E as a non-distinguished attribute value
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 18]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- V.csn := P.csn
- }
- }
-
-
- 5.3.7 Processing Remove Attribute Value Primitive
-
- This section details the algorithm for processing the p-remove-
- attribute-value (P.uid, P.type, P.value, P.csn) primitive, which
- describes the removal of a single attribute value. If P.type is the
- entryUUID attribute type then the primitive MUST be rejected.
-
- IF no value deletion record (uid, type, value, csn) exists
- where (uid = P.uid AND type = P.type AND
- value = P.value AND csn >= P.csn)
- AND
- no attribute deletion record (uid, type, csn) exists
- where (uid = P.uid AND type = P.type AND csn >= P.csn)
- AND
- no entry deletion record (uid, csn) exists
- where (uid = P.uid AND csn >= P.csn)
- IF entry, E, with uid = P.uid exists
- {
- IF P.csn > E.csn
- IF attribute value, V, of P.type
- where V = P.value, exists in E
- {
- IF P.csn > V.csn
- IF V is distinguished
- IF ProtectDistinguished()
- V.csn := GenerateNextCSN(P.csn)
- ELSE
- {
- R := E.rdn
- remove value V
- CheckUniqueness(E, E.superior, R)
- StoreValueDeletion (P.uid, P.type, P.value, P.csn)
- }
- ELSE
- {
- remove value V
- StoreValueDeletion (P.uid, P.type, P.value, P.csn)
- }
- }
- ELSE
- StoreValueDeletion (P.uid, P.type, P.value, P.csn)
- }
- ELSE
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 19]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- StoreValueDeletion (P.uid, P.type, P.value, P.csn)
-
- The presence of a younger deletion record for the entry, attribute or
- value provides a convenient test for whether the p-remove-attribute-
- value primitive needs to be processed at all. If the value exists to
- be removed then there cannot be a deletion record affecting it that
- has a younger CSN. If there is a younger deletion record than the
- primitive then there cannot be an older value to remove.
-
-
- 5.3.8 Processing Remove Attribute Primitive
-
- This section details the algorithm for processing the p-remove-
- attribute (P.uid, P.type, P.csn) primitive, which describes the
- removal of all attribute values of P.type. If P.type is the
- entryUUID attribute type then the primitive MUST be rejected.
-
- IF no attribute deletion record (uid, type, csn) exists
- where (uid = P.uid AND type = P.type AND csn >= P.csn)
- AND no entry deletion record (uid, csn) exists where
- (uid = P.uid AND csn >= P.csn)
- IF entry, E, with uid = P.uid exists
- {
- IF P.csn > E.csn
- {
- FOREACH attribute value, V, of type P.type in E (if any)
- IF P.csn > V.csn
- IF V is distinguished
- IF ProtectDistinguished()
- V.csn := GenerateNextCSN(P.csn)
- ELSE
- {
- R := E.rdn
- remove value V
- CheckUniqueness(E, E.superior, R)
- }
- ELSE
- remove value V
- StoreAttributeDeletion (P.uid, P.type, P.csn)
- }
- }
- ELSE
- StoreAttributeDeletion (P.uid, P.type, P.csn)
-
-
- 5.3.9 Processing Add Entry Primitive
-
- This section details the algorithm for processing the p-add-entry
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 20]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- (P.uid, P.superior, P.rdn, P.csn) primitive, which describes the
- addition of an entry. The CSN on an entry records the time of the
- latest p-add-entry primitive for the Unique Identifier. In normal
- circumstances there will only ever be one p-add-entry primitive
- associated with an entry. The entry CSN MAY be discarded when it
- becomes eligible to be purged according to the Purge Vector.
-
- IF no entry deletion record (uid, csn) exists where
- (uid = P.uid AND csn > P.csn)
- IF entry, E, with uid = P.uid exists
- {
- IF P.csn > E.csn
- {
- R := E.rdn
- S := E.superior
- E.csn := P.csn
- FOREACH attribute type, T, in E, except entryUUID
- FOREACH attribute value, V, of type T
- IF V.csn < P.csn
- remove value V
- CheckUniqueness(E, S, R)
- process P according to
- p-rename-entry(P.uid, P.rdn, P.csn)
- process P according to
- p-move-entry(P.uid, P.superior, P.csn)
- }
- }
- ELSE
- {
- create entry E
- E.csn := P.csn
- E.uid := P.uid
- E.uid.csn := P.csn
- IF an entry with uid = P.superior does not exist
- CreateGlueEntry(P.superior)
- E.superior = P.superior
- E.superior.csn := P.csn
- RenameEntry(E, P)
- CheckUniqueness(E, E.superior, E.rdn)
- }
-
-
- 5.3.10 Processing Remove Entry Primitive
-
- This section details the algorithm for processing the p-remove-entry
- (P.uid, P.csn) primitive, which describes the removal of an entry.
- If the target entry has attribute values with CSNs greater than the
- primitive's CSN, a superior reference with a greater CSN, or if it
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 21]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- has any subordinate entries, it becomes a glue entry instead of being
- removed. It is also moved to Lost & Found, unless it has a CSN for
- its superior reference that is greater than the CSN of the p-remove-
- entry.
-
- IF no entry deletion record (uid, csn) exists
- where (uid = P.uid AND csn >= P.csn)
- IF entry, E, with uid = P.uid exists
- {
- IF P.csn > E.csn
- {
- IF E.superior.csn >= P.csn
- OR any value, V, with csn >= P.csn exists
- OR E has subordinates
- {
- R := E.rdn
- S := E.superior
- make E a glue entry
- purge E.csn
- IF E.superior.csn < P.csn
- {
- E.superior := LOST_AND_FOUND
- purge E.superior.csn
- }
- IF E.rdn.csn < P.csn
- purge E.rdn.csn
- FOREACH attribute type, T, in E, except entryUUID
- FOREACH attribute value, V, of type T
- IF V.csn < P.csn
- remove value V
- CheckUniqueness(E, S, R)
- }
- ELSE
- remove entry E
- StoreEntryDeletion (P.uid, P.csn)
- }
- }
- ELSE
- StoreEntryDeletion (P.uid, P.csn)
-
-
- 5.3.11 Processing Move Entry Primitive
-
- This section details the algorithm for processing the p-move-entry
- (P.uid, P.superior, P.csn) primitive, which describes the moving of
- an entry to a new immediate superior in the DIT. If the new superior
- specified by the primitive does not exist, or is a direct or indirect
- subordinate of the entry being moved, then the entry is moved to Lost
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 22]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- & Found instead.
-
- IF no entry deletion record (uid, csn) exists
- where (uid = P.uid AND csn > P.csn)
- {
- IF entry, E, with uid = P.uid does not exist
- E := CreateGlueEntry(P.uid)
- IF P.csn > E.superior.csn
- {
- R := E.rdn
- O := E.superior
- IF entry, S, with uid = P.superior does not exist
- S := CreateGlueEntry(P.superior)
- IF S is not in the subtree of E
- {
- E.superior := P.superior
- E.superior.csn = P.csn
- }
- ELSE
- {
- E.superior := LOST_AND_FOUND;
- E.superior.csn := GenerateNextCSN(P.csn)
- }
- CheckUniqueness(E, O, R)
- }
- }
-
-
- 5.3.12 Processing Rename Entry Primitive
-
- This section details the algorithm for processing the p-rename-entry
- (P.uid, P.rdn, P.csn) primitive, which describes a change to the
- Relative Distinguished Name of an entry. A p-rename-entry primitive
- that is older than current name of an entry is not simply ignored
- since it may contain attribute values that would have been added to
- the entry had the primitives arrived in CSN order. These extra
- values would now be non-distinguished.
-
- IF no entry deletion record (uid, csn) exists
- where (uid = P.uid AND csn >= P.csn)
- {
- IF entry, E, with uid = P.uid does not exist
- E := CreateGlueEntry(P.uid)
- IF P.csn > E.rdn.csn
- {
- R := E.rdn
- FOREACH distinguished attribute value, V, in entry E
- make V non-distinguished
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 23]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- RenameEntry(E, P)
- CheckUniqueness(E, E.superior, R)
- }
- ELSE
- FOREACH AttributeTypeAndValue, N, in P.rdn
- {
- IF there exists an attribute value, V, in E of type
- N.type AND V = N.value
- {
- IF P.csn > V.csn
- {
- replace V with N.value if they are not identical
- V.csn := P.csn
- }
- }
- ELSE
- {
- IF no value deletion record (uid, type, value, csn)
- exists where (uid = P.uid AND type = N.type AND
- value = N.value AND csn > P.csn)
- AND
- no attribute deletion record (uid, type, csn)
- exists where (uid = P.uid AND type = N.type AND
- csn > P.csn)
- {
- V := N.value
- Add V to E
- V.csn := P.csn
- }
- }
- }
- }
-
-
- 6. Security Considerations
-
- The procedures described in this document are not subject to access
- controls on the directory data items being modified. Specifically,
- the update primitives received from a peer replica are applied
- without regard for access controls. This is necessary so that access
- control information can also be replicated. An LDUP enabled server
- entering into a multi-master replication agreement with a peer server
- is enabling joint authority and responsibility for some part of the
- directory data. A replica must trust that the other replicas are
- properly enforcing access controls on user update requests, but this
- trust extends only as far as described by the replication agreements
- currently in place. The replication agreement acts as a surrogate
- for access controls between peer replicas. Replication primitives
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 24]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- that are outside the scope of the agreement are rejected.
-
- Authentication of peer replica LDUP sessions and the security of the
- exchange of replication primitives through the LDUP protocol are
- outside the scope of this document and are described elsewhere.
-
- Simultaneous updates at different replicas can result in two entries,
- corresponding to two different real world entities, having the same
- distinguished name. The Update Reconciliation Procedures
- disambiguate these two names by appending the respective Unique
- Identifiers to the entries' RDNs. This action will disable any
- access controls based on an entry's specific DN or RDN. Disabling
- such an access control may have the effect of granting a permission
- that was explicitly denied. Since a Unique Identifier is required to
- be globally unique for all time, appending a Unique Identifier to the
- RDN cannot unintentionally enable access controls applying to a
- different real world entity.
-
- It is sufficient when disambiguating entry RDNs to append the UID to
- only one of a pair of entries ending up with the same name. The
- Update Reconciliation Procedures require both entries to have their
- UID appended to minimize the chance that either entry will gain
- permissions intended for the other. This is based on the assumption
- that most access controls will grant permissions rather than deny
- permissions.
-
-
- 7. Acknowledgements
-
- The authors would like to thank Suellen Faulks and Tony Robertson
- from Telstra and Mark Ennis from Adacel Technologies who contributed
- to the design and verification of the procedures described in this
- document.
-
- The authors would also like to thank the members of the LDUP
- architecture group for their input into the refinement of the design.
-
-
- 8. References
-
- [RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119.
-
- [LDAPv3] - M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [X500] - ITU-T Recommendation X.500 (08/97) | ISO/IEC 9594-1:1998,
- Information Technology - Open Systems Interconnection - The
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 25]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- Directory: Overview of concepts, models and services
-
- [X511] - ITU-T Recommendation X.511 (08/97) | ISO/IEC 9594-3:1998,
- Information Technology - Open Systems Interconnection - The
- Directory: Abstract service definition
-
- [BCP-11] - R. Hovey, S. Bradner, "The Organizations Involved in the
- IETF Standards Process", BCP 11, RFC 2028, October 1996.
-
-
- 9. Intellectual Property Notice
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property 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; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. [BCP-11]
- Copies of claims of rights made available for publication 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 implementors or users of this
- specification can be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
- 10. Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 26]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
- 11. Authors' Addresses
-
- Steven Legg
- Adacel Technologies Ltd.
- 250 Bay Street
- Brighton, Victoria 3186
- AUSTRALIA
-
- Phone: +61 3 8530 7808
- Fax: +61 3 9596 2960
- EMail: steven.legg@adacel.com.au
-
- Alison Payne
- Telstra
- 21/242 Exhibition Street
- Melbourne, Victoria 3000
- AUSTRALIA
-
- Phone: +61 3 9634 4628
- EMail: alison.payne@team.telstra.com
-
- 12. Appendix A - Changes From Previous Drafts
-
- 12.1 Changes in Draft 01
-
- Some of the terminology has been changed to better align with the
- terminology used in the LDUP architecture draft.
-
- Descriptions on the usage of CSNs have been revised to account for
- the extra modification number component.
-
- The semantics of re-added entries has been simplified so that only
- changes after the latest re-add are preserved instead of all those
- after the earliest re-add. This eliminates the need for Addition
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 27]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- CSNs in the entry. It is anticipated that new replication primitives
- will be introduced to manage entries that come and go from partial
- replicas instead of using p-add-entry and p-remove-entry.
-
- Orphaned entries are no longer moved directly to Lost & Found.
- Instead a glue entry is created in Lost & Found for the missing
- superior and the orphaned entry becomes a subordinate of that. This
- change eliminates the need for explicit propagated primitives for
- moving orphaned entries to Lost & Found.
-
- Glue entries have also been used as the mechanism for saving
- primitives. There are no longer any references to saved primitives
- though the functionality is still present.
-
- The procedures for processing received replication primitives have
- been rearranged to follow a more consistent pattern where the
- presence of deletion records is tested first.
-
- 12.2 Changes in Draft 02
-
- Multimaster replication has been dropped as a work item for the next
- edition of X.500 so references to the proposed X.500 multimaster
- replication protocol have been removed.
-
- The treatment of distinguished values has been simplified.
- Previously an attempt to remove a distinguished value caused the
- value to be tagged distinguished-not-present. Now the distinguished
- value is removed, and if necessary, the Unique Identifier is made
- distinguished to avoid an empty RDN. Optionally, the value to be
- removed can be reasserted by emitting an explicit p-add-attribute-
- value primitive.
-
- The current draft is more implementation neutral. A replication log
- no longer figures prominently in the specification. The previous
- descriptions had the user updates generating replication primitives,
- which in turn were used to determine the CSNs and deletion records.
- The new descriptions have user updates generating CSNs and deletion
- records and the primitives are subsequently generated from them.
-
- 12.3 Changes in Draft 03
-
- The draft has been edited to make use of the key words "MUST",
- "SHOULD", "MAY", etc.
-
- The treatment of server maintained operational attributes has been
- clarified.
-
- An extra CheckUniqueness call has been added to the procedure for
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 28]
-\f
-INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000
-
-
- processing the p-add-entry primitive (Section 5.3.9) to cover the
- case where an entry is re-added. A loop through all of the values of
- an entry in the p-add-entry and p-remove-entry processing has been
- altered to explicitly skip the entryUUID operational attribute. No
- other changes have been made to the behaviour of the Update
- Reconciliation Procedures from Draft 02.
-
- The list of references has been expanded.
-
- The Security Considerations section has been added.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Legg & Payne Expires 29 December 2000 [Page 29]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group Paul J. Leach, Microsoft
-INTERNET-DRAFT Rich Salz, Certco
-<draft-leach-uuids-guids-01.txt>
-Category: Standards Track
-Expires August 4, 1998 February 4, 1998
-
-
-
- UUIDs and GUIDs
-
-STATUS OF THIS MEMO
-
- This document is an Internet-Draft. Internet-Drafts are working
- documents of the Internet Engineering Task Force (IETF), its areas,
- and its working groups. Note that other groups may also distribute
- working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- To learn the current status of any Internet-Draft, please check the
- "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
- Distribution of this document is unlimited. Please send comments to
- the authors or the CIFS mailing list at <cifs@discuss.microsoft.com>.
- Discussions of the mailing list are archived at
- <URL:http://discuss.microsoft.com/archives/index.
-
-
-ABSTRACT
-
- This specification defines the format of UUIDs (Universally Unique
- IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID
- is 128 bits long, and if generated according to the one of the
- mechanisms in this document, is either guaranteed to be different
- from all other UUIDs/GUIDs generated until 3400 A.D. or extremely
- likely to be different (depending on the mechanism chosen). UUIDs
- were originally used in the Network Computing System (NCS) [1] and
- later in the Open Software Foundation's (OSF) Distributed Computing
- Environment [2].
-
- This specification is derived from the latter specification with the
- kind permission of the OSF.
-
-
-Table of Contents
-
-1. Introduction .......................................................3
-
-
-[Page 1]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-2. Motivation .........................................................3
-
-3. Specification ......................................................3
-
- 3.1 Format............................................................4
-
- 3.1.1 Variant......................................................4
-
- 3.1.2 UUID layout..................................................5
-
- 3.1.3 Version......................................................5
-
- 3.1.4 Timestamp....................................................6
-
- 3.1.5 Clock sequence...............................................6
-
- 3.1.6 Node.........................................................7
-
- 3.1.7 Nil UUID.....................................................7
-
- 3.2 Algorithms for creating a time-based UUID.........................7
-
- 3.2.1 Basic algorithm..............................................7
-
- 3.2.2 Reading stable storage.......................................8
-
- 3.2.3 System clock resolution......................................8
-
- 3.2.4 Writing stable storage.......................................9
-
- 3.2.5 Sharing state across processes...............................9
-
- 3.2.6 UUID Generation details......................................9
-
- 3.3 Algorithm for creating a name-based UUID.........................10
-
- 3.4 Algorithms for creating a UUID from truly random or pseudo-random
- numbers .............................................................11
-
- 3.5 String Representation of UUIDs...................................12
-
- 3.6 Comparing UUIDs for equality.....................................12
-
- 3.7 Comparing UUIDs for relative order...............................13
-
- 3.8 Byte order of UUIDs..............................................13
-
-4. Node IDs when no IEEE 802 network card is available ...............14
-
-5. Obtaining IEEE 802 addresses ......................................15
-
-6. Security Considerations ...........................................15
-
-7. Acknowledgements ..................................................15
-
- Leach, Salz expires Aug 1998 [Page 2]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-8. References ........................................................15
-
-9. Authors' addresses ................................................16
-
-10.Notice ............................................................16
-
-11.Full Copyright Statement ..........................................16
-
-Appendix A _ UUID Sample Implementation...............................17
-
-Appendix B _ Sample output of utest...................................27
-
-Appendix C _ Some name space IDs......................................27
-
-
-
-
-1. Introduction
-
- This specification defines the format of UUIDs (Universally Unique
- IDentifiers), also known as GUIDs (Globally Unique IDentifiers). A
- UUID is 128 bits long, and if generated according to the one of the
- mechanisms in this document, is either guaranteed to be different
- from all other UUIDs/GUIDs generated until 3400 A.D. or extremely
- likely to be different (depending on the mechanism chosen).
-
-
-2. Motivation
-
- One of the main reasons for using UUIDs is that no centralized
- authority is required to administer them (beyond the one that
- allocates IEEE 802.1 node identifiers). As a result, generation on
- demand can be completely automated, and they can be used for a wide
- variety of purposes. The UUID generation algorithm described here
- supports very high allocation rates: 10 million per second per
- machine if you need it, so that they could even be used as
- transaction IDs.
-
- UUIDs are fixed-size (128-bits) which is reasonably small relative to
- other alternatives. This fixed, relatively small size lends itself
- well to sorting, ordering, and hashing of all sorts, storing in
- databases, simple allocation, and ease of programming in general.
-
-
-3. Specification
-
- A UUID is an identifier that is unique across both space and time,
- with respect to the space of all UUIDs. To be precise, the UUID
- consists of a finite bit space. Thus the time value used for
- constructing a UUID is limited and will roll over in the future
- (approximately at A.D. 3400, based on the specified algorithm). A
- UUID can be used for multiple purposes, from tagging objects with an
- extremely short lifetime, to reliably identifying very persistent
- objects across a network.
-
- Leach, Salz expires Aug 1998 [Page 3]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- The generation of UUIDs does not require that a registration
- authority be contacted for each identifier. Instead, it requires a
- unique value over space for each UUID generator. This spatially
- unique value is specified as an IEEE 802 address, which is usually
- already available to network-connected systems. This 48-bit address
- can be assigned based on an address block obtained through the IEEE
- registration authority. This section of the UUID specification
- assumes the availability of an IEEE 802 address to a system desiring
- to generate a UUID, but if one is not available section 4 specifies a
- way to generate a probabilistically unique one that can not conflict
- with any properly assigned IEEE 802 address.
-
-
-3.1 Format
-
- In its most general form, all that can be said of the UUID format is
- that a UUID is 16 octets, and that some bits of octet 8 of the UUID
- called the variant field (specified in the next section) determine
- finer structure.
-
-
-3.1.1 Variant
- The variant field determines the layout of the UUID. That is, the
- interpretation of all other bits in the UUID depends on the setting
- of the bits in the variant field. The variant field consists of a
- variable number of the msbs of octet 8 of the UUID.
-
- The following table lists the contents of the variant field.
-
- Msb0 Msb1 Msb2 Description
-
- 0 - - Reserved, NCS backward compatibility.
-
- 1 0 - The variant specified in this document.
-
- 1 1 0 Reserved, Microsoft Corporation backward
- compatibility
-
- 1 1 1 Reserved for future definition.
-
-
-
- Other UUID variants may not interoperate with the UUID variant
- specified in this document, where interoperability is defined as the
- applicability of operations such as string conversion and lexical
- ordering across different systems. However, UUIDs allocated according
- to the stricture of different variants, though they may define
- different interpretations of the bits outside the variant field, will
- not result in duplicate UUID allocation, because of the differing
- values of the variant field itself.
-
- The remaining fields described below (version, timestamp, etc.) are
- defined only for the UUID variant noted above.
-
-
- Leach, Salz expires Aug 1998 [Page 4]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-3.1.2 UUID layout
- The following table gives the format of a UUID for the variant
- specified herein. The UUID consists of a record of 16 octets. To
- minimize confusion about bit assignments within octets, the UUID
- record definition is defined only in terms of fields that are
- integral numbers of octets. The fields are in order of significance
- for comparison purposes, with "time_low" the most significant, and
- "node" the least significant.
-
- Field Data Type Octet Note
- #
-
- time_low unsigned 32 0-3 The low field of the
- bit integer timestamp.
-
- time_mid unsigned 16 4-5 The middle field of the
- bit integer timestamp.
-
- time_hi_and_version unsigned 16 6-7 The high field of the
- bit integer timestamp multiplexed
- with the version number.
-
- clock_seq_hi_and_rese unsigned 8 8 The high field of the
- rved bit integer clock sequence
- multiplexed with the
- variant.
-
- clock_seq_low unsigned 8 9 The low field of the
- bit integer clock sequence.
-
- node unsigned 48 10-15 The spatially unique
- bit integer node identifier.
-
-
-
-
-3.1.3 Version
- The version number is in the most significant 4 bits of the time
- stamp (time_hi_and_version).
-
- The following table lists currently defined versions of the UUID.
-
- Msb0 Msb1 Msb2 Msb3 Version Description
-
- 0 0 0 1 1 The time-based version
- specified in this
- document.
-
- 0 0 1 0 2 Reserved for DCE
- Security version, with
- embedded POSIX UIDs.
-
- 0 0 1 1 3 The name-based version
- specified in this
-
- Leach, Salz expires Aug 1998 [Page 5]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- document
-
- 0 1 0 0 4 The randomly or pseudo-
- randomly generated
- version specified in
- this document
-
-
-3.1.4 Timestamp
- The timestamp is a 60 bit value. For UUID version 1, this is
- represented by Coordinated Universal Time (UTC) as a count of 100-
- nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of
- Gregorian reform to the Christian calendar).
-
- For systems that do not have UTC available, but do have local time,
- they MAY use local time instead of UTC, as long as they do so
- consistently throughout the system. This is NOT RECOMMENDED, however,
- and it should be noted that all that is needed to generate UTC, given
- local time, is a time zone offset.
-
- For UUID version 3, it is a 60 bit value constructed from a name.
-
- For UUID version 4, it is a randomly or pseudo-randomly generated 60
- bit value.
-
-
-3.1.5 Clock sequence
- For UUID version 1, the clock sequence is used to help avoid
- duplicates that could arise when the clock is set backwards in time
- or if the node ID changes.
-
- If the clock is set backwards, or even might have been set backwards
- (e.g., while the system was powered off), and the UUID generator can
- not be sure that no UUIDs were generated with timestamps larger than
- the value to which the clock was set, then the clock sequence has to
- be changed. If the previous value of the clock sequence is known, it
- can be just incremented; otherwise it should be set to a random or
- high-quality pseudo random value.
-
- Similarly, if the node ID changes (e.g. because a network card has
- been moved between machines), setting the clock sequence to a random
- number minimizes the probability of a duplicate due to slight
- differences in the clock settings of the machines. (If the value of
- clock sequence associated with the changed node ID were known, then
- the clock sequence could just be incremented, but that is unlikely.)
-
- The clock sequence MUST be originally (i.e., once in the lifetime of
- a system) initialized to a random number to minimize the correlation
- across systems. This provides maximum protection against node
- identifiers that may move or switch from system to system rapidly.
- The initial value MUST NOT be correlated to the node identifier.
-
- For UUID version 3, it is a 14 bit value constructed from a name.
-
-
- Leach, Salz expires Aug 1998 [Page 6]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- For UUID version 4, it is a randomly or pseudo-randomly generated 14
- bit value.
-
-
-3.1.6 Node
- For UUID version 1, the node field consists of the IEEE address,
- usually the host address. For systems with multiple IEEE 802
- addresses, any available address can be used. The lowest addressed
- octet (octet number 10) contains the global/local bit and the
- unicast/multicast bit, and is the first octet of the address
- transmitted on an 802.3 LAN.
-
- For systems with no IEEE address, a randomly or pseudo-randomly
- generated value may be used (see section 4). The multicast bit must
- be set in such addresses, in order that they will never conflict with
- addresses obtained from network cards.
-
- For UUID version 3, the node field is a 48 bit value constructed from
- a name.
-
- For UUID version 4, the node field is a randomly or pseudo-randomly
- generated 48 bit value.
-
-
-3.1.7 Nil UUID
- The nil UUID is special form of UUID that is specified to have all
- 128 bits set to 0 (zero).
-
-
-3.2 Algorithms for creating a time-based UUID
-
- Various aspects of the algorithm for creating a version 1 UUID are
- discussed in the following sections. UUID generation requires a
- guarantee of uniqueness within the node ID for a given variant and
- version. Interoperability is provided by complying with the specified
- data structure.
-
-
-3.2.1 Basic algorithm
- The following algorithm is simple, correct, and inefficient:
-
- . Obtain a system wide global lock
-
- . From a system wide shared stable store (e.g., a file), read the
- UUID generator state: the values of the time stamp, clock sequence,
- and node ID used to generate the last UUID.
-
- . Get the current time as a 60 bit count of 100-nanosecond intervals
- since 00:00:00.00, 15 October 1582
-
- . Get the current node ID
-
-
-
-
- Leach, Salz expires Aug 1998 [Page 7]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- . If the state was unavailable (non-existent or corrupted), or the
- saved node ID is different than the current node ID, generate a
- random clock sequence value
-
- . If the state was available, but the saved time stamp is later than
- the current time stamp, increment the clock sequence value
-
- . Format a UUID from the current time stamp, clock sequence, and node
- ID values according to the structure in section 3.1 (see section
- 3.2.6 for more details)
-
- . Save the state (current time stamp, clock sequence, and node ID)
- back to the stable store
-
- . Release the system wide global lock
-
- If UUIDs do not need to be frequently generated, the above algorithm
- may be perfectly adequate. For higher performance requirements,
- however, issues with the basic algorithm include:
-
- . Reading the state from stable storage each time is inefficient
-
- . The resolution of the system clock may not be 100-nanoseconds
-
- . Writing the state to stable storage each time is inefficient
-
- . Sharing the state across process boundaries may be inefficient
-
- Each of these issues can be addressed in a modular fashion by local
- improvements in the functions that read and write the state and read
- the clock. We address each of them in turn in the following sections.
-
-
-3.2.2 Reading stable storage
- The state only needs to be read from stable storage once at boot
- time, if it is read into a system wide shared volatile store (and
- updated whenever the stable store is updated).
-
- If an implementation does not have any stable store available, then
- it can always say that the values were unavailable. This is the least
- desirable implementation, because it will increase the frequency of
- creation of new clock sequence numbers, which increases the
- probability of duplicates.
-
- If the node ID can never change (e.g., the net card is inseparable
- from the system), or if any change also reinitializes the clock
- sequence to a random value, then instead of keeping it in stable
- store, the current node ID may be returned.
-
-
-3.2.3 System clock resolution
- The time stamp is generated from the system time, whose resolution
- may be less than the resolution of the UUID time stamp.
-
-
- Leach, Salz expires Aug 1998 [Page 8]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- If UUIDs do not need to be frequently generated, the time stamp can
- simply be the system time multiplied by the number of 100-nanosecond
- intervals per system time interval.
-
- If a system overruns the generator by requesting too many UUIDs
- within a single system time interval, the UUID service MUST either:
- return an error, or stall the UUID generator until the system clock
- catches up.
-
- A high resolution time stamp can be simulated by keeping a count of
- how many UUIDs have been generated with the same value of the system
- time, and using it to construction the low-order bits of the time
- stamp. The count will range between zero and the number of 100-
- nanosecond intervals per system time interval.
-
- Note: if the processors overrun the UUID generation frequently,
- additional node identifiers can be allocated to the system, which
- will permit higher speed allocation by making multiple UUIDs
- potentially available for each time stamp value.
-
-
-3.2.4 Writing stable storage
- The state does not always need to be written to stable store every
- time a UUID is generated. The timestamp in the stable store can be
- periodically set to a value larger than any yet used in a UUID; as
- long as the generated UUIDs have time stamps less than that value,
- and the clock sequence and node ID remain unchanged, only the shared
- volatile copy of the state needs to be updated. Furthermore, if the
- time stamp value in stable store is in the future by less than the
- typical time it takes the system to reboot, a crash will not cause a
- reinitialization of the clock sequence.
-
-
-3.2.5 Sharing state across processes
- If it is too expensive to access shared state each time a UUID is
- generated, then the system wide generator can be implemented to
- allocate a block of time stamps each time it is called, and a per-
- process generator can allocate from that block until it is exhausted.
-
-
-3.2.6 UUID Generation details
- UUIDs are generated according to the following algorithm:
-
- - Determine the values for the UTC-based timestamp and clock sequence
- to be used in the UUID, as described above.
-
- - For the purposes of this algorithm, consider the timestamp to be a
- 60-bit unsigned integer and the clock sequence to be a 14-bit
- unsigned integer. Sequentially number the bits in a field, starting
- from 0 (zero) for the least significant bit.
-
- - Set the time_low field equal to the least significant 32-bits (bits
- numbered 0 to 31 inclusive) of the time stamp in the same order of
- significance.
-
- Leach, Salz expires Aug 1998 [Page 9]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- - Set the time_mid field equal to the bits numbered 32 to 47
- inclusive of the time stamp in the same order of significance.
-
- - Set the 12 least significant bits (bits numbered 0 to 11 inclusive)
- of the time_hi_and_version field equal to the bits numbered 48 to 59
- inclusive of the time stamp in the same order of significance.
-
- - Set the 4 most significant bits (bits numbered 12 to 15 inclusive)
- of the time_hi_and_version field to the 4-bit version number
- corresponding to the UUID version being created, as shown in the
- table in section 3.1.3.
-
- - Set the clock_seq_low field to the 8 least significant bits (bits
- numbered 0 to 7 inclusive) of the clock sequence in the same order of
- significance.
-
- - Set the 6 least significant bits (bits numbered 0 to 5 inclusive)
- of the clock_seq_hi_and_reserved field to the 6 most significant bits
- (bits numbered 8 to 13 inclusive) of the clock sequence in the same
- order of significance.
-
- - Set the 2 most significant bits (bits numbered 6 and 7) of the
- clock_seq_hi_and_reserved to 0 and 1, respectively.
-
- - Set the node field to the 48-bit IEEE address in the same order of
- significance as the address.
-
-
-3.3 Algorithm for creating a name-based UUID
-
- The version 3 UUID is meant for generating UUIDs from "names" that
- are drawn from, and unique within, some "name space". Some examples
- of names (and, implicitly, name spaces) might be DNS names, URLs, ISO
- Object IDs (OIDs), reserved words in a programming language, or X.500
- Distinguished Names (DNs); thus, the concept of name and name space
- should be broadly construed, and not limited to textual names. The
- mechanisms or conventions for allocating names from, and ensuring
- their uniqueness within, their name spaces are beyond the scope of
- this specification.
-
- The requirements for such UUIDs are as follows:
-
- . The UUIDs generated at different times from the same name in the
- same namespace MUST be equal
-
- . The UUIDs generated from two different names in the same namespace
- should be different (with very high probability)
-
- . The UUIDs generated from the same name in two different namespaces
- should be different with (very high probability)
-
- . If two UUIDs that were generated from names are equal, then they
- were generated from the same name in the same namespace (with very
- high probability).
-
- Leach, Salz expires Aug 1998 [Page 10]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- The algorithm for generating the a UUID from a name and a name space
- are as follows:
-
- . Allocate a UUID to use as a "name space ID" for all UUIDs generated
- from names in that name space
-
- . Convert the name to a canonical sequence of octets (as defined by
- the standards or conventions of its name space); put the name space
- ID in network byte order
-
- . Compute the MD5 [3] hash of the name space ID concatenated with the
- name
-
- . Set octets 0-3 of time_low field to octets 0-3 of the MD5 hash
-
- . Set octets 0-1 of time_mid field to octets 4-5 of the MD5 hash
-
- . Set octets 0-1 of time_hi_and_version field to octets 6-7 of the
- MD5 hash
-
- . Set the clock_seq_hi_and_reserved field to octet 8 of the MD5 hash
-
- . Set the clock_seq_low field to octet 9 of the MD5 hash
-
- . Set octets 0-5 of the node field to octets 10-15 of the MD5 hash
-
- . Set the 2 most significant bits (bits numbered 6 and 7) of the
- clock_seq_hi_and_reserved to 0 and 1, respectively.
-
- . Set the 4 most significant bits (bits numbered 12 to 15 inclusive)
- of the time_hi_and_version field to the 4-bit version number
- corresponding to the UUID version being created, as shown in the
- table above.
-
- . Convert the resulting UUID to local byte order.
-
-
-3.4 Algorithms for creating a UUID from truly random or pseudo-random
-numbers
-
- The version 4 UUID is meant for generating UUIDs from truly-random or
- pseudo-random numbers.
-
- The algorithm is as follows:
-
- . Set the 2 most significant bits (bits numbered 6 and 7) of the
- clock_seq_hi_and_reserved to 0 and 1, respectively.
-
- . Set the 4 most significant bits (bits numbered 12 to 15 inclusive)
- of the time_hi_and_version field to the 4-bit version number
- corresponding to the UUID version being created, as shown in the
- table above.
-
-
-
- Leach, Salz expires Aug 1998 [Page 11]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- . Set all the other bits to randomly (or pseudo-randomly) chosen
- values.
-
- Here are several possible ways to generate the random values:
-
- . Use a physical source of randomness: for example, a white noise
- generator, radioactive decay, or a lava lamp.
-
- . Use a cryptographic strength random number generator.
-
-
-3.5 String Representation of UUIDs
-
- For use in human readable text, a UUID string representation is
- specified as a sequence of fields, some of which are separated by
- single dashes.
-
- Each field is treated as an integer and has its value printed as a
- zero-filled hexadecimal digit string with the most significant digit
- first. The hexadecimal values a to f inclusive are output as lower
- case characters, and are case insensitive on input. The sequence is
- the same as the UUID constructed type.
-
- The formal definition of the UUID string representation is provided
- by the following extended BNF:
-
- UUID = <time_low> "-" <time_mid> "-"
- <time_high_and_version> "-"
- <clock_seq_and_reserved>
- <clock_seq_low> "-" <node>
- time_low = 4*<hexOctet>
- time_mid = 2*<hexOctet>
- time_high_and_version = 2*<hexOctet>
- clock_seq_and_reserved = <hexOctet>
- clock_seq_low = <hexOctet>
- node = 6*<hexOctet
- hexOctet = <hexDigit> <hexDigit>
- hexDigit =
- "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
- | "a" | "b" | "c" | "d" | "e" | "f"
- | "A" | "B" | "C" | "D" | "E" | "F"
-
- The following is an example of the string representation of a UUID:
-
- f81d4fae-7dec-11d0-a765-00a0c91e6bf6
-
-3.6 Comparing UUIDs for equality
-
- Consider each field of the UUID to be an unsigned integer as shown in
- the table in section 3.1. Then, to compare a pair of UUIDs,
- arithmetically compare the corresponding fields from each UUID in
- order of significance and according to their data type. Two UUIDs are
- equal if and only if all the corresponding fields are equal.
-
-
- Leach, Salz expires Aug 1998 [Page 12]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- Note: as a practical matter, on many systems comparison of two UUIDs
- for equality can be performed simply by comparing the 128 bits of
- their in-memory representation considered as a 128 bit unsigned
- integer. Here, it is presumed that by the time the in-memory
- representation is obtained the appropriate byte-order
- canonicalizations have been carried out.
-
-
-3.7 Comparing UUIDs for relative order
-
- Two UUIDs allocated according to the same variant can also be ordered
- lexicographically. For the UUID variant herein defined, the first of
- two UUIDs follows the second if the most significant field in which
- the UUIDs differ is greater for the first UUID. The first of a pair
- of UUIDs precedes the second if the most significant field in which
- the UUIDs differ is greater for the second UUID.
-
-
-3.8 Byte order of UUIDs
-
- UUIDs may be transmitted in many different forms, some of which may
- be dependent on the presentation or application protocol where the
- UUID may be used. In such cases, the order, sizes and byte orders of
- the UUIDs fields on the wire will depend on the relevant presentation
- or application protocol. However, it is strongly RECOMMENDED that
- the order of the fields conform with ordering set out in section 3.1
- above. Furthermore, the payload size of each field in the application
- or presentation protocol MUST be large enough that no information
- lost in the process of encoding them for transmission.
-
- In the absence of explicit application or presentation protocol
- specification to the contrary, a UUID is encoded as a 128-bit object,
- as follows: the fields are encoded as 16 octets, with the sizes and
- order of the fields defined in section 3.1, and with each field
- encoded with the Most Significant Byte first (also known as network
- byte order).
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | time_low |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | time_mid | time_hi_and_version |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |clk_seq_hi_res | clk_seq_low | node (0-1) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | node (2-5) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
- Leach, Salz expires Aug 1998 [Page 13]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-4. Node IDs when no IEEE 802 network card is available
-
- If a system wants to generate UUIDs but has no IEE 802 compliant
- network card or other source of IEEE 802 addresses, then this section
- describes how to generate one.
-
- The ideal solution is to obtain a 47 bit cryptographic quality random
- number, and use it as the low 47 bits of the node ID, with the most
- significant bit of the first octet of the node ID set to 1. This bit
- is the unicast/multicast bit, which will never be set in IEEE 802
- addresses obtained from network cards; hence, there can never be a
- conflict between UUIDs generated by machines with and without network
- cards.
-
- If a system does not have a primitive to generate cryptographic
- quality random numbers, then in most systems there are usually a
- fairly large number of sources of randomness available from which one
- can be generated. Such sources are system specific, but often
- include:
-
- - the percent of memory in use
- - the size of main memory in bytes
- - the amount of free main memory in bytes
- - the size of the paging or swap file in bytes
- - free bytes of paging or swap file
- - the total size of user virtual address space in bytes
- - the total available user address space bytes
- - the size of boot disk drive in bytes
- - the free disk space on boot drive in bytes
- - the current time
- - the amount of time since the system booted
- - the individual sizes of files in various system directories
- - the creation, last read, and modification times of files in various
- system directories
- - the utilization factors of various system resources (heap, etc.)
- - current mouse cursor position
- - current caret position
- - current number of running processes, threads
- - handles or IDs of the desktop window and the active window
- - the value of stack pointer of the caller
- - the process and thread ID of caller
- - various processor architecture specific performance counters
- (instructions executed, cache misses, TLB misses)
-
- (Note that it precisely the above kinds of sources of randomness that
- are used to seed cryptographic quality random number generators on
- systems without special hardware for their construction.)
-
- In addition, items such as the computer's name and the name of the
- operating system, while not strictly speaking random, will help
- differentiate the results from those obtained by other systems.
-
- The exact algorithm to generate a node ID using these data is system
- specific, because both the data available and the functions to obtain
-
- Leach, Salz expires Aug 1998 [Page 14]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- them are often very system specific. However, assuming that one can
- concatenate all the values from the randomness sources into a buffer,
- and that a cryptographic hash function such as MD5 [3] is available,
- then any 6 bytes of the MD5 hash of the buffer, with the multicast
- bit (the high bit of the first byte) set will be an appropriately
- random node ID.
-
- Other hash functions, such as SHA-1 [4], can also be used. The only
- requirement is that the result be suitably random _ in the sense that
- the outputs from a set uniformly distributed inputs are themselves
- uniformly distributed, and that a single bit change in the input can
- be expected to cause half of the output bits to change.
-
-
-5. Obtaining IEEE 802 addresses
-
- At the time of writing, the following URL
-
- http://standards.ieee.org/db/oui/forms/
-
- contains information on how to obtain an IEEE 802 address block. At
- the time of writing, the cost is $1250 US.
-
-
-6. Security Considerations
-
- It should not be assumed that UUIDs are hard to guess; they should
- not be used as capabilities.
-
-
-7. Acknowledgements
-
- This document draws heavily on the OSF DCE specification for UUIDs.
- Ted Ts'o provided helpful comments, especially on the byte ordering
- section which we mostly plagiarized from a proposed wording he
- supplied (all errors in that section are our responsibility,
- however).
-
-
-8. References
-
- [1] Lisa Zahn, et. al., Network Computing Architecture, Prentice
- Hall, Englewood Cliffs, NJ, 1990
-
- [2] DCE: Remote Procedure Call, Open Group CAE Specification C309
- ISBN 1-85912-041-5 28cm. 674p. pbk. 1,655g. 8/94
-
- [3] R. Rivest, RFC 1321, "The MD5 Message-Digest Algorithm",
- 04/16/1992.
-
- [4] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute
- of Standards and Technology, U.S. Department of Commerce, DRAFT, May
- 31, 1994.
-
-
- Leach, Salz expires Aug 1998 [Page 15]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-9. Authors' addresses
-
- Paul J. Leach
- Microsoft
- 1 Microsoft Way
- Redmond, WA, 98052, U.S.A.
- paulle@microsoft.com
- Tel. 425 882 8080
- Fax. 425 936 7329
-
- Rich Salz
- 100 Cambridge Park Drive
- Cambridge MA 02140
- salzr@certco.com
- Tel. 617 499 4075
- Fax. 617 576 0019
-
-
-10. Notice
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property 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; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society 1997. All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
-
- Leach, Salz expires Aug 1998 [Page 16]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
- Appendix A _ UUID Sample Implementation
-
- This implementation consists of 5 files: uuid.h, uuid.c, sysdep.h,
- sysdep.c and utest.c. The uuid.* files are the system independent
- implementation of the UUID generation algorithms described above,
- with all the optimizations described above except efficient state
- sharing across processes included. The code has been tested on Linux
- (Red Hat 4.0) with GCC (2.7.2), and Windows NT 4.0 with VC++ 5.0. The
- code assumes 64 bit integer support, which makes it a lot clearer.
-
- All the following source files should be considered to have the
- following copyright notice included:
-
- copyrt.h
-
- /*
- ** Copyright (c) 1990- 1993, 1996 Open Software Foundation, Inc.
- ** Copyright (c) 1989 by Hewlett-Packard Company, Palo Alto, Ca. &
- ** Digital Equipment Corporation, Maynard, Mass.
- ** Copyright (c) 1998 Microsoft.
- ** To anyone who acknowledges that this file is provided "AS IS"
- ** without any express or implied warranty: permission to use, copy,
- ** modify, and distribute this file for any purpose is hereby
- ** granted without fee, provided that the above copyright notices and
- ** this notice appears in all source code copies, and that none of
- ** the names of Open Software Foundation, Inc., Hewlett-Packard
- ** Company, or Digital Equipment Corporation be used in advertising
- ** or publicity pertaining to distribution of the software without
- ** specific, written prior permission. Neither Open Software
- ** Foundation, Inc., Hewlett-Packard Company, Microsoft, nor Digital
- Equipment
- ** Corporation makes any representations about the suitability of
- ** this software for any purpose.
- */
-
-
- uuid.h
-
-
- Leach, Salz expires Aug 1998 [Page 17]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- #include "copyrt.h"
- #undef uuid_t
- typedef struct _uuid_t {
- unsigned32 time_low;
- unsigned16 time_mid;
- unsigned16 time_hi_and_version;
- unsigned8 clock_seq_hi_and_reserved;
- unsigned8 clock_seq_low;
- byte node[6];
- } uuid_t;
-
- /* uuid_create -- generate a UUID */
- int uuid_create(uuid_t * uuid);
-
- /* uuid_create_from_name -- create a UUID using a "name"
- from a "name space" */
- void uuid_create_from_name(
- uuid_t * uuid, /* resulting UUID */
- uuid_t nsid, /* UUID to serve as context, so identical
- names from different name spaces generate
- different UUIDs */
- void * name, /* the name from which to generate a UUID */
- int namelen /* the length of the name */
- );
-
- /* uuid_compare -- Compare two UUID's "lexically" and return
- -1 u1 is lexically before u2
- 0 u1 is equal to u2
- 1 u1 is lexically after u2
- Note: lexical ordering is not temporal ordering!
- */
- int uuid_compare(uuid_t *u1, uuid_t *u2);
-
- uuid.c
-
- #include "copyrt.h"
- #include <string.h>
- #include <stdio.h>
- #include <stdlib.h>
- #include <time.h>
- #include "sysdep.h"
- #include "uuid.h"
-
- /* various forward declarations */
- static int read_state(unsigned16 *clockseq, uuid_time_t *timestamp,
- uuid_node_t * node);
- static void write_state(unsigned16 clockseq, uuid_time_t timestamp,
- uuid_node_t node);
- static void format_uuid_v1(uuid_t * uuid, unsigned16 clockseq,
- uuid_time_t timestamp, uuid_node_t node);
- static void format_uuid_v3(uuid_t * uuid, unsigned char hash[16]);
- static void get_current_time(uuid_time_t * timestamp);
- static unsigned16 true_random(void);
-
-
- Leach, Salz expires Aug 1998 [Page 18]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- /* uuid_create -- generator a UUID */
- int uuid_create(uuid_t * uuid) {
- uuid_time_t timestamp, last_time;
- unsigned16 clockseq;
- uuid_node_t node;
- uuid_node_t last_node;
- int f;
-
- /* acquire system wide lock so we're alone */
- LOCK;
-
- /* get current time */
- get_current_time(×tamp);
-
- /* get node ID */
- get_ieee_node_identifier(&node);
-
- /* get saved state from NV storage */
- f = read_state(&clockseq, &last_time, &last_node);
-
- /* if no NV state, or if clock went backwards, or node ID changed
- (e.g., net card swap) change clockseq */
- if (!f || memcmp(&node, &last_node, sizeof(uuid_node_t)))
- clockseq = true_random();
- else if (timestamp < last_time)
- clockseq++;
-
- /* stuff fields into the UUID */
- format_uuid_v1(uuid, clockseq, timestamp, node);
-
- /* save the state for next time */
- write_state(clockseq, timestamp, node);
-
- UNLOCK;
- return(1);
- };
-
- /* format_uuid_v1 -- make a UUID from the timestamp, clockseq,
- and node ID */
- void format_uuid_v1(uuid_t * uuid, unsigned16 clock_seq, uuid_time_t
- timestamp, uuid_node_t node) {
- /* Construct a version 1 uuid with the information we've gathered
- * plus a few constants. */
- uuid->time_low = (unsigned long)(timestamp & 0xFFFFFFFF);
- uuid->time_mid = (unsigned short)((timestamp >> 32) & 0xFFFF);
- uuid->time_hi_and_version = (unsigned short)((timestamp >> 48) &
- 0x0FFF);
- uuid->time_hi_and_version |= (1 << 12);
- uuid->clock_seq_low = clock_seq & 0xFF;
- uuid->clock_seq_hi_and_reserved = (clock_seq & 0x3F00) >> 8;
- uuid->clock_seq_hi_and_reserved |= 0x80;
- memcpy(&uuid->node, &node, sizeof uuid->node);
- };
-
-
- Leach, Salz expires Aug 1998 [Page 19]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- /* data type for UUID generator persistent state */
- typedef struct {
- uuid_time_t ts; /* saved timestamp */
- uuid_node_t node; /* saved node ID */
- unsigned16 cs; /* saved clock sequence */
- } uuid_state;
-
- static uuid_state st;
-
- /* read_state -- read UUID generator state from non-volatile store */
- int read_state(unsigned16 *clockseq, uuid_time_t *timestamp,
- uuid_node_t *node) {
- FILE * fd;
- static int inited = 0;
-
- /* only need to read state once per boot */
- if (!inited) {
- fd = fopen("state", "rb");
- if (!fd)
- return (0);
- fread(&st, sizeof(uuid_state), 1, fd);
- fclose(fd);
- inited = 1;
- };
- *clockseq = st.cs;
- *timestamp = st.ts;
- *node = st.node;
- return(1);
- };
-
- /* write_state -- save UUID generator state back to non-volatile
- storage */
- void write_state(unsigned16 clockseq, uuid_time_t timestamp,
- uuid_node_t node) {
- FILE * fd;
- static int inited = 0;
- static uuid_time_t next_save;
-
- if (!inited) {
- next_save = timestamp;
- inited = 1;
- };
- /* always save state to volatile shared state */
- st.cs = clockseq;
- st.ts = timestamp;
- st.node = node;
- if (timestamp >= next_save) {
- fd = fopen("state", "wb");
- fwrite(&st, sizeof(uuid_state), 1, fd);
- fclose(fd);
- /* schedule next save for 10 seconds from now */
- next_save = timestamp + (10 * 10 * 1000 * 1000);
- };
- };
-
- Leach, Salz expires Aug 1998 [Page 20]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-
- /* get-current_time -- get time as 60 bit 100ns ticks since whenever.
- Compensate for the fact that real clock resolution is
- less than 100ns. */
- void get_current_time(uuid_time_t * timestamp) {
- uuid_time_t time_now;
- static uuid_time_t time_last;
- static unsigned16 uuids_this_tick;
- static int inited = 0;
-
- if (!inited) {
- get_system_time(&time_now);
- uuids_this_tick = UUIDS_PER_TICK;
- inited = 1;
- };
-
- while (1) {
- get_system_time(&time_now);
-
- /* if clock reading changed since last UUID generated... */
- if (time_last != time_now) {
- /* reset count of uuids gen'd with this clock reading */
- uuids_this_tick = 0;
- break;
- };
- if (uuids_this_tick < UUIDS_PER_TICK) {
- uuids_this_tick++;
- break;
- };
- /* going too fast for our clock; spin */
- };
- /* add the count of uuids to low order bits of the clock reading */
- *timestamp = time_now + uuids_this_tick;
- };
-
- /* true_random -- generate a crypto-quality random number.
- This sample doesn't do that. */
- static unsigned16
- true_random(void)
- {
- static int inited = 0;
- uuid_time_t time_now;
-
- if (!inited) {
- get_system_time(&time_now);
- time_now = time_now/UUIDS_PER_TICK;
- srand((unsigned int)(((time_now >> 32) ^ time_now)&0xffffffff));
- inited = 1;
- };
-
- return (rand());
- }
-
-
-
- Leach, Salz expires Aug 1998 [Page 21]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- /* uuid_create_from_name -- create a UUID using a "name" from a "name
- space" */
- void uuid_create_from_name(
- uuid_t * uuid, /* resulting UUID */
- uuid_t nsid, /* UUID to serve as context, so identical
- names from different name spaces generate
- different UUIDs */
- void * name, /* the name from which to generate a UUID */
- int namelen /* the length of the name */
- ) {
- MD5_CTX c;
- unsigned char hash[16];
- uuid_t net_nsid; /* context UUID in network byte order */
-
- /* put name space ID in network byte order so it hashes the same
- no matter what endian machine we're on */
- net_nsid = nsid;
- htonl(net_nsid.time_low);
- htons(net_nsid.time_mid);
- htons(net_nsid.time_hi_and_version);
-
- MD5Init(&c);
- MD5Update(&c, &net_nsid, sizeof(uuid_t));
- MD5Update(&c, name, namelen);
- MD5Final(hash, &c);
-
- /* the hash is in network byte order at this point */
- format_uuid_v3(uuid, hash);
- };
-
- /* format_uuid_v3 -- make a UUID from a (pseudo)random 128 bit number
- */
- void format_uuid_v3(uuid_t * uuid, unsigned char hash[16]) {
- /* Construct a version 3 uuid with the (pseudo-)random number
- * plus a few constants. */
-
- memcpy(uuid, hash, sizeof(uuid_t));
-
- /* convert UUID to local byte order */
- ntohl(uuid->time_low);
- ntohs(uuid->time_mid);
- ntohs(uuid->time_hi_and_version);
-
- /* put in the variant and version bits */
- uuid->time_hi_and_version &= 0x0FFF;
- uuid->time_hi_and_version |= (3 << 12);
- uuid->clock_seq_hi_and_reserved &= 0x3F;
- uuid->clock_seq_hi_and_reserved |= 0x80;
- };
-
- /* uuid_compare -- Compare two UUID's "lexically" and return
- -1 u1 is lexically before u2
- 0 u1 is equal to u2
- 1 u1 is lexically after u2
-
- Leach, Salz expires Aug 1998 [Page 22]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- Note: lexical ordering is not temporal ordering!
- */
- int uuid_compare(uuid_t *u1, uuid_t *u2)
- {
- int i;
-
- #define CHECK(f1, f2) if (f1 != f2) return f1 < f2 ? -1 : 1;
- CHECK(u1->time_low, u2->time_low);
- CHECK(u1->time_mid, u2->time_mid);
- CHECK(u1->time_hi_and_version, u2->time_hi_and_version);
- CHECK(u1->clock_seq_hi_and_reserved, u2->clock_seq_hi_and_reserved);
- CHECK(u1->clock_seq_low, u2->clock_seq_low)
- for (i = 0; i < 6; i++) {
- if (u1->node[i] < u2->node[i])
- return -1;
- if (u1->node[i] > u2->node[i])
- return 1;
- }
- return 0;
- };
-
- sysdep.h
-
- #include "copyrt.h"
- /* remove the following define if you aren't running WIN32 */
- #define WININC 0
-
- #ifdef WININC
- #include <windows.h>
- #else
- #include <sys/types.h>
- #include <sys/time.h>
- #include <sys/sysinfo.h>
- #endif
-
- /* change to point to where MD5 .h's live */
- /* get MD5 sample implementation from RFC 1321 */
- #include "global.h"
- #include "md5.h"
-
- /* set the following to the number of 100ns ticks of the actual
- resolution of
- your system's clock */
- #define UUIDS_PER_TICK 1024
-
- /* Set the following to a call to acquire a system wide global lock
- */
- #define LOCK
- #define UNLOCK
-
- typedef unsigned long unsigned32;
- typedef unsigned short unsigned16;
- typedef unsigned char unsigned8;
- typedef unsigned char byte;
-
- Leach, Salz expires Aug 1998 [Page 23]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-
- /* Set this to what your compiler uses for 64 bit data type */
- #ifdef WININC
- #define unsigned64_t unsigned __int64
- #define I64(C) C
- #else
- #define unsigned64_t unsigned long long
- #define I64(C) C##LL
- #endif
-
-
- typedef unsigned64_t uuid_time_t;
- typedef struct {
- char nodeID[6];
- } uuid_node_t;
-
- void get_ieee_node_identifier(uuid_node_t *node);
- void get_system_time(uuid_time_t *uuid_time);
- void get_random_info(char seed[16]);
-
-
- sysdep.c
-
- #include "copyrt.h"
- #include <stdio.h>
- #include "sysdep.h"
-
- /* system dependent call to get IEEE node ID.
- This sample implementation generates a random node ID
- */
- void get_ieee_node_identifier(uuid_node_t *node) {
- char seed[16];
- FILE * fd;
- static inited = 0;
- static uuid_node_t saved_node;
-
- if (!inited) {
- fd = fopen("nodeid", "rb");
- if (fd) {
- fread(&saved_node, sizeof(uuid_node_t), 1, fd);
- fclose(fd);
- }
- else {
- get_random_info(seed);
- seed[0] |= 0x80;
- memcpy(&saved_node, seed, sizeof(uuid_node_t));
- fd = fopen("nodeid", "wb");
- if (fd) {
- fwrite(&saved_node, sizeof(uuid_node_t), 1, fd);
- fclose(fd);
- };
- };
- inited = 1;
- };
-
- Leach, Salz expires Aug 1998 [Page 24]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- *node = saved_node;
- };
-
- /* system dependent call to get the current system time.
- Returned as 100ns ticks since Oct 15, 1582, but resolution may be
- less than 100ns.
- */
- #ifdef _WINDOWS_
-
- void get_system_time(uuid_time_t *uuid_time) {
- ULARGE_INTEGER time;
-
- GetSystemTimeAsFileTime((FILETIME *)&time);
-
- /* NT keeps time in FILETIME format which is 100ns ticks since
- Jan 1, 1601. UUIDs use time in 100ns ticks since Oct 15, 1582.
- The difference is 17 Days in Oct + 30 (Nov) + 31 (Dec)
- + 18 years and 5 leap days.
- */
-
- time.QuadPart +=
- (unsigned __int64) (1000*1000*10) // seconds
- * (unsigned __int64) (60 * 60 * 24) // days
- * (unsigned __int64) (17+30+31+365*18+5); // # of days
-
- *uuid_time = time.QuadPart;
-
- };
-
- void get_random_info(char seed[16]) {
- MD5_CTX c;
- typedef struct {
- MEMORYSTATUS m;
- SYSTEM_INFO s;
- FILETIME t;
- LARGE_INTEGER pc;
- DWORD tc;
- DWORD l;
- char hostname[MAX_COMPUTERNAME_LENGTH + 1];
- } randomness;
- randomness r;
-
- MD5Init(&c);
- /* memory usage stats */
- GlobalMemoryStatus(&r.m);
- /* random system stats */
- GetSystemInfo(&r.s);
- /* 100ns resolution (nominally) time of day */
- GetSystemTimeAsFileTime(&r.t);
- /* high resolution performance counter */
- QueryPerformanceCounter(&r.pc);
- /* milliseconds since last boot */
- r.tc = GetTickCount();
- r.l = MAX_COMPUTERNAME_LENGTH + 1;
-
- Leach, Salz expires Aug 1998 [Page 25]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- GetComputerName(r.hostname, &r.l );
- MD5Update(&c, &r, sizeof(randomness));
- MD5Final(seed, &c);
- };
- #else
-
- void get_system_time(uuid_time_t *uuid_time)
- {
- struct timeval tp;
-
- gettimeofday(&tp, (struct timezone *)0);
-
- /* Offset between UUID formatted times and Unix formatted times.
- UUID UTC base time is October 15, 1582.
- Unix base time is January 1, 1970.
- */
- *uuid_time = (tp.tv_sec * 10000000) + (tp.tv_usec * 10) +
- I64(0x01B21DD213814000);
- };
-
- void get_random_info(char seed[16]) {
- MD5_CTX c;
- typedef struct {
- struct sysinfo s;
- struct timeval t;
- char hostname[257];
- } randomness;
- randomness r;
-
- MD5Init(&c);
- sysinfo(&r.s);
- gettimeofday(&r.t, (struct timezone *)0);
- gethostname(r.hostname, 256);
- MD5Update(&c, &r, sizeof(randomness));
- MD5Final(seed, &c);
- };
-
- #endif
-
- utest.c
-
- #include "copyrt.h"
- #include "sysdep.h"
- #include <stdio.h>
- #include "uuid.h"
-
- uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */
- 0x6ba7b810,
- 0x9dad,
- 0x11d1,
- 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
- };
-
-
-
- Leach, Salz expires Aug 1998 [Page 26]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- /* puid -- print a UUID */
- void puid(uuid_t u);
-
- /* Simple driver for UUID generator */
- void main(int argc, char **argv) {
- uuid_t u;
- int f;
-
- uuid_create(&u);
- printf("uuid_create() -> "); puid(u);
-
- f = uuid_compare(&u, &u);
- printf("uuid_compare(u,u): %d\n", f); /* should be 0 */
- f = uuid_compare(&u, &NameSpace_DNS);
- printf("uuid_compare(u, NameSpace_DNS): %d\n", f); /* s.b. 1 */
- f = uuid_compare(&NameSpace_DNS, &u);
- printf("uuid_compare(NameSpace_DNS, u): %d\n", f); /* s.b. -1 */
-
- uuid_create_from_name(&u, NameSpace_DNS, "www.widgets.com", 15);
- printf("uuid_create_from_name() -> "); puid(u);
- };
-
- void puid(uuid_t u) {
- int i;
-
- printf("%8.8x-%4.4x-%4.4x-%2.2x%2.2x-", u.time_low, u.time_mid,
- u.time_hi_and_version, u.clock_seq_hi_and_reserved,
- u.clock_seq_low);
- for (i = 0; i < 6; i++)
- printf("%2.2x", u.node[i]);
- printf("\n");
- };
-
-Appendix B _ Sample output of utest
-
- uuid_create() -> 7d444840-9dc0-11d1-b245-5ffdce74fad2
- uuid_compare(u,u): 0
- uuid_compare(u, NameSpace_DNS): 1
- uuid_compare(NameSpace_DNS, u): -1
- uuid_create_from_name() -> e902893a-9d22-3c7e-a7b8-d6e313b71d9f
-
-Appendix C _ Some name space IDs
-
- This appendix lists the name space IDs for some potentially
- interesting name spaces, as initialized C structures and in the
- string representation defined in section 3.5
-
- uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */
- 0x6ba7b810,
- 0x9dad,
- 0x11d1,
- 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
- };
-
-
- Leach, Salz expires Aug 1998 [Page 27]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- uuid_t NameSpace_URL = { /* 6ba7b811-9dad-11d1-80b4-00c04fd430c8 */
- 0x6ba7b811,
- 0x9dad,
- 0x11d1,
- 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
- };
-
- uuid_t NameSpace_OID = { /* 6ba7b812-9dad-11d1-80b4-00c04fd430c8 */
- 0x6ba7b812,
- 0x9dad,
- 0x11d1,
- 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
- };
-
- uuid_t NameSpace_X500 = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */
- 0x6ba7b814,
- 0x9dad,
- 0x11d1,
- 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
- };
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
projects / openldap / commitdiff