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

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 16 Oct 2003 16:16:20 -0400

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: Thu, 16 Oct 2003 14:03:46 -0700

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

> Sent: Thursday, October 16, 2003 1:16 PM
> Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 16 Oct 2003 14:03:46 -0700

Hi -

Randy