Subject: RE: snmpconf General Functional Questions

From: Andrew Smith <[email-masked]>
Date: Fri, 9 Jun 2000 13:00:16 -0700

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

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Friday, June 09, 2000 12:43 PM
> To: [email-masked]
> 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.
> 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.
> 
> Yours,
> Joel M. Halpern
> 
> At 02:52 PM 6/9/00 -0400, Jon Saperia wrote:
> >If an element under policy control has any attribute (read 
> MIB Object)
> >changed that is under policy control, then it has the 
> exemption bit set that
> >Matt and I wrote about (the don't touch bit) set. It remains 
> in this state
> >until manually changed back. Dale made a good point that is 
> at some point
> >the policy might need to change.
>

---

From: Jon Saperia <[email-masked]>
Date: Fri, 09 Jun 2000 16:34:56 -0400

> change things at both SNMP manager and local interface].
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.

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

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

/jon