Subject: [Supa] Time as a dimension in policy

From: Dave Hood <[email-masked]>
Date: Wed, 9 Mar 2016 00:43:26 +0000

In looking at draft-strassner-supa-generic-policy-info-model-04, I found myself confused at the idea that all policy clauses were boolean, then realized that the root cause of my discomfort was the absence of a time dimension in the policy concepts. A quick look at RFCs 3060 and 3460 indicates that they also don't reflect the passage of time.

For this discussion, consider the event-condition-action model, but keep other models in mind for applicability.

First, events
We (I) think of policy as an algorithm that is evaluated from time to time, but not continuously with infinitesimal granularity (note). If this be true, execution of the algorithm is triggered by an event, which may be the tick of a clock. Taking the concept of state very broadly, event reports are generated by changes in state of some domain of interest. I assert that state is rarely boolean: more often than not, state is multi-valued, and may well be multi-dimensional. If we require an event to be a boolean clause, we must construct it along the lines:

(observedState == x) AND (in the most recent previous iteration of the algorithm, observedState <> x)

Surely it is more straightforward to recognize the event as the trigger for execution of the algorithm. (And besides, the expression above looks like a condition, not obviously an event.)

We may wish to filter events: if events a, b, but not c all occur within the most recent 1-second sliding window, then trigger the algorithm. Such an expression looks boolean, but it exists in time, not in the static space of logic. Binary is perhaps a better word than boolean; we do indeed expect a yes/no result from each term.

Note - applied to driving a car, an example of a policy in continuous time might be something like, "The center line shall be maintained on a visual reference point." Whether continuous time is of interest in our work is an open question: we speak of examples such as, "don't let server loading exceed x%" - how are we to understand the microscopic or even milliscopic time dependency of such a policy?

Second, conditions
When we begin the evaluation of a policy algorithm, we imagine that the universe freezes, or at least that we have a static snapshot substrate on which to perform the evaluation. Given that assumption - and it should be clearly stated - it is probably okay to evaluate conditions as booleans.

Third, actions
Actions necessarily involve a time aspect: as the result of a policy evaluation, we wish to change some state (or not). It is not clear how we would construct meaningful action clauses that were intrinsically boolean. Yes, they can be combined in boolean ways: (do action x) AND (do action y). Even here, the sensible combinations are limited. We would probably not say (do x) OR (do y), nor would we say (do x) AND (don't do y).

Am I completely off in the weeds on this? Or if this is all old news, could someone point me to the RFC (or other) material that rationalizes time into this story?

Thanks,
Dave

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 8 Mar 2016 19:56:41 -0800 (GMT-08:00)

Hi -

> From: Dave Hood
> Sent: Mar 8, 2016 4:43 PM
> To: "[email-masked]"
> Subject: [Supa] Time as a dimension in policy
..
> Am I completely off in the weeds on this? Or if this is
> all old news, could someone point me to the RFC (or other)
> material that rationalizes time into this story?

RFC 2981, 2982, and 2592/3165 address these issues in the
SNMP universe.

Randy