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

Re: snmpconf General Functional Questions



on 07/06/2000 5:23 PM, Steve Waldbusser at waldbusser@nextbeacon.com wrote:

> All I want is for the field engineer to have to do something special
> to override a policy. Shouldn't he at least know that he has done
> something significant? Wouldn't it be good if he was thus encouraged
> to think twice? Wouldn't it be good if he was encouraged to mention it
> to the network architect? ("hey, I needed to disable the blah policy
> on trunk 7 last night because it was interacting poorly with the
> backup circuit").
> 
> My proposal is that he issue 2 commands rather than one. The first
> disables the policy on the interface and the second is a normal
> SNMP set that makes the change.

Steve, I am in agreement with your concern. I think we can accomplish this
without having to issue two commands though. You gave the example of not
running as 'root' to avoid making mistakes - most of us have learned that
lesson. My point is that the access/change of policy is an operational
policy (forgive the pun) decision. If a system is under policy control,
access to the MIB tree that contains everything except the policy objects,
should be quite restricted. The operator would then have to use the root
password to make the changes. This is analogous to 'su root' make all your
changes and exit. Your preference would be to have the person 'sudo change
1', 'sudo change2' etc. In our case the equivalent of the sudo is to make
the explicit something special you suggest.

I do not think either of the two approach we discuss is very bad since they
do allow for policy override, which is my primary concern. I think Joel said
it pretty well: 

> 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.


/jon