Re: [ldapext] [Fwd: New Version Notification for draft-pluta-ldap-srv-side-current-time-match-00]

Hi Daniel,

Daniel Pluta wrote:
> Hi Steven,
> 
> 
> Steven Legg wrote:
>> Daniel Pluta wrote:
>>> Steven Legg wrote:
>>>> Daniel Pluta wrote:
>>>> If it is the case, then it boils down to a question of whether a
>>>> time comparison involving the current time is performed using
>>>> the client's idea of UTC or the server's.
>>>
>>> We specifically require the server's idea of UTC.
> 
> And you are right, the timezone information in the Root-DSE is not
> needed for our mentioned replication scenario in case every time-stamp 
> value and the comparison is strictly made using UTC.
> 
> At first I've been thinking of using localtime which:
> - would justify the transformation but causes major disadvantages at
> least in complexity, usability, replication and in other cases e.g. when 
> taking a replica's dump to recover the master or another replica in 
> other timezones.
> - is against common accepted LDAP specifications (everything is UTC)
> - should no longer be thought about
> 
> Nevertheless we are currently still think that the timezone information
> should be published:
> - this data "completes" the current time information
> - this information can be used to derive a server's timezone position
> (at least as long as there is no specification how to publish the global
> positioning system information)

I don't have problem with a server publishing its time zone, but the IESG
might take exception to standardizing a feature for which no particular
purpose has been identified.

Incidentally, I can imagine scenarios where an administrator would set up
a server to report and operate as though it is in a time zone other than
the one it is physically in. It's better and easier for the server to nominate
its timezone rather than have to work it out from the server's location.

> 
> 
>>> configuration directives in third party products do not allow to be
>>>  dynamically rewritten to use the client's current time for each 
>>> request. Specifying a search filter 
>>> (endOfLifeTimeStamp:noOrEarlierMatch:=NOW) solves this. A client
>>> does not need to replace the assertion value for each request any
>>> more.
>>
>> I think this is reasonable justification for new matching rules.
>>
> 
> Fine, thanks.
> 
> 
>>> The comparison result need to be independent of the replica (its
>>> timezone) a client connects to.
>>
>> It should be already because all comparisons are according to UTC.
> 
> As already said above: that's right.
> 
> 
>>>> Incidentally, I have implemented operational attributes that
>>>> expose the current date and time, current time of day and current
>>>> day of the week. They appear in every entry and are created on
>>>> demand.
>>>
>>> Ok. We have decided to take the Root-DSE because we are not sure 
>>> whether this information is needed for each entry: - As time flows
>>> which time of day is it? The time of the operation's request or the
>>> time of the result set's delivery (constant result set delivery
>>> time or still "drifting" for each result set's entry's delivery)?
>>
>> Currently (for convenience) it is the instant when the entry contents
>> are composed for final filtering and access control checks. This
>> means that each entry could have a slightly different time. This is
>> adequate for our current purposes because the time difference between
>> the first and last entry is small compared to the precision that the
>> consuming applications actually need, and small compared to the
>> typical skew between different machines. If that ever changes we will
>> review how the timestamps are generated.
>>
>>> - Depending on the first point: how does this impact perfomance?
>>
>> Barely at all in the great scheme of things. The attributes are only
>>  generated if they are specifically requested or required.
>>> case / scenario) where these information and the possible
>>> processing overhead is worth for?
>> - Depending on the first and the second point: What's the reason (use
>>
>>
>> The primary motivation was to allow access controls to be set up
>> based on time of day. The eB2Bcom directory also allows access
>> controls to be specified using filters. With these operational
>> attributes we can do things like permit access if:
>>
>> (&(currentTimeOfDay>=09:00:00+10:00)(currentTimeOfDay<=17:00:00+10:00)).
>>  N.B., the syntax of currentTimeOfDay uses a constrained ASN.1 TIME
>> type.
> 
> Ah I see, this is exactly the opposite approach of ours - but an 
> interesting solution at least for this specialized scenario (and limited 
> for a short period of time e.g. a day).

Not so much an opposite approach as a solution to a different requirement.
I just mentioned it to indicate that I have a use for publishing the server's
current time, not just in the root, but in every entry. I wasn't offering
it as an alternative solution to your specific requirements.

