Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 19 Oct 2003 14:32:32 -0400

Hi

Because you can't assume that IP and resourceId is sufficient to identify
the source of an alarm when you support multiple context can you?

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Friday, October 17, 2003 2:17 PM
To: Disman (E-mail)
Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Sent: Friday, October 17, 2003 4:53 AM
> Subject: RE: [Disman] Section 3.3.5 of 
> draft-ietf-disman-alarm-mib-15.txt
>

> Hi
>
> Oops.
>
>  "  The Alarm MIB provides a generic method for identifying the resource
>     by extracting and building a resource ID from the Notification
>     varbinds. Solutions interested in being able to specify alarms from
>     sources in different SNMP contexts can create separate alarm lists
>     such that each context is its own list."
...

Why would they (want/need) to create separate alarm lists in order to
specify alarms from sources in different SNMP contexts?

I'm glad the IP business is resolved, but I return to my original question:

> > I still don't see why one would need to create separate alarm lists, 
> > nor do I see why we're talking about IP addresses when one also 
> > needs a port (if one is even using IP!) to find an agent.
> >
> > Proposed replacement text:
> >    The Alarm MIB provides a generic method for identifying the resource
> >    by extracting and building a resource ID from the Notification
> >    varbinds.  It records the relevant information needed to locate the
> >    source of the alarm.
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Oct 2003 19:25:23 -0700

Hi -

> Sent: Sunday, October 19, 2003 11:32 AM
> Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt
>

> the source of an alarm when you support multiple context can you?

Presumably that's why an active alarm entry has all of
alarmActiveEngineID, alarmActiveEngineAddressType,
alarmActiveEngineAddress, and alarmActiveContextName.
Since all that information is present in an active alarm entry,
I'm still left asking why a management system would need to
request that they be put into separate lists in order to "specify
alarms from sources in different SNMP contexts".

I'm not trying to be dense here.  I can understand *other* reasons
why an application or security administrator might want  various
active alarms to go into different lists, but I *don't* see why it would
be necessary to do so for purposes of specifying or distinguishing
multiple alarm sources.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Oct 2003 19:25:23 -0700

Hi -

Randy