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

Re: snmpconf General Functional Questions



There are at least two problems that I see being aluded to here.  Both are 
related to the phrase "if a variable is unde3r control of more than one 
policy".  We do need to make sure we understand what we want to happen in 
that case.

1) If you set that variable with SNMP, assuming that the intention is to 
override the policy setting of that variable, then I believe that you are 
overriding ALL the policies which set that variable.  Trying to achieve 
some intermediate state where some of the policies apply to that variable, 
but not all of them, would be better done by actually changing the set of 
roles, rather than trying to force-off.  force-off is for the case when the 
manual intervention is moving the variable out of the policy space temporarily.
2) In practice the variable can not really be set by more than one 
policy.  There is some sort of conflict which has essentially been resolved 
by "last touch wins".  Unless we are forcing order of evaluation of policy 
(and what about order of re-evaluation?) such a conflict resolution 
mechanism is exceedingly risky.  This goes on the conflict resolution thread.

Related to this, I believe that the intention of most of the discussants is 
that if a human being directly modifies a variable whose current state was 
effected by policy, then that variable better be removed from policy 
control automatically.  Otherwise, the user will get unexpected effects 
wherein his changes evaporate periodically (or even worse, some of them 
evaporate, but not all).

Yours,
Joel M. Halpern

At 03:45 AM 6/30/00 -0700, you wrote:

>   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
>     SYNTAX      INTEGER {
>                     off(0),
>                     on(1),
>                     forceOff(2)
>                 }
>
>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.
>
>Steve
>
>
>
>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