> 
> Therefore in our opinion it's not comparable to the draft's matching 
> rule approach and rises the following questions (if nevertheless compared):
> - the many time determination operations for huge result sets (which can 
> be optimized)
> - the client side specified filter criteria
> 
> The first point can be easily optimized:
> In huge result sets the repeating time determination for each
> entry does possibly take some time. I would suggest to use an
> instantaneous and constant time of the request/operation/etc even
> because you already said, that the time deltas are just slightly
> different and are to small to be of any great effect (so, why spending
> processing time for them?).

Because it was easier to code it that way. A consistent time would be
better but requires more coding. If I were to standardize this attribute,
then I would specify it as having its value fixed for the duration of an
operation, and change the code accordingly.

> 
> Comment regarding the second point:
> Instead of using calculated times, when using in backend stored
> time-stamp values in combination with our matching rule each entry can
> have different period limiting time-stamp pairs. This is an important
> difference regarding the use in automatic provisioning scenarios where 
> we want to support selection of all currently valid entries (independent 
> from the distinct time-stamps, which should not be readable or even 
> binary search able) in contrast to your scenario.
> 
> Our approach handles huge and tiny result sets using the same matching 
> rule mechanisms independent from operating as single userDN (self) or a 
> service's DN.
> 
> However, I think I understand your scenario and idea. In
> regard to "currentTimeOfDay" this seems to be a fine solution in case
> your clients and services are trustworthy enough to be allowed to 
> define/request the periods on their own.

The periods are defined by the directory administrators in the access
controls, which are evaluated by the server using the server's current time.
The client's aren't defining anything.

 > Regardless from our concerns,
> your currentTimeOfDay syntax is very interesting, to extend our matching 
> rules to also match these kind of values, too.

I don't see what that would achieve. The value of currentTimeOfDay is always
"now" and your matching rules are testing if the value of a timestamp is "now",
so the result would always be true (assuming the implementation determined
"now" only once for the entire operation).

> 
> Instead of publishing the current time in each entry our approach allows 
> us to uses a single, centralized place in the DIT (e.g. Root-DSE) to 
> publish the server's current time information. The time information is 
> only used seldom in combination with our matching rule approach but is 
> useful to offer clients a general chance to determine the server's 
> current system time. When using tls/ssl in general the server's system 
> time should be ok, but nobody knows. So the clients needs a
> chance to query the server (using LDAP) for its current time at least in 
> UTC.

The pertinent question is: why? The IESG will probably want to know.

> 
> Although a concrete scenario where the timezone is needed is currently 
> missing, additionally publishing the timezone (in contrast to our draft 
> e.g. in an extra attribute) makes this kind of information (the time) 
> more complete, at least in our opinion.

My opinion is different. An operational attribute to publish the server's
time and/or timezone isn't significant to the remainder of the draft and
could just as well be in a separate draft, or not mentioned at all.
So I don't see it as being desirable for reasons of completeness.

