[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf General Functional Questions
on 07/13/2000 12:23 AM, Steve Waldbusser at email@example.com wrote:
> Jon Saperia wrote:
>> on 07/06/2000 3:47 PM, Joel M. Halpern at firstname.lastname@example.org wrote:
>>> I had overlooked that (background change detection) proposal. That would
>>> indeed produce the results you propose. And was not what I was
>>> expecting. I had assumed that one would indeed modify some internal
>>> mechanisms so that if a change was being made to a variable which had been
>>> modified by policy, that the "don't touch" flag would get set.
>> Yes. The modification of the internal mechanisms to which you refer, does
>> not imply that one would need to modify the low level instrumentation as
>> Steve suggests.
> It requires a change to the snmp protocol engine and to the CLI command
> processor and any other engine that processes management commands. Such
> a requirement is pretty unprecedented in MIB development.
No, you assume a particular method of implementation. There is nothing in
the realization of the software to access the instrumentation such as an
interface counter object that is necessarily cognizant of how the request
got there. I will agree that with some systems this is easier to do than
with others. Many newer systems are implemented in the way I describe.
There are ways or 'retrofitting' this into architectures that have the
isolated CLI and SNMP systems that would be most problematic. I am working
on one such system now. How one works on this problem is a function of how
the system is put together.
> So far I've talked about the requirement for the operator to think
> twice before overriding a policy. The same is true when the tables
> are turned: When an operator overrides a policy to firefight a
> problem, the architect should think twice before returning it to
> policy control. The problem is that without an explicit forceOff
> state, the architect has no evidence that a modification to policy
> was done deliberately.
> I am opposed to the modified bit because it doesn't offer the right
> services to network architects and operators alike and secondarily
> because of the modeling and implementation problems it presents.
> The current solution (the forceOff bit), allows operators to override
> any policy that is causing operational difficulties (subject to
> access control, of course). Meanwhile, the network architect can be
> assured that policy overrides are applied only when necessary.
Several of us has stated a different view of this. There is no objection to
the foreOff bit. That said, we do not believe it is correct in this case, to
try to do social engineering by making it more difficult to do policy