Subject: RE: Condition MIB Issue List

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Fri, 7 Dec 2001 00:14:38 -0500

Hi,

I have identified one more issue for the Condition & ARC MIB. 

Cond#5: There is a need for a management system to create a new arcEntry in
the arcTable for provisioning a new ARC control (i.e., creating a conceptual
row in the arcTable).

A solution to this issue is: use the RowStatus Textual Convention.
That is, add a columnar object arcRowStatus with syntax RowStatus in the
arcTable. So a new ARC control can be provisioned by setting the value of
RowStatus to createAndGo or createAndWait.

Regards,
Kam  

> -----Original Message-----
> From: Lam, Hing-Kam (Kam) 
> Sent: Wednesday, November 28, 2001 1:17 PM
> To: Lam, Hing-Kam (Kam); [email-masked]'
> Cc: [email-masked]'; 'David Perkins'
> Subject: RE: Condition MIB Issue List
> 
> 
> 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,
> > 
> > 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-conditio
> nmib-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".
> 
> 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."
> 
> >
> >Cond#2: Alarm Definition (section 3.2) & AlarmType text convention
> >   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.
> 
> >
> >Cond#3: Readability of Section 4.1 (Role of the Condition MIB)
> >   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)."
> 
> >
> >Cond#4: Relationship between ARC and Condition notifications 
> (section 5.1)
> >   ARC should have the similar impact on condition 
> notification as on alarm
> >   notification.
> 
> 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."
> 
> >Regards,
> >Kam Lam
>