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

Hi Steven,


Steven Legg wrote:
> Hi Daniel, Daniel Pluta wrote:
>> Hi Steven, Steven Legg wrote:
>>> Hi Daniel, Daniel Pluta wrote:
>>>> Hi Steven, Steven Legg wrote:
>>>>> Daniel Pluta wrote:
>>>>>> Steven Legg wrote:
>>>>>>> Daniel Pluta wrote:
> 
>> decision) denied. To give interested clients a chance to determine
>>  the server's time we suggest that the server should publish its 
>> current time to be query able for some kind of verification / 
>> debugging possibility.
> 
> The immediately preceding sentence is the answer to the "why?"; so 
> that clients can verify that the server's idea of "now" is 
> reasonable, or to debug unexpected results.

Ok, that's fine.


>> Let me now come to the still somewhat open question: "Where and 
>> how?" Q: Where should the time be published? Why within the 
>> Root-DSE, and not in each entry? A: In our opinion clients would 
>> ask servers seldom for their current time but there exist some 
>> justifications for clients to do so. The time information is very 
>> helpful especially in case of supposed errors or for debugging. 
>> Imagine replicated environments where one replica system for 
>> example is operating using the wrong system time. This would 
>> probably lead to strongly varying result sets depending on the 
>> server that answers the queries. Because the time is so seldom 
>> queried we prefer its publication within the "neutral zone" the 
>> Root-DSE, instead of attaching it using an extra attribute for each
>>  entry.
> 
> You haven't considered that the LDAP server a client is connected to
>  could be an X.500 server supporting a distributed DIT, or a virtual
>  directory.

As we've written (above and in our draft, sect. 7.3) we prefer and have
always preferred the Root-DSE. Publishing an additional operational
attribute carrying the current time of the server (an entry is delivered
from) has been mentioned (sect. 7.4) but left open for discussion to
determine whether such kind of information is useful for someone else.


> In both cases the result returned to the client can contain entries 
> contributed by more than one server, each of which has its own time.

Unlike your suggested approach using filter statements like for example
(&(currTime>=9:00)(currTime<=12:00)) to enable client side filtering for
an operational attribute called e.g. currTime that contains the server's
time during delivery our concept does not and has never had a need for 
such kind of attribute.

With your argument concerning the distributed DIT in mind this entry
local attribute does not seem to make sense (even in regard to your
scenario) so we tend to remove sect. 7.4 from the draft.


>> And finally the minor important question: Q: In case the server 
>> would already publish its current system time, what about 
>> additionally publishing the server's timezone?
> 
> Publishing the server time as local time plus time zone (which is 
> allowed by the Generalized Time syntax) allows UTC, server local time
>  or time zone to be recovered from the one value. I would recommend 
> doing that.

That's fine and it complies with what we've suggested in sect. 6.2.


> That is too inflexible. What you should be doing is extending the 
> access control mechanisms in OpenLDAP so that it is possible to 
> express which identities are permitted to apply which matching rules
>  to which attribute types. That, combined with the new matching
> rules, would allow you to do everything you want to do with the new 
> syntaxes and more besides. It would allow access controls to be 
> tailored for the needs of each service and could be applied to 
> syntaxes other than timestamps. It would also allow tighter controls 
> to be placed on existing attributes of Generalized Time syntax.

You're completely right here. We've also thought about that previously
but canceled it because in our opinion this won't be a general but only
a product specific solution.

[snip]

> That's what I don't like about the new syntaxes. Each new 
> authorization criterion needs a new syntax, so we get a proliferation
> of new syntaxes just like old syntaxes, but with special rules. Put
> the rules in the access control models where they belong.

Many thanks for this explanation. We have not thought about this, yet.
It obviously does not scale.


> I would rather do that in the access control mechanisms.

We too. ;-)

[snip]


Last but not least, towards an 01-version please let me give a first
short summary regarding the intermediate status of our ongoing
discussion (please feel free to comment):


General remarks:
- LDAP Server Side Current Time Matching seems to be of interest
- Steven, many thanks for the discussion and your valuable feedback!

Attribute Value Syntaxes to enforce/denie some kind of access:
- Doesn't seem to make sense in general - better use ACLs.
- No need for the many syntactically dedicated ext. matching rule

Matching Rules:
- Instead of all the extensible matching rules only two:
   - equality matching rule: "nowMatch"
   - ordering matching rule: "nowOrderingMatch"
   - both matching rules support now and timely offset matching
   - both matching rules support extensible match filters

Assertion Syntaxes:
- Two standalone assertion syntaxes preferred:
   - simple "NOW"
   - flexible X.680 (based on your already avail. implementation)
   - both compatible with the above matching rules
- Alternative:
   Differentiation between "now" and "nowOffset" assertion syntax
   not strictly needed: both can be integrated in one "Assertion
   Syntax" that supports any offset (also "NOW" using some kind
   of a zero offset?).
- In my opinion: "NOW" would offer improved readability

Operational Attribute for each Entry:
- Distributed DIT could result in many different "NOW"s
   - Currently there's no known use-case for something like this.
   - Remove from draft
[- Nevertheless, keep it just for informational reasons]?!

Root-DSE:
- "supportedFeature" seems to be ok
- "serverTime" whether in UTC or <g-differential> format
    - both seem to be reasonable


Best regards,
Daniel