Subject: Condition MIB Issues

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 11 Dec 2001 20:10:57 -0500

hi

n. The condition MIB defines terms related to alarms, where I
  thought we had previously agreed that the Alarm MIB would
  define Alarms, the condition MIB would define conditions
  and each draft would point at the other draft for needed
  definitions.
  Plus, section 3.2 discusses alarms in a way that seems to have
  nothing to do with either what is defined in the Alarm
  MIB or the condition MIB.

n+1. We had previously agreed to remove figure 1 since these sorts
   of architectures are generally not defined in RFCs. Plus,
   it is one architecture, but neither a representational one
   or necessarily the recommended one.

n+2. There is discussion in the draft as to how the Alarm MIB is
   suited for medium sized systems while the condition MIB is
   suited for large system but there is no explanation or
   justification of this claim. In theory, as the condition MIB
   is suppose to provide more detail than the alarm MIB, this
   could be argued. In practice, the MIB is not there yet.
   We still don't have condition profiles and I saw nothing 
   in the issues list to indicate if this concept is under
   development or been dropped.  Unless I'm missing something
   what is currently in the condition MIB can still be supported
   using the Alarm MIB by modelling events as alarms of no duration.
   I'd like to see more differentiation.

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 12 Dec 2001 10:55:43 -0500

Hi, 

See comments inline.

Regards,
Kam

> -----Original Message-----
> From: Sharon Chisholm [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2001 8:11 PM
> To: disman
> Subject: Condition MIB Issues
> 
> 
> hi
> 

Agree. Reference the Alarm MIB for the following definitions:
Event, Error, Fault, Alarm, Alarm Raised, and Alarm Cleared.

>   MIB or the condition MIB.

Agree. In fact, in my previous email (12/7), I proposed to remove this
section for the following reason:
The textual convention for AlarmType, if useful, can be done in a 
separate document. In fact, the Condition Types used in the Condition MIB
are 
based on the ITU-T probable causes, so it is more appropriate for ITU-T 
to provide the attributes (raise criteria, clear criteria, source 
identification, etc.) for the probable causes.

>    or necessarily the recommended one.

I thought he intent of figure 1 and the section (Section 4.1) is to show the
role
(i.e., application) of the condition mib. It was generated to reflect the
recommendation from the Minneapolis meeting that the Condition MIB is suited
in the sub-agents for large scale NEs.

If there was a agreement for removal, then I must miss it.
Will some text to clarify that is the figure is just an illustrative example
help? 

>    justification of this claim. 

See above: 
The recommendation from the Minneapolis meeting that the Condition MIB is
suited
in the sub-agents for large scale NEs.

>    In theory, as the condition MIB
>    development or been dropped.  

Anni had provided an initial thought of a condition severity profile.
But that work has never been followed-up on.
(See attached email for that initial draft.)
Severity is used by both the Condition Mib and the ITU Alarm MIB. 
Adding the Condition Severity Profile will support both.

The Condition MIB document now has two modules in it - the Condition MIB
module and
the ARC MIB module. The Condition Severity Profile could be the third
module.
  
>    Unless I'm missing something

Regards,
Kam

Subject: condSeverityProfile
From: a huynh <[email-masked]>
To: Sharon Chisholm <[email-masked]>, A Huynh <[email-masked]>, "Lam, Hing-Kam (Kam)" <[email-masked]>, David Perkins <[email-masked]>, r presuhn <[email-masked]>, Dan Romascanu <[email-masked]>
Date: Mon, 10 Sep 2001 09:20:05 -0500

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 12 Dec 2001 12:38:41 -0500

hi

<Sharon 1>
>    or necessarily the recommended one.

<Kam>
I thought he intent of figure 1 and the section (Section 4.1) is to show the
role
(i.e., application) of the condition MIB. It was generated to reflect the
recommendation from the Minneapolis meeting that the Condition MIB is suited
in the sub-agents for large scale NEs.

</kam>

I don't think it's a very representative example architecture and just
causes confusion. I'd like to see it removed altogether like previously
discussed. I think Anni was present for that conversation. 

<Sharon 1>
>    justification of this claim. 
</Sharon 1>

<Kam>
See above: 
</Kam>

Actually I believe the discussion said that the condition MIB would be
best implemented by distributing it through sub-agents,
not that it was the best solution for systems that had sub agents.

In theory, the condition MIB is suppose to be providing more granular 
information about what is happening on the system. This level of information
is not really a function of the size of the system, but on the requirements
of the box, the operator and the manager. The Alarm MIB provides a view
of what problems are occurring on a box. The condition MIB provides a view
of both alarms and events that have happened on the box and also relates to 
the alarm suppression. I'd like to see the draft focus on what value it is
adding that might make it useful to support it on large systems, instead of
just claiming it is needed for large systems.

Plus, there is still the issue that what is currently in the MIB portions of
the draft do not live up to these claims. I think there is more work still
to be
done to get where we said we wanted to be.

Sharon