Subject: Re: snmpconf out-of-policy indications

From: Jeff Case <[email-masked]>
Date: Fri, 7 Jul 2000 18:18:07 -0400 (EDT)

>I think there may be a need for an out-of-policy-state notification
>(which the architect may choose to disable or filter via snmpv3) for
>security/auditing purposes.

or use of multiple logical contexts wherein the only objects accessible
in that mib view are the ones that would be altered by a given policy
or policy change

we need to get a greater appreciation for what multiple logical contexts
can/could do for us

i am not disagreeing ... this is not an either/or choice required

regards,
jdc

---

From: Jon Saperia <[email-masked]>
Date: Sat, 08 Jul 2000 10:10:13 -0400

> i am not disagreeing ... this is not an either/or choice required

I think Jeff is correct, these are not mutually exclusive. Here is an
attempt to describe what I think helpful with regard to out of policy
changes. The only point of disagreement that I know about in this area is
that Steve would like to have a user making an out of policy change have to
modify an object as an extra safety measure. I am not sure that would really
be all that beneficial or produce the result he desires. Here are some
comments, most of which belong in the BCP - though one, the modified(3)
value we have discussed quite a lot does belong in the Policy Module.

1. A notification should be sent whenever an out of policy control change is
made to an element that is under the control of policy. (I will say more on
this in the BCP).

2. I had proposed the use of contexts earlier as Jeff suggests here. This
can only help. I am not sure that is part of the MIB Modules we are
developing, but probably should be in the BCP. Suggestions appreciated.

3. An element under the control of policy that has been changed remains a
member of the policy group until the attributes in the Role table that
caused it to match the policy in the first place are modified.

4. An element that has been modified by a human, while remaining a member of
the policy does not get overridden by a policy until its value is made the
same as the extant policy with the highest precedence for this element, and
by implication then returned to policy control - see my next note. I had
mentioned in a note a long time ago that a reload of a policy to a system is
the brute force way of overriding all overrides.

/jon