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

Re: snmpconf General Functional Questions

on 06/09/2000 4:00 PM, Andrew Smith at andrew@extremenetworks.com wrote:

> And, as Avri hinted, table (1) does need to be SNMP-writeable to satisfy the
> operational requirement of not having to go visit the wiring-closet again to
> restore things to normality [you have to make the assumption that suitable
> authentication is in force: only authorised people/tools are allowed to
> change things at both SNMP manager and local interface].
> Andrew
Sure. The table that I have been suggesting is our Role table. I do not
think we need another and that seems like the right place for it. If we do
that we meet the SNMP access rule.

I seem to have missed a note by Avri so I do not know what he said.

>> -----Original Message-----
>> From: Joel M. Halpern [mailto:joel@mcquillan.com]
>> Sent: Friday, June 09, 2000 12:43 PM
>> To: snmpconf@snmp.com
>> Subject: Re: snmpconf General Functional Questions
>> This is an implementable, well defined behavior.  I could
>> live with it.
>> It would be nice if the implementation were simpler than I imagine, so let me
>> describe what I think the implementation effect is: 1) There is a table of
>> objects for which the "do not touch" bit has been set.  When policy actions
>> are being considered, such objects may not be effected.  [This relates to the
>> question of failures of policies which effect several related objects.  TBD.]
>> This table probably should be SNMP visible.

We are in agreement. For me this is the Role table.

>> 2) There must be a table (whether visible to SNMP or not) or
>> all elements 
>> which have actually been touched by policy.  [Removal of
>> entries from this
>> table must be tied to the maintenance of policy and the
>> removal mechanisms
>> for policy.  It may need to know which policies touched the object to
>> handle policy removal).

>> 3) When an object is manipulated directly using low level
>> mechanisms (CLI,
>> SNMP, ...) the table in (2) is checked.  If the object is in
>> said table, 
>> then an entry is made in the table in (1).
>> This does seem to require updating the direct manipulation
>> subsystem when 
>> policy is added, which is unfortunate, but probably inevitable.
I agree. It is also true that many new systems are being developed such that
the CLI and SNMP infrastructures are more closely integrated - that is a
change by the CLI would be known by the SNMP infrastructure. There are
important reasons for doing this beyond the policy management problem. For
those vendors with other types of implementations connections can be made
but they are not quite so clean.