Subject: Condition MIB Issue List

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 28 Nov 2001 10:22:16 -0500

Hi,

Listed below are the issues that I have identified 
for the Condition & ARC MIB, which is now at
http://www.ietf.org/internet-drafts/draft-ietf-disman-conditionmib-01.txt. 

I will use a separate email to propose solutions for the issues.

Cond#1: Terminology (section 3.1)
   Condition: The current wording doesn't clearly give the definition
   of the term "Condition".
   Alarm "set", "clear", "raised": Need to align with the Alarm MIB.

Cond#2: Alarm Definition (section 3.2) & AlarmType text convention
   This section is not complete. Does it need to be in this document?

Cond#3: Readability of Section 4.1 (Role of the Condition MIB)
   Rearrange the figure and text of this section to improve the readability.

Cond#4: Relationship between ARC and Condition notifications (section 5.1)
   ARC should have the similar impact on condition notification as on alarm
   notification.

Regards,
Kam Lam

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 28 Nov 2001 13:17:29 -0500

Hi,

See inline for my proposed solution.

Regards,
Kam Lam

> -----Original Message-----
> From: Lam, Hing-Kam (Kam) [mailto:[email-masked]]
> Sent: Wednesday, November 28, 2001 10:22 AM
> To: [email-masked]'
> Cc: [email-masked]'; 'David Perkins'
> Subject: Condition MIB Issue List
> 
> 
> Hi,
> 

>   Condition: The current wording doesn't clearly give the definition

Build the definition of Condition upon the definition of Event. 
So, replace the current definition of Condition by the following:

   "A condition is an abnormal event that worth the attention of the
managing system.
    A condition can be a standing condition or transient condition.
    A condition does not have to be an error or fault."

Since the definition of Condition is built upon that of Event, 
so move the definition of Event to before that of Condition.

>   Alarm "set", "clear", "raised": Need to align with the Alarm MIB.

I don't see any difference between "alarm is set" and "alarm is raised".
I propose merge "set" and "raise" into one term, namely "raise", and use
similar
definition from the Alarm MIB. That is:

   "Alarm Raise: The initial detection of the fault. 
    A notification SHOULD be sent on alarm raise."

>   This section is not complete. Does it need to be in this document?

I propose removing this section from the document. 
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.

>   Rearrange the figure and text of this section to improve the
readability.

In this section (4.1), move the text to before the figure. Also, move the
last 
paragraph to become the second sentence in the first paragraph. 
That is, the text become:

  "The relationship of the Condition MIB and the generic alarm MIB in a
   distributed management environment is illustrated in Figure 1.  
   The generic alarm MIB provides a high level view of the network device 
   status while the Condition MIB reports the detail information to identify
the
   source of an abnormal condition in a large scale network devices.
   The Condition MIB is defined in this document.
   The Generic Alarm MIB refers to draft-ietf-disman-alarm-mib-xx.txt

   Depending on the size and the architecture of the management network,
there
   may be multiple level of management systems in a large scale network
   case 1, 2, or 3) or a single management system (case 4)."

>   ARC should have the similar impact on condition notification as on alarm

ARC shall have the similar impact on alarm notifications (alarmRaise and
alarmCleared) and condition notifications (conditionActiveEvent and 
conditionRetiredEvent).
I propose replacing the first two sentences of Section 5.1 by:

   "The ARC mode SHALL have the following impact on alarm notifications 
    (alarmRaise and alarmCleared) and condition notifications 
    (conditionActiveEvent and conditionRetiredEvent)"

No change to the three dash items, which describe the impact.

In the Condition MIB, there is a feature for suppression notification
based on the condition severity level. The relationship between suppression 
by severity level and suppression by ARC (which is based on resource and 
condition type) needs to be explicitly explained.
When an alarm condition is raised, the potential notification should be 
screened by the ARC function first (if ARC is supported). If this potential
notification is not suppressed or deferred by the ARC function, then it will
be
further screened by the Suppression-by-Severity-Level function (if it is
supported).
So I propose adding the following text at the end of Section 5.1.

   "If both the functions of Suppression by ARC and Suppression by Severity
Level 
    are supported in a device, then when an alarm condition is raised, 
    the potential notification should be screened by the ARC function
first." 

In addition, I propose the following editorial update for clarification
purpose.

Add the following sentence at the beginning of the third paragraph of
Section 5.

   "A resource is said to be in ARC mode if notification suppression by ARC
is
    in effect."

Add the following sentence at the end of the third paragraph of Section 5.

   "When a resource is in the ARC mode, active alarm information SHALL still
be
    available for retrieval by the managing system."