[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf General Functional Questions

  I agree that the "touch-bit" needs to be instance specific, but placing it in
the role table is pretty heavyweight because it will turn off *all* policies
that control a particular element. Say I need to override a variable for
firefighting purposes but I don't want to also turn off the policy that applies
QOS to that interface (because that might cause another firefight). The
"touch-bit" should turn off a particular policy from a particular instance.

In the current draft, such a facility exists:

PmTrackingElementToPolicyEntry ::= SEQUENCE {
    pmTrackingElementToPolicyElement          RowPointer,
    pmTrackingElementToPolicyStatus           INTEGER
    INDEX       { pmTrackingElementToPolicyElement, pmPolicyIndex }

pmTrackingElementToPolicyStatus OBJECT-TYPE

The forceOff state is the touch-bit. When set, it forcibly disables this policy
from executing on this element.

Also, I don't believe in having these bits set as side-effects of setting an
SNMP variable. Reasons include:
1) An SNMP set for a variable that is under policy control doesn't communicate
the following necessary sentiment: "While I know that this variable is under
policy control, I intend to override that anyway". In other words, the SNMP
engine can't tell whether the request intended to override policy or was an
innocent mistake. It would be hard to say that we're enforcing policy when any
request has carte-blanche to get an exemption.
2) Would require changing instrumentation for all MIBs
3) Doesn't specify which policy to override in those cases where a single
variable is under control of multiple policies.


Jon Saperia wrote:

> on 06/12/2000 1:15 PM, David Harrington at dbh@enterasys.com wrote:
> > Hi,
> >
> > I think the exempt bit needs to be instance-specific, to tell which
> > instance has been overridden. If the "touch-bit" can be cleared via
> > SNMP, it will be important to know WHICH instance should be cleared if
> > there are multiple instances that have been touched.
> Exactly so. We are all in agreement on this point. That is why I have
> proposed using the role table which is instance specific.
> >
> > It may also be important for tracking down a security breach to expose
> > which instance was changed.
> >
> > Having the "touch-bit" at the role-abstraction level doesn't allow the
> > necessary granularity. I think it might be nice to have a dirty-flag at
> > the role level, to easily indicate that one or more instances of the
> > role have been overridden. However, I am concerned that having the
> > touch-bit at this level may be problematic. It may be difficult to go
> > from the instance level to the role level easily, as has been discussed.
> > This becomes harder in a mid-level manager situation, where the role
> > evaluation may be done within a different engine, as discussed at the
> > interim meeting.
> >
> PmRoleESEntry ::= SEQUENCE {
>     pmRoleESElement        RowPointer,
>     pmRoleESString         SnmpAdminString,
>     pmRoleESStatus         RowStatus
> }
> Roles are assigned on an instance specific basis. That is the only way the
> local mechanisms can know were to apply the policy. I do not see the role
> evaluation taking place remotely. One a large machine with many interfaces
> and/or S/PVCs numbering into the many hundreds of thousands, the evaluation
> has to be done locally. This does not mean that a MLM can not participate
> since the MLM application would send the policy filters to the targets for
> evaluation.
> I propose that the pmRoleESStatus be the place for the dirty bit. If that is
> not acceptable, another object in this table.
> /jon