Subject: MIB views and agentx

From: Sivakumar Narayanan <[email-masked]>
Date: Mon, 03 Aug 1998 13:15:56 -0700

Hi,

I have been reading the agentx rfc.

One thing is not clear to me.  The agentx-based subagents will be
ignorant of MIB views and access lists.

Suppose we implement an enterprise-specific MIB in an independent
subagent; and suppose that the MIB defines RMON-like alarm tables to
monitor specific objects.  If the user tries to create a new entry, how
can the subagent know if the particular mib object A corresponding to
"The variable to be monitored" exists in the particular MIB view ?

There is a possibility that the current MIB view does not even allow
read access to the object A.  So, setting up an alarm for this variable
is not allowed.  But, how can the subagent know from the master whether
A exists in the current MIB view or not?

Any help is appreciated.

Thanks,
Siva

--
Sivakumar Narayanan             Silicon Graphics Inc.
Tel# 650 933 5249 (W)    Email: [email-masked]

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 3 Aug 1998 15:19:11 -0700 (PDT)

Hi - 

> Date: Mon, 03 Aug 1998 13:15:56 -0700
> From: Sivakumar Narayanan <[email-masked]>
> To: [email-masked]
> Subject: MIB views and agentx
...
> ignorant of MIB views and access lists.

This is correct and intentional.

> "The variable to be monitored" exists in the particular MIB view ?

The subagent should not need to know this.  Since the access control
policy may change over time, the access decision function will have to
be consulted when access is actually attempted, since the decision may
be different from what would have resulted with the entry was created.

The real question, then, is how does the monitor program make its
requests?  The answer is simple: SNMP.  The subagent with the RMON-like
table you describe would take a command generator role.  The access
decision function is consulted by the management application in the
command responder role, not this RMON-like command generator.

Now, in both the Disman and the SNMPv3 work we've said over and over
that a particular implementation might provide all sorts of specialized
infrastructure to do this efficiently.  Architecturally, however, its
pretty simple, as long as this RMON-like process acts on its own behalf.
If the it needs to act on behalf of the user making the original request,
life gets much more interesting.  See the disman archives for more
on this.

> A exists in the current MIB view or not?
...

But what if the access policy is later changed to permit access?
I think it's not a good idea to base access control decisions on 
old information. 

 -----------------------------------------------------------------------
 Randy Presuhn           Email: [email-masked]      http://www.bmc.com     
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy, I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 -----------------------------------------------------------------------