Subject: Re: Event MIB typo?

From: Randy Presuhn <[email-masked]>
Date: Fri, 8 Nov 2002 18:42:22 -0800 (PST)

Hi -

> Message-ID: <[email-masked]>
> Date: Thu, 07 Nov 2002 14:12:33 +0000
> From: RP <[email-masked]>
> To: [email-masked]
> Subject: Event MIB typo?
> 
> I believe that I found a typo in draft-ietf-disman-event-mib-v2-01.txt 
> (or is it intentional?):
> 
> Section 6. Security - 3rd para.
> Model (VACM) defined in RFC 2275 [RFC2575] for tables in which
> 
> Shouldn't it be
> Model (VACM) defined in RFC 2575 [RFC2575] for tables in which

Yes, though the fix will be a bit more invasive.  The SNMPv3 RFCs
are in the final throes of editing, and new MIB boilerplate, as
well as updated security incantation are also being produced.
By the time the next update to the i-d comes out, these changes
will need to be applied.

> I have also a related question:
> "The security for remote access depends on the Target MIB". But the 
> target MIB does not store the auth and priv keys. How does the Event MIB 
> based DMs know this information?
> a) recording appropriate security credentials of the creator of an entry 
> and using it for remote access?
> b) reading the security credentials from an agent config file?
> c) reading the keys from usmUserTable?
> d) other?
...

I agree that this sentence leaves too much to the
imagination.  The descriptions of mteTriggerTargetTag and
mteEventSetTargetTag are supposed to explain the rest, with
RFC 2573 clause 2 as background.

The target lookup would give a set of sets of security
parameters, which in turn could be used to get the keys for
the respective systems from usmUserTable.

Ram: Did I get it right?

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  SJC-1.3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: RP <[email-masked]>
Date: Mon, 11 Nov 2002 08:49:28 +0000

> By the time the next update to the i-d comes out, these changes

OK. I did not see yet the SNMPv3 drafts. I will take a look into it to 
stop making unnecessary questions. ;)

> the respective systems from usmUserTable.

By the way, I still have another one:
The current approach to the delegation of security parameters to the 
Event MIB does not allow it to be built as an AgentX sub agent, or am I 
missing somethind?

Thanks for the answers.

Best regards,

Rui Pedro

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 11 Nov 2002 09:00:44 -0800

>>>>> On Mon, 11 Nov 2002 08:49:28 +0000, RP <[email-masked]> said:

rlopes> The current approach to the delegation of security parameters
rlopes> to the Event MIB does not allow it to be built as an AgentX
rlopes> sub agent, or am I missing somethind?

Correct.  It's not possible to build it in a subagent since the
polling of the localhost has to be done using same security parameters
that were used to set up the row, and there is no way for a subagent
to retrieve this information without using a proprietary extension.

It might be possible to do it via a non-local polling to the local
agent, if the target and usm mibs were also implemented in the
subagent (probably in a different context or something; IE, two
different target MIBs).

Anyway, the last time I asked this exact same question I got an "Why
would you want to do that?" answer.  IE, the expectation was that the
event mib wasn't even intended to be implemented in a subagent.
Therefore, the master agent should always do the monitoring of the
subagents rather than have the subagents do self monitoring of themselves.

-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett

---

From: Bob Natale <[email-masked]>
Date: Tue, 19 Nov 2002 13:21:21 -0500

At 11/11/2002:12:00 PM, Wes Hardaker wrote:

Hi Wes,

><...>

Yes, it sounds reasonable (esp. from an architectural perspective)
that "generic" services MIBs (i.e., those not directly related to
managed entity operations) might best be implemented at the master
agent level.  Several of the DISMAN MIBs are probably good examples
of what I think would be categorized as generic services MIBs.

>subagents rather than have the subagents do self monitoring of themselves.

Again, I think that approach serves the industry well, both from
an architectural perspective and from an ease-of-implementation
approach (for sub-agent developers).  This is particularly true
of SNMPv3 security.

Granted, additional capabilities must be added to AgentX before
such guidance can be implemented in a standard way (applies to
both the "generic services" and the "security control" guidance).
Carrying that discussion forward should probably be done on the
AgentX list, either now or as part of the future consideration
of AgentX as a candidate Full Standard.

Cheers,

BobN