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

Re: snmpconf General Functional Questions

"Joel M. Halpern" wrote:
> If they have the access to write directly to the
> variable, then they should be able to do so.  They should not have to
> understand the policy tables and find the correct place to markt "I mean
> this"  If they are making the change, they mean it.
> Fundementally, you are arguing that putting an object under policy control
> should remove it from SNMP control unless it is explicitly removed from
> policy control first.  I am arguing that the act of directly setting the
> attribute seems to me to be quite clear enough.

I believe the main constituency for policy-based management is the
architect/engineer who is sick and tired of the ad-hoc nonsense that 
continuously creates problems. Maybe rigorous training of everybody who 
touches the network could solve this problem, but with staff turnover
the constant stream of vendor staff, consultants and service provider
in and out the door, this is impossible.

Policy-based management can help the network architect make everything

Now you say "if they are making the change, they mean it". Well, when an 
entry-level technician makes an out-of-policy change, two things are
1. The technician meant it
2. The network architect wants to bash his brains in with a 2x4. 
   The architect DIDN'T MEAN IT.

Thus, there are 2 constituencies. One is tactically focused and one is 
strategically focused. 

The tactical constituency is the only one that has been represented so
WRT SNMP configuration. We are here to provide a tool for the strategic 
constituency that lets them enforce the strategic goals. We can't let 
ad-hoc SETs always win or we haven't provided any enforcement

So far I've only been talking about the case where the technician "meant
What about the case where nobody meant it?:
- I made a mistake
- I didn't know what I was doing
- I ran an old script, I didn't realise what it did.

> 2) If you require people to explicitly mark that they want to override
> policy, they will forget.  They will be surprised and confused when the
> system does things that they do not expect.

This is better than having the network architect be surprised and

Yes, sometimes they will forget. They will have to learn. (An aside: it
be great if we could figure out how to give them more instant feedback
requiring changes to existing SNMP instrumentation).

Sometimes the architect and the tech mean different things. Sometimes
architect is wrong and sometimes the tech is wrong. We can't assume that 
either is always right. The middle ground is to require that the tech
special action for those things under policy control - to acknowledge
what they are about to do is a conscious decision to violate the policy.

No more unreasonable than "Delete all files. Are you sure?"