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

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 17 Oct 2003 07:53:00 -0400

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

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:0S00:EXCH] 
Sent: Friday, October 17, 2003 7:37 AM
To: Disman (E-mail)
Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt

Hi

How about

 "  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 pair is its own list."

The point of the text was really just to address the multi-context thing, so
removing the IP reference makes it cleaner.

Sharon

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

Hi -

I still don't see why the "should" language is needed.  Am I being
unnecessarily dense?  Did I miss where the i-d explains why applications
should do this?

Also, context/IP is *not* enough to uniquely identify a source.  Think DHCP.
That's why I proposed the more general language.

Randy

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Sent: Thursday, October 16, 2003 1:16 PM
> Subject: RE: [Disman] Section 3.3.5 of
> draft-ietf-disman-alarm-mib-15.txt
>

> Hi
>
> The following is the proposed resolution to Randy-26  Assuming no 
> objection, this item will be considered closed conditional on the 
> proposed edit being done.
>
> In section 3.3.5 replace
>
> "   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 differentiate the
>    source of the alarm by means other than the source IP address and
>    resource ID should create separate alarm lists such that each
>    context/source IP address pair is its own list."
>
> With
>
> "  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 should create separate alarm lists
>    such that each (context, source IP address) pair is its own list."
>
> Sharon
>
> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Friday, October 03, 2003 1:50 AM
> To: Disman (E-mail)
> Subject: [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]>
> > Cc: <[email-masked]>; "Randy Presuhn" 
> > <[email-masked]>; "Romascanu, Dan (Dan)"
> <[email-masked]>
> > Sent: Monday, September 29, 2003 7:34 AM
> > Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt
> ...
> > 26) Section 3.3.5: "Solutions interested in being able to 
> > differentiate
> the
> >    source of the alarm by means other than the source IP address and
> >    resource ID"  is at odds with what's actually done in the
> >    alarmActiveEntry and alarmClearEntry.  Both include information
> >    for the LocalSnmpEngineOrZeroLenStr, AddressType, EngineAddress,
> >    and ContextName.
> ...
>
> The text still doesn't match the actual operation of the MIB. The 
> current text says:
>    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 differentiate the
>    source of the alarm by means other than the source IP address and
>    resource ID should create separate alarm lists such that each
>    context/source IP address pair is its own list.
>
> 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: Fri, 17 Oct 2003 11:16:32 -0700

Hi -

> Sent: Friday, October 17, 2003 4:53 AM

...

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

...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 17 Oct 2003 11:16:32 -0700

Hi -

...

...

Randy