Subject: PVP timeout wording

From: "Chris Martin" <[email-masked]>
Date: Wed, 17 Feb 1999 19:36:26 -0500

Per the discussion at the IETF meeting, I propose an additional
paragraph to section 5.5 (the second one) for clarification purposes.
The proposed text supports the current understanding that PVP conditions
can act as a "scheduler". From my viewpoint, this has the impact of
changing the interpretation of policy rules from "if <cond(s)> then
<action(s)>" to "when <cond(s)> then <actions(s)>". The intent is *not*
to restrict the use of PVP, but to identify the potential for implicit
action(s) associated with the PVP condition.

The proposed text (second paragraph) is included below.

chm

5.5  The Class policyValidityPeriodCondition

This class provides a means of representing the time periods during
which a policy rule is valid, i.e., active.  At all times that fall
outside these time periods, the policy rule has no effect.  A policy
rule is treated as valid at all times if it does not specify a
policyValidityPeriodCondition.

The actions taken by a PDP resulting from the enabling (disabling)
of a policy rule at the beginning (end) of a
policyValidityPeriodCondition
timeframe depend on the decision context.  For instance, the
policyValidityPeriodCondition may be used to enable scheduled
activation and deactivation of a policyRule.  Additionally,
policyValidityPeriodCondition may serve as a qualifier to
another activity requiring a policy decision, for example to identify
when an authentication policy applies for a user login.

PolicyValidityPeriodCondition is defined as a subclass of
policyCondition.  This is to allow the inclusion of time-based
criteria in the AND/OR condition definitions for a policyRule.

Instances of this class may have up to five attributes identifying time
periods at different levels.  The values of all the attributes present
in an instance are ANDed together to determine the validity period(s)
for the instance.  For example, an instance with an overall validity
range of January 1, 1999 through December 31, 1999; a month mask of
"001100000000" (March and April); a day-of-the-week mask of "0000100"
(Fridays); and a time of day range of 8 AM through 4 PM would represent
the following validity periods:

    Friday, March  5, 1999, from 8 AM through 4 PM;
    Friday, March 12, 1999, from 8 AM through 4 PM;
    Friday, March 19, 1999, from 8 AM through 4 PM;
    Friday, March 26, 1999, from 8 AM through 4 PM;
    Friday, April  2, 1999, from 8 AM through 4 PM;
    Friday, April  9, 1999, from 8 AM through 4 PM;
    Friday, April 16, 1999, from 8 AM through 4 PM;
    Friday, April 23, 1999, from 8 AM through 4 PM;
    Friday, April 30, 1999, from 8 AM through 4 PM.

Strassner, et. al               Expires 8 August 1999          [Page 24]

INTERNET DRAFT      draft-ietf-policy-core-schema-01.txt        8 Feb 99

Attributes not present in an instance of policyValidityPeriodCondition
are implicitly treated as having their value "always enabled". Thus, in
the example above, the day-of-the-month mask is not present, and so the
validity period for the instance implicitly includes a day-of-the-month
mask containing 31 1's.  If we apply this "missing attribute" rule to
its fullest, we see that there is a second way to indicate that a
policy rule is always enabled:  have it point to an instance of
policyValidityPeriodCondition whose only attributes are its naming
attributes.

The class definition is as follows.
...