General impact of ldap server side current time matching

Dear ldapex[t|perts],

thanks to the received feedback our draft related to "ldap server side 
current time matching" has been recently updated to version 1: 
http://www.ietf.org/id/draft-pluta-ldap-srv-side-current-time-match-01.txt
As a result of the previous technical discussions the document is 
currently focused on LDAP protocol specific implementation details like 
for example the syntaxes (current time and duration) and the various 
extensible matching rules.

As the feedback in regard to the general idea (ldap server side current 
time matching) has been quite small we would like to take the 
opportunity to restart the discussion into a more general direction.

We are interested in your (also non-technical) opinions and visions 
regarding this kind of LDAP protocol feature. Advanced usage scenarios 
based on current time matching operations are therefore also of 
interest. Where else and how do these matching rules could have an 
impact, e.g. on your environment, development or related future 
concepts? In the following you find a short (and surely incomplete) list 
of topics that are in our opinion (at least partly) related to current 
time matching:

- ldap password policy's password expiration[Time|Duration], 
draft-behera-ldap-password-policy
- Component Matching (Certificate timestamps?)
- DSA-internal KDC data store; draft-chu-ldap-kdc-schema (eg. 
principalNotUsed[Before|After]?)
- DSA-internal CA (mentioned at kerberos 2009 by H. Chu)
- ...

Your feedback is highly appreciated - thanks a lot!

Best regards,
Daniel