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

Re: snmpconf General Functional Questions

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

I propose that the pmRoleESStatus be the place for the dirty bit. If that is
not acceptable, another object in this table.