> 
> 
>>> In addition to privacy another scenario where the server side time 
>>> matching is very useful affects provisioning systems. E.g. identity
>>>  management (IDM) system infrastructures can profit from such
>>> matching rules. They can be pre-provisioned (pre means timely in
>>> advance) and entries become available just-in-time (based on a
>>> single time-stamp attribute for example), without the need for an
>>> external event that has to trigger the provisioning (results in an
>>> entry's visibility). Beside the initial provisioning, the
>>> provisioning life-cycle becomes independent, more flexible, gets
>>> simplified and can be consolidated into the ldap server itself. Not
>>> to mention automatic de-provisioning without manual/external
>>> just-in-time interventions. De-provisioning is highly probable the
>>> wrong expression: In IDM systems former identities need to be
>>> removed from core services but often also need to stay available
>>> for a subset of services (for alumna). Currently this is often
>>> controlled by complete entry provisioning or simple attribute
>>> changes (event or timely triggered or both). Although these changes
>>> are known in advance for the majority of the users, complex
>>> interdependent event handling mechanisms and triggers are externally 
>>> implemented to manipulate (e.g. hide or disable) entries
>>>  for distinct services... When using current time matching no
>>> events are needed in those scenarios. In OpenLDAP for example, by
>>> using an appropriate ACL the event's can be planned in advance and
>>> the partial de-provisioning will automatically and immediately take
>>> effect when time has come.
>>
>> I can see how that works if the services always bind to the directory
>>  and perform operations as themselves but it wouldn't work if the
>> services proxy the end user or proxy other services. In all, this
>> feels like a workaround for simple-minded services that assume the
>> service is available to a user just because the user has an entry.
>> The ideal solution would be for the service to check that the current
>> time is in the validity period for that service and user (in which 
>> case the service's idea of UTC is just as good as the LDAP server's).
>>
> 
> In our current scenario service proxies are supported as well. They
> could also contain time-stamp attributes that are used to determine
> whether a service is currently allowed to operate on the directory 
> (please see below for details).
> 
> 
>> Where there is some limited ability to configure the service with
>> fixed LDAP searches then the new matching rules become useful. If
>> that isn't an option, then the new matching rules could be used to
>> limit the visibility of the user's entry for different services. Bad
>> luck if the services proxy other identities.
> 
> Probably I cannot follow you in detail. Could you please give me a more 
> detailed example? Thanks a lot.

In the ideal situation the "foobar" service would test whether it is
currently enabled for a given user by searching the user's entry with a
filter like:

     (&(foobarStartTime<=20100423133800+1000)(foobarEndTime>=20100423133800+1000))

where (for example) the current time is 20100423133800+1000 as far as
the foobar service is concerned.

If the foobar service can only be configured with a fixed LDAP filter,
then that filter would need to be something like this:

     (&(|(foobarStartTime:currentTimeMatch:=P0S)
         (foobarStartTime:currentTimeOrderingMatch:=P0S))
       (!(foobarEndTime:currentTimeOrderingMatch:=P0S)))

Note that "P0S" is a duration of zero seconds.

If the foobar service just assumes that it is enabled for any user whose
entry is visible, then there would need to be an access control in the LDAP
server that only allows the foobar service identity to see a user entry
if the preceding filter applied to that user entry is satisfied.

If the foobar service used the user identity rather than its own to
determine the existence of the user entry, then there would need to be
an access control in the LDAP server that only allows the user identity
to see its own entry if the preceding filter is satisfied. However, it
then isn't possible to have separate start and end times for each service.
There would be one start time and end time that applies to all services
and the user would not even see their own entry outside those times.

> 
> 
>>>> If particular privacy outcomes are not a goal, then all you need
>>>> is two matching rules with DURATION assertion syntax that I might
>>>> call currentTimeMatch and currentTimeOrderingMatch. The
>>>> currentTimeMatch rule tests if an attribute value is equal to the
>>>> current time plus an offset (i.e., the DURATION assertion value,
>>>> which can be positive, negative or zero) and the 
>>>> currentTimeOrderingMatch tests if an attribute value is less than
>>>> the current time plus an offset.
>>>>
>>>>> It is a direct result based on our experiments with current
>>>>> time matching rules, which probably deflects from our primary
>>>>> intention.
>>>>>
>>>>> Your suggested solution does not need to make use of current
>>>>> time matching rules (due to server internal delta calculation
>>>>> which first of all seems to be an easy and elegant way) so this
>>>>> solution is strictly limited to the scenario where two
>>>>> time-stamps define a rather hard validity period (begin and
>>>>> end). On the other side, what about the possibility to use one
>>>>> of the two time-stamps (or any other time-stamp attribute)
>>>>> within scenarios where flexible transitions times (e.g. +2
>>>>> months/days/... after or before a given time) need to be
>>>>> supported, too? Therefore the server internal calculation
>>>>> suggested by you need to be customizable depending on the
>>>>> operations details...
>>>>
>>>> Yes, that's why I said "it becomes a question of how expressive
>>>> should the derivation rules be and what form should they take ?".
>>>> One way to express the derivation rule for a boolean attribute is
>>>> as a search filter, which could use currentTimeMatch and
>>>> currentTimeOrderingMatch ! It may be more appropriate to have
>>>> different derived attributes and end-points to reflect "soft" and
>>>> "hard" validity. Detailed use cases would help guide such
>>>> decisions. However, it doesn't matter if privacy outcomes are not
>>>> the goal.
>>>
>>> As explained above LDAP servers that support filter statements
>>> during ACL processing can fulfill the privacy goals very easily,
>>> because the matching rules can be used to server-side force a
>>> filter via ACLs that clients cannot overwrite or bypass.
>>
>>
>> In that case you don't need extra syntaxes or all four matching
>> rules.
> 
> Indeed we need the syntaxes to prevent services to be able to determine
> the limiting time-stamp values for example of an user's entry which has 
> to be searched by a service before it can be used for authentication via 
> a bind operation. We are yet already able to prevent inquisitive 
> services to get more information than that are needed just in the moment.

I'm not convinced that preventing services from seeing data that are pertinent
to the operation of that service is an important goal. Fair enough that
users shouldn't be able to see the service details of other users, and maybe
there are times when users shouldn't be able to see some of their own service
details, but putting blinkers on the service as well doesn't seem worth it.
For one thing it means that the service can't do things like warn users
that their access will be disabled in one hour, or even determine for itself
which users will soon become disabled so that certain administrative actions
can be put in motion.

> 
> BTW: I could not find an RFC which explicitly says something
> about how ordering matching rules may/must/should be supported/processed
> in extensible match filters. On the other hand I also have not found a
> statement that ordering matching rules should not be supported in
> extensible match filters...

I know of no standard specification that explicitly allows or prohibits the use
of any particular matching rule in an extensible match. Yours would be the
first.

> Although, OpenLDAP currently does not support ordering matching rules in
> extensible match filters it's possibly just a question of time when this
> "feature" becomes supported, too (in case the/a specification says so?).
> On the other hand, other directory server implementations may be already
> support ordering matching rules in extensible match filters (the way
> you've explained above) and probably also want to prevent client's to 
> determine the exact time-stamps vaules - just by using the new syntaxes 
> which we derived from gerneralizedTime.

FYI, eB2Bcom's directory allows all of its 110+ supported matching rules to
be used in an extensible match. In fact, an extensible match is the only
way to invoke a significant number of them. I'm not convinced that the
new syntaxes are necessary or desirable.

> 
> 
> Now let me please come back to explain the common need for the two extra 
> syntaxes (named "nowBefore" and "nowAfter") mentioned in our draft:
> 
> Imagine two period limiting time-stamp attributes' values. These
> attributes need to be searchable to allow an ACL engine (that supports 
> searchfilter) to process the filter statement in the context of the user 
> or the context of a service's bindDN.

An ACL engine in a directory is not itself subject to access controls.

 > So at least search (ideally
> without read) permission has to be given to self, the service's bindDN 
> or both. Search permission for "self" is not as critical as search 
> access for the service's bindDN. Snoopy bindDN owners could try to 
> gather more detailed information from exntries than originally intended 
> (e.g. looking into the future or past using binary search...)

Even if you lock down the timestamps there is still plenty of other,
more useful information that someone with the service's credentials
could access. The new syntaxes would provide only a marginal benefit
in this situation. Not enough to justify their unconventional
quirkiness.

Regards,
Steven

> 
> Thus, search access currently cannot be further limited e.g. to 
> "generalizedTimeMatch-only" and there's currently no easy or general 
> (even standardized) way to handle/extend ACL processing to exclude 
> distinct matching rules from search (matching) operations, using 
> generalizedTime syntax for the two limiting attributes leads to the 
> binary search problem in case ordering matching rules are usable in 
> combination with extensible match filters.
> 
> By using our two syntaxes, services' bindDNs are able to use the 
> time-stamp limits (using our matching rule) right in the moment but they 
> are not able to determine any entry's distinct time-stamps (even not 
> their own where this is appropriate).
> 
> Additionally both attribute value syntaxes are not completely new. They 
> are just syntactically derived from generalizedTime syntax. Both are 
> explicitly not associated with the generalizedTimeOrdering matching rule 
> to prevent binary searching in extensible match filters. In our opinion 
> the above mentioned limitation (in regard to privacy protection against 
> binary search) justifies their introduction. How these syntaxes are used 
> in an userApplication schema or even product specific ACL definition 
> (where supported) should of course be left open to the directory 
> designers and administrators.
> 
> 
> Appendix:
> Of course you are right, the other two extra offset-syntaxes (defined in
> our draft) are only nice to have but not needed (in regard to privacy) 
> because clients can of course specify all kind of offsets to do a binary 
> search. Therefore these syntaxes can be removed from the document. 
> generalizedTime syntax is completely sufficient in regard to 
> Offset/Duration matching.
> 
> 
>>>>> To support these kind of requirements the matching rules are of
>>>>>  general interest. Based on our current experimental
>>>>> implementation (which possibly needs to be reduced to the
>>>>> matching basics) of these matching rules in combination with
>>>>> your implementation of the X680 duration specification the
>>>>> matching could be of general use for LDAP, too.
>>>>>
>>>>> In our opinion there is currently nothing to be said against
>>>>> the reasonable use of both mechanisms. What do you think about
>>>>> this?
>>>>
>>>> New matching rules and derived attributes both have their uses, 
>>>> singly or in combination,
>>>
>>> yes, for sure.
>>>
>>>> but using syntaxes to achieve access control is just wrong to my
>>>> mind.
>>>
>>> yes, at least as long as extensibleMatch filter expression do not 
>>> support ":<=" or ":>=" comparison operations...
>>
>> ... which they do and always have :-).
> 
> Hmmm, please let me cite BOFH chap. 13: "Yes means No and No means Yes.
> Delete all files [Y]?" ;-)
> 
> Based on your clarification regarding the possibility to use ordering 
> matching rules in extensible match filters our previous position 
> regarding the sabove "yes, at least as..." has spontaneously changed 
> into the opposite. As explained above we would like to see the 
> additional two syntaxes to solve possible privacy concerns (regardless 
> of distinct products' ACL processing features), so please let me answer 
> your previous statement once again:
> 
> 
>> but using syntaxes to achieve access control is just wrong to my
>> mind.
> 
> Achieving additional access control features is just a side effect 
> (which affect varies between different directory server products' 
> features).
> The additional syntaxes' limitations are useful in common
> privacy related scenarios where time-stamp derived attributes should by 
> design only be search able using our matching rules. Preventing snoopy 
> service's (proxy?) bindDNs to get more information about an entry than 
> actually is needed.
> 
> 
> Best regards,
> Daniel
> 
> 
> 
>> Regards, Steven
>>
>>>
>>> Best regards, Daniel
>>>
>>>
>>>>> Steven Legg wrote:
>>>>>> Daniel Pluta wrote:
>>>>>>> Dear ldapext,
>>>>>>>
>>>>>>> we would appreciate your valuable comments and feedback
>>>>>>> regrading our draft specifying "ldap server side current
>>>>>>> time matching".
>>>>>>
>>>>>> The draft is essentially about enforcing access control
>>>>>> policy through schema mechanisms, which strikes me as
>>>>>> inappropriate for two principal reasons:
>>>>>>
>>>>>> (1) Schema is supposed to be immutable, whereas access
>>>>>> control policy is subject to change. If access control policy
>>>>>> is reflected in the attribute syntaxes one chooses, then that
>>>>>> policy is permanently locked-in.
>>>>>>
>>>>>> (2) Schema is one-size-fits-all. The same rules apply to
>>>>>> everyone, regardless of whether they are anonymous guest
>>>>>> users or highly privileged administrators. Access control
>>>>>> policy is rarely that uniform.
>>>>>>
>>>>>> Privacy goals should be addressed through access control
>>>>>> mechanisms, but of course you are hampered by the absence of
>>>>>> a common, standardized access control mechanism across all
>>>>>> LDAP implementations. With that in mind I would take a
>>>>>> somewhat different approach to a solution.
>>>>>>
>>>>>> Basically you want to allow general access to a derived
>>>>>> property of a collection of attributes while simultaneously
>>>>>> enforcing restricted access to that collection of attributes.
>>>>>> What I would do is define a schema mechanism for defining
>>>>>> derived attributes, i.e., attributes whose values are
>>>>>> algorithmically derived by the server from the values of
>>>>>> other attributes in the same entry. The derived attributes
>>>>>> can then be subject to different access controls than the
>>>>>> source attributes.
>>>>>>
>>>>>> In your example with the notValidBefore and notValidAfter
>>>>>> attributes, I imagine having a derived attribute called
>>>>>> currentlyValid, with Boolean Syntax, that is derived from
>>>>>> notValidBefore and notValidAfter according to the following
>>>>>> pseudo code:
>>>>>>
>>>>>> if (current time >= notValidBefore and current time <=
>>>>>> notValidAfter) then value = TRUE else value = FALSE
>>>>>>
>>>>>> Privileged users and processes would be given permission to
>>>>>> read and update the notValidBefore and notValidAfter
>>>>>> attributes, but regular users would only be able to read the
>>>>>> currentlyValid attribute. This kind of access control policy
>>>>>> can be expressed in existing LDAP access control schemes even
>>>>>> though they differ between implementations.
>>>>>>
>>>>>> That takes care of the nowBefore and nowAfter syntaxes. I
>>>>>> don't see that you achieve anything with the nowBeforeOffset
>>>>>> and nowAfterOffset syntaxes since a user can just use a
>>>>>> binary search to determine the actual values of the target
>>>>>> attributes by adjusting the offsets (a client can guess the
>>>>>> time at the server with reasonable accuracy). Limiting the
>>>>>> sign or magnitude of the offset would provide partial protection, 
>>>>>> but a derived attribute could also do that. For
>>>>>> example, to allow regular users to determine when a valid
>>>>>> account became valid but not allow them to determine whether
>>>>>> or when an account will become valid at some time in the
>>>>>> future I would define a derived attribute of GeneralizedTime
>>>>>> syntax whose values are determined by the following pseudo
>>>>>> code:
>>>>>>
>>>>>> if (current time >= notValidBefore) value = notValidBefore else 
>>>>>> absent
>>>>>>
>>>>>> It becomes a question of how expressive should the derivation
>>>>>>  rules be and what form should they take ? I think OpenLDAP
>>>>>> might have some capabilities in that area already.
>>>>>>
>>>>>> The nowOffset syntax isn't required if derived attributes are
>>>>>> used instead, but if you want to persist with it I suggest
>>>>>> you align it with the existing ASN.1 DURATION data type (see
>>>>>>  http://www.itu.int/rec/T-REC-X.680-200606-S!Amd3/en ) rather
>>>>>> than rolling your own format, not the least because I already
>>>>>> have an implementation that supports DURATION as an attribute
>>>>>> and assertion syntax for both X.500 and LDAP.
>>>>>>
>>>>>> Regards, Steven
>>>>>>
>>>>>>>
>>>>>>> Please see below for the abstract.
>>>>>>>
>>>>>>> The full version can be found here: 
>>>>>>> http://www.ietf.org/id/draft-pluta-ldap-srv-side-current-time-match-00.txt 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Many thanks in advance!
>>>>>>>
>>>>>>> Best regards Daniel
>>>>>>>
>>>>>>>
>>>>>>> -------- Original-Nachricht -------- Betreff: New Version
>>>>>>> Notification for draft-pluta-ldap-srv-side-current-time-match-00 
>>>>>>> Datum: Thu,
>>>>>>> 25 Mar 2010 15:51:33 -0700 (PDT) Von: IETF I-D Submission
>>>>>>> Tool <idsubmission@ietf.org>
>>>>>>>
>>>>>>>
>>>>>>> A new version of I-D, 
>>>>>>> draft-pluta-ldap-srv-side-current-time-match-00.txt has
>>>>>>> been successfully submitted and posted to the IETF
>>>>>>> repository.
>>>>>>>
>>>>>>> Filename:     draft-pluta-ldap-srv-side-current-time-match 
>>>>>>> Revision:     00 Title:         Lightweight Directory
>>>>>>> Access Protocol (LDAP): Server Side Current Time Matching -
>>>>>>> Matching Rules and Syntaxes Creation_date:     2010-03-25 WG 
>>>>>>> ID:         Independent Submission Number_of_pages: 20
>>>>>>>
>>>>>>> Abstract: This document extends the Lightweight Directory
>>>>>>> Access Protocol (LDAP) to support server side current time
>>>>>>> matching.  Matching of attribute values against an LDAP
>>>>>>> server's current time offers additional functionality with
>>>>>>> regard to authorization and fulfills enhanced data privacy
>>>>>>> requirements for restrictive environments. Therefore this
>>>>>>> specification defines four additional syntaxes and related
>>>>>>> matching rules useful for extensible matching in
>>>>>>> association with these syntaxes.  In addition and for
>>>>>>> general use the matching rules defined in this document are
>>>>>>> also applicable to any attribute type definitions that are
>>>>>>> using the 'Generalized Time' syntax.  This specification
>>>>>>> also contains restrictive attribute type definitions 
>>>>>>> demonstrating the usage of the introduced syntaxes and
>>>>>>> matching rules.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The IETF Secretariat. 
>>>>>>> _______________________________________________ Ldapext
>>>>>>> mailing list Ldapext@ietf.org 
>>>>>>> https://www.ietf.org/mailman/listinfo/ldapext