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

Re: snmpconf General Functional Questions



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. 

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.

dbh

Jon Saperia wrote:
> 
> on 06/12/2000 4:46 AM, Dan Romascanu at dromasca@lucent.com wrote:
> 
> > Jon,
> >
> > I think that making the solution TOO simple, may result it in being
> > implementable and deployable, but not useful. We probably agree on this.
> 
> I think we do.
> >
> > However, I do not understand your example about the 'exempted' element. Do
> > you mean that once a value was overridden, the respective instance can't be
> > touched any longer, until the 'touch' bit in Joel's second table is cleared?
> > Who clears this table?
> >
> I mean that the respective instance will be skipped each time a policy is
> evaluated in the device that 'touches' that instance. This is like adding
> another attribute/role to the instance that causes it to 'fail' the role
> match in our system. This is how the policy system will know how to exempt
> it. The attribute might be the 'exempt' attribute. It would have been placed
> there if that instance had been touched by a mechanism other than the policy
> system, for example a CLI, web interface, or a non-policy SNMP manager. The
> way this works is that the policy system has access to the instances by
> definition. It also knows if it changed a value or not.
> 
> I have not heard any objection to using the role table, so I assume for now
> that is where this attribute is stored though that is not very important.
> Once set the only way to reset it is by direct action on this attribute for
> this instance. In an SNMP case the manager would sent a set to remove the
> attribute. Certainly we have experience with enabling CLI's to have access
> to such objects and I would have the CLI also able to remove this attribute.
> 
> /jon

-- 
---
David Harrington            Network Management Architect Engineer
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA