diff --git a/doc/drafts/draft-haripriya-dynamicgroup-xx.txt b/doc/drafts/draft-haripriya-dynamicgroup-xx.txt
new file mode 100644
index 0000000000..a68af29a35
--- /dev/null
+++ b/doc/drafts/draft-haripriya-dynamicgroup-xx.txt
@@ -0,0 +1,1400 @@
+
+
+
+Network Working Group                                       S. Haripriya
+Internet-Draft                                         Jaimon. Jose, Ed.
+Updates: 02 (if approved)                               Jim. Sermersheim
+Intended status: Standards Track                            Novell, Inc.
+Expires: July 9, 2007                                    January 5, 2007
+
+
+                    LDAP: Dynamic Groups for LDAPv3
+                    draft-haripriya-dynamicgroup-02
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 July 9, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2007).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                  [Page 1]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+Abstract
+
+   This document describes the requirements, semantics, schema elements,
+   and operations needed for a dynamic group feature in LDAP.  A dynamic
+   group is defined here as a group object with a membership list of
+   distinguished names that is dynamically generated using LDAP search
+   criteria.  The dynamic membership list may then be interrogated by
+   LDAP search and compare operations, and may also be used to find the
+   groups that an object is a member of.  This feature eliminates a huge
+   amount of the administrative effort required today for maintaining
+   group memberships and role-based operations in large enterprises.
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  4
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  Requirements of a dynamic group feature  . . . . . . . . . . .  6
+   4.  Schema and Semantic Definitions for Dynamic Groups . . . . . .  7
+     4.1.  Object Classes . . . . . . . . . . . . . . . . . . . . . .  7
+       4.1.1.  dynamicGroup . . . . . . . . . . . . . . . . . . . . .  7
+       4.1.2.  dynamicGroupOfUniqueNames  . . . . . . . . . . . . . .  7
+       4.1.3.  dynamicGroupAux  . . . . . . . . . . . . . . . . . . .  7
+       4.1.4.  dynamicGroupOfUniqueNamesAux . . . . . . . . . . . . .  7
+     4.2.  Attributes . . . . . . . . . . . . . . . . . . . . . . . .  8
+       4.2.1.  memberQueryURL . . . . . . . . . . . . . . . . . . . .  8
+       4.2.2.  excludedMember . . . . . . . . . . . . . . . . . . . . 11
+     4.3.  member . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+     4.4.  uniqueMember . . . . . . . . . . . . . . . . . . . . . . . 11
+     4.5.  dgIdentity . . . . . . . . . . . . . . . . . . . . . . . . 11
+       4.5.1.  dgIdentity - Security implications . . . . . . . . . . 12
+   5.  Advertisement of support for dynamic groups  . . . . . . . . . 13
+   6.  Dynamic Group Operations . . . . . . . . . . . . . . . . . . . 14
+     6.1.  Existing Operations  . . . . . . . . . . . . . . . . . . . 14
+       6.1.1.  Access to resources in the directory . . . . . . . . . 14
+       6.1.2.  Reading a dynamic group object . . . . . . . . . . . . 14
+       6.1.3.  'Is Member Of' functionality . . . . . . . . . . . . . 15
+     6.2.  New Extensions . . . . . . . . . . . . . . . . . . . . . . 16
+       6.2.1.  Managing the static members of a dynamic group . . . . 16
+   7.  Performance Considerations . . . . . . . . . . . . . . . . . . 17
+     7.1.  Caching of Dynamic Members . . . . . . . . . . . . . . . . 17
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
+   10. Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 20
+   11. Normative References . . . . . . . . . . . . . . . . . . . . . 21
+   Appendix A.  Example Values for memberQueryURL . . . . . . . . . . 22
+   Appendix B.  Acknowledgments . . . . . . . . . . . . . . . . . . . 23
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
+
+
+
+Haripriya, et al.         Expires July 9, 2007                  [Page 2]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+   Intellectual Property and Copyright Statements . . . . . . . . . . 25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                  [Page 3]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+1.  Conventions used in this document
+
+   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 [1].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                  [Page 4]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+2.  Introduction
+
+   The LDAP schema described in [4] defines two object classes:
+   'groupOfNames', and 'groupOfUniqueNames', that hold a static list of
+   distinguished names in their 'member' or 'uniqueMember' attributes
+   respectively, and are typically used to describe a group of objects
+   for various functions.  These grouping functions range from simple
+   group membership applications such as email distribution lists to
+   describing common authorization for a set of users The administration
+   and updating of these membership lists must be done by specifically
+   modifying the DN values in the member or uniqueMember attributes.
+   Thus, each time a change in membership happens, a process must exist
+   which adds or removes the particular entry's DN from the member
+   attribute.  For example, consider an organization, where the access
+   to its facilities is controlled by membership in a directory group.
+   Assume that all employees in a department have been added to the
+   group that provides access to the required department facility.  If
+   an employee moves from one department to another, the administrator
+   must remove the employee from one group and add him to another.
+   Similarly consider an organization that wants to provide access to
+   its facility, to both interns and employees on weekdays, but only to
+   employees on weekends.  It would be effort-consuming to achieve this
+   with static groups.
+
+   "Dynamic groups" are like normal groups, but they let one specify
+   criteria to be used for evaluating membership to a group; the
+   membership of the group is determined dynamically by the directory
+   servers involved.  This lets the group administrator define the
+   membership in terms of attributes, and let the DSAs worry about who
+   are the actual members.  This solution is more scalable and reduces
+   administrative costs.  This can also supplement static groups in LDAP
+   to provide flexibility to the user.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                  [Page 5]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+3.  Requirements of a dynamic group feature
+
+   The following requirements SHOULD be met by a proposal for the
+   dynamic groups feature:
+
+   1.  Creation and administration of dynamic groups should be done
+       using normal LDAP operations.
+
+   2.  Applications must be able to use dynamic groups in the same way
+       that they are able to use static groups for listing members and
+       for membership evaluation.
+
+   3.  Interrogation of a dynamic group's membership should be done
+       using normal LDAP operations, and should be consistent.  This
+       means that all authorization identities with the same permission
+       to the membership attribute of a dynamic group (such as 'read')
+       should be presented with the same membership list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                  [Page 6]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+4.  Schema and Semantic Definitions for Dynamic Groups
+
+   The dynamic group classes are defined by the following schema
+
+4.1.  Object Classes
+
+   The following object classes MUST be supported, and their semantics
+   understood by the server, for it to support the dynamic groups
+   feature.
+
+4.1.1.  dynamicGroup
+
+   ( <OID.TBD> NAME 'dynamicGroup' SUP groupOfNames STRUCTURAL MAY
+   (memberQueryURL $ excludedMember $ dgIdentity ))
+
+   This structural object class is used to create a dynamic group
+   object.  It is derived from groupOfNames, which is defined in [4].
+
+4.1.2.  dynamicGroupOfUniqueNames
+
+   ( <OID.TBD> NAME 'dynamicGroupOfUniqueNames' SUP groupOfUniqueNames
+   STRUCTURAL MAY (memberQueryURL $ excludedMember $ dgIdentity ))
+
+   This structural object class is used to create a dynamic group object
+   whose membership list is held in a uniqueMember attribute.  It is
+   derived from groupOfUniqueNames, which is defined in [4].
+
+4.1.3.  dynamicGroupAux
+
+   ( <OID.TBD> NAME 'dynamicGroupAux' SUP groupOfNames AUXILIARY MAY
+   (memberQueryURL $ excludedMember $ dgIdentity ))
+
+   This auxiliary object class is used to convert an existing object to
+   a dynamic group or to create an object of another object class but
+   with dynamic group capabilities.  This is derived from groupOfNames
+   which is defined in [4].
+
+4.1.4.  dynamicGroupOfUniqueNamesAux
+
+  ( <OID.TBD> NAME 'dynamicGroupOfUniqueNamesAux' SUP groupOfUniqueNames
+  AUXILIARY MAY (memberQueryURL $ excludedMember $ dgIdentity ))
+
+   This auxiliary object class is used to convert an existing object to
+   a dynamic group of unique names or to create an object of another
+   object class but with dynamic group capabilities.  This is derived
+   from groupOfUniqueNames which is defined in [4].
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                  [Page 7]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+4.2.  Attributes
+
+   The following attribute names MUST be supported by the server.
+
+4.2.1.  memberQueryURL
+
+   This attribute describes the membership of the list using an LDAPURL
+   [3].
+
+ (<OID.TBD> NAME 'memberQueryURL' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+   The value of memberQueryURL is encoded as an LDAPURL [3]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                  [Page 8]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+   The BNF from [3] is listed here for reference.
+ldapurl = scheme COLON SLASH SLASH [host [COLON port]] [SLASH dn
+                     [QUESTION [attributes] [QUESTION [scope] [QUESTION [filter] [QUESTION
+                     extensions]]]]]
+                                ; <host> and <port> are defined
+                                ;   in Sections 3.2.2 and 3.2.3
+                                ;   of [RFC3986].
+                                ; <filter> is from Section 3 of
+                                ;   [RFC4515], subject to the
+                                ;   provisions of the
+                                ;   "Percent-Encoding" section
+                                ;   below.
+scheme      = "ldap"
+dn          = distinguishedName ; From Section 3 of [RFC4514],
+                                ; subject to the provisions of
+                                ; the "Percent-Encoding"
+                                ; section below.
+attributes  = attrdesc *(COMMA attrdesc)
+attrdesc    = selector *(COMMA selector)
+selector    = attributeSelector ; From Section 4.5.1 of
+                                ; [RFC4511], subject to the
+                                ; provisions of the
+                                ; "Percent-Encoding" section
+                                ; below.
+scope       = "base" / "one" / "sub"
+extensions  = extension *(COMMA extension)
+extension   = [EXCLAMATION] extype [EQUALS exvalue]
+extype      = oid               ; From section 1.4 of [RFC4512].
+exvalue     = LDAPString        ; From section 4.1.2 of
+                                ; [RFC4511], subject to the
+                                ; provisions of the
+                                ; "Percent-Encoding" section
+                                ; below.
+EXCLAMATION = %x21              ; exclamation mark ("!")
+SLASH       = %x2F              ; forward slash ("/")
+COLON       = %x3A              ; colon (":")
+QUESTION    = %x3F              ; question mark ("?")
+
+
+   For the purpose of evaluating dynamic members, the directory server
+   uses only the dn, scope, filter and extensions fields.  All remaining
+   fields are ignored if specified.  If other fields are specified, the
+   server SHALL ignore them and MAY omit them when presenting the value
+   to a client.  The dn is used to specify the base dn from which to
+   start the search for dynamic members.  The scope specifies the scope
+   with respect to the dn in which to search for dynamic members.  The
+   filter specifies the criteria with which to select objects for
+   dynamic membership.
+
+
+
+Haripriya, et al.         Expires July 9, 2007                  [Page 9]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+4.2.1.1.  The x-chain extension
+
+   A new extension is defined for use of the memberQueryURL in dynamic
+   groups, named 'x-chain'. x-chain does not take a value.  When x-chain
+   is present, the server must follow any search continuation references
+   to other servers while searching for dynamic members.  When x-chain
+   is absent, the dynamic members computed will be only those that are
+   present on the server from which the search is made.  A directory
+   server supporting the memberQueryURL MAY support the x-chain
+   extension, thus the x-chain extension could be critical or non-
+   critical as specified by the '!' prefix to the extension type.
+
+4.2.1.2.  Semantics of multiple values for memberQueryURL
+
+   The memberQueryURL MAY have multiple values, and in that case, the
+   members of the dynamic group will be the union of the members
+   computed using each individual URL value.  This is useful in
+   specifying a group membership that is made up from subtrees rooted at
+   different base DNs, and possibly using different filters.
+
+4.2.1.3.  Condition of membership
+
+   An object O is a member of a dynamic group G if and only if
+
+   (( O is a value of the 'member' or 'uniqueMember' attribute of G)
+
+   OR
+
+   (( O is selected by the membership criteria specified in the
+   'memberQueryURL' attribute values of G)
+
+   AND
+
+   ( O is not listed in the 'excludedMember' attribute of G) ))
+
+   If a member M of a dynamic group G happens to be a dynamic or a
+   static group, the static or dynamic members of M SHALL NOT be
+   considered as members of G. M is a member of G though.
+
+   The last condition is imposed because
+
+   o  Recursively evaluating members of members may degrade the
+      performance of the server drastically.
+
+   o  Looping may occur particularly in situations where the search
+      chains across multiple-servers.
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 10]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+   o  Dynamic membership assertions (compare operation) cannot be
+      optimized if recursive memberships are allowed.  Without
+      recursion, comparisons can be made light-weight.
+
+4.2.2.  excludedMember
+
+   ( <OID.TBD> NAME 'excludedMember' SUP distinguishedName )
+
+   This attribute is used to exclude entries from being a dynamic member
+   of a dynamic group.  Thus an entry is a dynamic member of a dynamic
+   group if and only if it is selected by the member criteria specified
+   by the 'memberQueryURL' attribute or explicitly added to the member
+   or uniqueMember attribute, and it is not listed in the
+   'excludedMember' attribute.
+
+4.3.  member
+
+   ( 2.5.4.31 NAME 'member' SUP distinguishedName )
+
+   Defined in [4], this attribute is overloaded when used in the context
+   of a dynamic group.  It is used to explicitly specify static members
+   of a dynamic group.  If the same entry is listed in both the 'member'
+   and 'excludedMember' attributes, the 'member' overrides the
+   'excludedMember', and the entry is considered to be a member of the
+   group.  This attribute is also used to interrogate both the static
+   and dynamic member values of a dynamic group object.  Subclasses of
+   this attribute are NOT considered in this manner.
+
+4.4.  uniqueMember
+
+   ( 2.5.4.32 NAME 'uniqueMember' SUP distinguishedName )
+
+   Defined in [4], this attribute is overloaded when used in the context
+   of a dynamic group.  It is used to specify the static members of a
+   dynamic group.  If the same entry is listed in both the
+   'uniqueMember' and 'excludedMember' attributes, the 'uniqueMember'
+   overrides the 'excludedMember', and the entry is considered to be a
+   member of the group.  This attribute is also used to interrogate both
+   the static and dynamic member values of a dynamic group object.
+   Subclasses of this attribute are NOT considered in this manner.
+
+4.5.  dgIdentity
+
+   ( <OID.TBD> NAME 'identity' SUP distinguishedName SINGLE-VALUE )
+
+   In order to provide consistent results when processing the search
+   criteria, the server must use a single authorization identity.  If
+   the authorization of the bound identity is used, the membership list
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 11]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+   will vary, from identity to identity due to differing access
+   controls.  This may either be done by the server authenticating as
+   the dgIdentity prior to performing a search or compare operation, or
+   may be done by simply assuming the authorization of the dgIdentity
+   when performing those operations.  As server implementations vary, so
+   may the mechanisms to achieve consistent results through the use of
+   the dgIdentity.  In the case that the server authenticates as the
+   dgIdentity, it may be required by the server that this identity have
+   proper authentication credentials, and it may be required that this
+   identity reside in the DIB of the local server.
+
+   In the absence of an identity value, or in case the identity value
+   cannot be used, the server will process the memberQueryURL as the
+   anonymous identity.  This attribute MAY be supported, and represents
+   the identity the server will use for processing the memberQueryURL.
+
+4.5.1.  dgIdentity - Security implications
+
+   Because this attribute indirectly but effectively grants anyone with
+   read or compare access to the member or uniqueMember attribute
+   sufficient permission to gain a DN result set from the
+   memberQueryURL, server implementations SHOULD NOT allow this
+   attribute to be populated with the DN of any object that is not
+   administered by the identity making the change to this attribute.
+   For purposes of this document, to "administer an object" indicates
+   that the administrative identity has the ability to fully update the
+   access control mechanism in place the object in question.  As of this
+   writing, there is no way to describe further what it means to be
+   fully able to administer the access control mechanism for an object,
+   so this definition is left as implementation-specific.
+
+   This requirement will allow an entity that has privileges to
+   administer a particular subtree (meaning that entity can add, delete,
+   and update objects in that subtree), to place in the dgIdentity DNs
+   of only those objects it administers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 12]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+5.  Advertisement of support for dynamic groups
+
+   If the dynamic groups schema is not present on an LDAP server, it
+   MUST be assumed that the dynamic groups feature is not supported.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 13]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+6.  Dynamic Group Operations
+
+6.1.  Existing Operations
+
+   The following operations SHOULD expose the dynamic groups
+   functionality.  These operations do not require any change in the
+   LDAP protocol to be exchanged between the client and server.
+
+6.1.1.  Access to resources in the directory
+
+   If access control items are set on a target resource object in the
+   directory, with the subject being a dynamic group object, then all
+   the members of the group object, including the dynamic members, will
+   get the same permissions on the target entry.  This would be the most
+   useful application of dynamic groups as seen by an administrator
+   because it lets the server control access to resources based on
+   dynamic membership to a trustee (subject of ACI) of the resource.
+   The way to specify a dynamic ACL is currently implementation
+   specific, as there is no common ACL definition for LDAP, and hence
+   will be dealt with in a separate document or later (TO BE DONE).
+
+6.1.2.  Reading a dynamic group object
+
+   When the member attributes of a dynamic group object is listed by the
+   client using an LDAP search operation, the member values returned
+   SHOULD contain both the static and dynamic members of the group
+   object.  This functionality will not require a change to the
+   protocol, and the clients need not be aware of dynamic groups to
+   exploit this functionality.  This feature is useful for clients that
+   determine access privileges to a resource by themselves, by reading
+   the members of a group object.  It will also be useful to
+   administrators who want to see the result of the query URL that they
+   set on the dynamic group entry.  Note that this overloads the
+   semantics of the 'member' and 'uniqueMember' attributes.  This could
+   lead to some surprises for the client .
+
+   for example: Clients that read the member attribute of a dynamic
+   group object and then attempt to remove values (which were dynamic)
+   could get an error specifying such a value was not there.
+
+   Example:
+
+   Let cn=dg1,o=myorg be a dynamic group object with the following
+   attributes stored in the directory.
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 14]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+      member: cn=admin,o=myorg
+
+      excludedMember: cn=guest,ou=finance,o=myorg
+
+      excludedMember: cn=robin,ou=finance,o=myorg
+
+      memberQueryURL:
+      ldap:///ou=finance,o=myorg??sub?(objectclass=organizationalPerson)
+
+   If there are 5 organizationalPerson objects under ou=finance,o=myorg
+   with common names bob, alice, john, robin, and guest, then the output
+   of a base-scope LDAP search at cn=dg1,o=myorg, with the attribute
+   list containing 'member' will be as follows:
+
+      dn: cn=dg1,o=myorg
+
+      member: cn=admin,o=myorg
+
+      member: cn=bob,ou=finance,o=myorg
+
+      member: cn=alice,ou=finance,o=myorg
+
+      member: cn=john,ou=finance,o=myorg
+
+6.1.3.  'Is Member Of' functionality
+
+   The LDAP compare operation allows one to discover whether a given DN
+   is in the membership list of a dynamic group.  Again, the server
+   SHOULD produce consistent results among different authorization
+   identities when processing this request, as long as those identities
+   have the same access to the member or uniqueMember attribute.  Using
+   the data from the example in Section 6.1.2, a compare on
+   cn=dg1,o=myorg, for the AVA member=cn=bob,ou=finance,o=myorg would
+   result in a response of compareTrue (assuming the bound identity was
+   authorized to compare the member attribute of cn=dg1,o=myorg).
+
+   Likewise, a search operation that contains an equalityMatch or
+   presence filter, naming the member or uniqueMember attribute as the
+   attribute (such as (member= cn=bob,ou=finance,o=myorg), or
+   (member=*)), will cause the server to evaluate this filter against
+   the rules given in Section 4.2.1.3 in the event that the search is
+   performed on a dynamic group object.  As of this writing, no other
+   matching rules exist for the distinguished name syntax, thus no
+   requirements beyond equalityMatch are given here.
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 15]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+6.2.  New Extensions
+
+   The following new extensions are added for dynamic group support.
+
+6.2.1.  Managing the static members of a dynamic group
+
+   Because a dynamic group overloads the semantics of the member and
+   uniqueMember attributes, a mechanism is needed to retrieve the static
+   values found in these attributes for management purposes.  To serve
+   this need, a new attribute option is defined here called 'x-static'.
+   Attribute options are discussed in Section 2.5 of [2].  This option
+   SHALL only be specified with the 'member' or 'uniqueMember'
+   attribute.  When the LDAP server does not understand the semantics of
+   this option on a given attribute, the option SHOULD be ignored.  This
+   attribute option is only used to affect the transmitted values, and
+   does not impose sub-typing semantics on the attribute.
+
+   This option MAY be specified by a client during a search request in
+   the list of attributes to be returned, i.e. member;x-static.  In this
+   case, the server SHALL only return those members of the dynamic group
+   that are statically listed as values of the member or uniqueMember
+   attribute.  The evaluation process listed in Section 9 SHALL NOT be
+   used to populate the values to be returned.
+
+   This option MAY be specified is either an equalityMatch or presence
+   search filter.  In this case, the server evaluates only the values
+   statically listed in the member or uniqueMember attribute, and does
+   not apply the evaluation process listed in Section 9.
+
+   This option MAY be specified in update operations such as add and
+   modify, but SHOULD be ignored, as its presence is semantically the
+   same as its non-presence.
+
+   Note to user: Performing a search to read a dynamic group, with a
+   filter item such as (member=*), and specifying member;x-static, may
+   result in a search result entry that has no member attribute.  This
+   may seem counter-intuitive.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 16]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+7.  Performance Considerations
+
+   When the x-chain extension is present on the memberQueryURL, the
+   server MUST follow any search continuation references to other
+   servers while searching for dynamic members.  This may be expensive
+   and slow in a true distributed environment.  The dynamicGroup
+   implementation can consider a distributed caching feature to improve
+   the performance.  An outline of such a distributed caching is given
+   below.
+
+7.1.  Caching of Dynamic Members
+
+   Since the dynamic members of a group are computed every time the
+   group is accessed, the performance could be affected.  An
+   implementation of dynamic groups can get around this problem by
+   caching the computed members of a dynamic group locally and using the
+   cached data subsequently.  One way to do this is to create pseudo-
+   objects for each dynamic group on every server that holds an object
+   that is a dynamic member of the group.  With this, the computation of
+   the dynamic members of a group reduces to the task of reading the
+   pseudo-objects from each server.  These pseudo-objects need to be
+   linked from the original dynamic group to speed up the member
+   computation.  Also, since these are cached objects, appropriate
+   timeouts need to be associated with the cache after which the cache
+   should be invalidated or refreshed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 17]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+8.  Security Considerations
+
+   This document discusses the use of one object as the identity
+   (Section 4.5) with which to read information for another object.  If
+   the creation of the dgIdentity attribute is uncontrolled, an intruder
+   could potentially create a dynamic group with the identity of, say,
+   the administrator, to be able to read the directory as the
+   administrator, and see information which would be otherwise
+   unavailable to him.  Thus, a person adding an object as identity of a
+   dynamic group should have appropriate permissions on the object being
+   added as identity.
+
+   This document also discusses using dynamic memberships to provide
+   access for resources in a directory.  As the dynamic members are not
+   created by the administrator, there could be surprises for the
+   administrator in the form of certain objects getting access to
+   certain resources through dynamic membership, which the administrator
+   never intended.  So the administrator should be wary of such
+   problems.  The administrator could view the memberships and make sure
+   that anybody who is not supposed to be a member of a group is added
+   to the excludedMember list.
+
+   Denial of service attacks can be launched on an LDAP server, by
+   repeatedly searching for a dynamic group with a large membership list
+   and listing the member attribute.  A more effective form of denial of
+   service attack could be launched by making searches of the form
+   (member="somedn") at the top of tree and closing the client
+   connection as soon as the search starts.  Some administrative limits
+   be imposed to avoid such situations.
+
+   The dynamic groups feature could be potentially misused by a user to
+   circumvent any administrative size-limit restriction placed on the
+   server.  In order to search an LDAP server and obtain the names of
+   all the objects on the server irrespective of admin size-limit
+   restriction on the server, the LDAP user could create a dynamic group
+   with a memberQueryURL which matches all objects in the tree, and list
+   just that one object.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 18]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+9.  IANA Considerations
+
+   There are no IANA considerations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 19]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+10.  Conclusions
+
+   This document discusses the syntax, semantics and usage of dynamic
+   groups in LDAPv3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 20]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+11.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Zeilenga, K., "Lightweight Directory Access Protocol (LDAP):
+        Directory Information Models", RFC 4512, June 2006.
+
+   [3]  Smith, M. and T. Howes, "Lightweight Directory Access Protocol
+        (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
+
+   [4]  Sciberras, A., "Lightweight Directory Access Protocol (LDAP):
+        Schema for User Applications", RFC 4519, June 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 21]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+Appendix A.  Example Values for memberQueryURL
+
+   1.  This memberQueryURL value specifies the membership criteria for a
+       dynamic group entry as "all inetorgperson entries that also have
+       their title attribute set to 'manager', and are in the DIT-wide
+       subtree under ou=hr,o=myorg ".
+
+          memberQueryURL: ldap:///
+          ou=hr,o=myorg??sub?(&
+          (objectclass=inetorgperson)(title=manager))? x-chain
+
+   2.  This value lets the user specify the membership criteria for a
+       dynamic group entry as "all entries on the local server, that
+       either have unix accounts or belong to the unix department, and
+       are under the engineering container ".
+
+          memberQueryURL: ldap:///ou=eng,o=myorg??sub?
+          (|(objectclass=posixaccount)(department=unix))
+
+   3.  These values let the user specify the membership criteria as "all
+       inetorgperson entries on the local server, in either the
+       ou=eng,o=myorg or ou=support,o=myorg" subtrees.
+
+          memberQueryURL:
+          ldap:///ou=eng,o=myorg??sub?(objectclass=inetorgperson)
+
+          memberQueryURL:
+          ldap:///ou=support,o=myorg??sub?(objectclass=inetorgperson)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 22]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+Appendix B.  Acknowledgments
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 23]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+Authors' Addresses
+
+   Haripriya S
+   Novell, Inc.
+   49/1 & 49/3 Garvebhavi Palya,
+   7th Mile, Hosur Road
+   Bangalore, Karnataka  560068
+   India
+
+   Email: sharipriya@novell.com
+
+
+   Jaimon Jose (editor)
+   Novell, Inc.
+   49/1 & 49/3 Garvebhavi Palya,
+   7th Mile, Hosur Road
+   Bangalore, Karnataka  560068
+   India
+
+   Email: jjaimon@novell.com
+
+
+   Jim Sermersheim
+   Novell, Inc.
+   1800 South Novell Place
+   Provo, Utah  84606
+   US
+
+   Email: jimse@novell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 24]
+
+Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Haripriya, et al.         Expires July 9, 2007                 [Page 25]
+