Subject: RE: Progressing the Condition/ARC MIB

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Tue, 5 Feb 2002 16:25:00 -0500

Dear All,

Up to now, I didn't hear any opinion to the proposal I have made. May I
interpret this as no objection. If so, then the remain issue is the
relationship of the Condition MIB to the Alarm MIB. Any input?

Regards,
Kam

> -----Original Message-----
> From: Lam, Hing-Kam (Kam) [mailto:[email-masked]]
> Sent: Thursday, January 10, 2002 4:47 PM
> To: [email-masked]'
> Subject: Progressing the Condition/ARC MIB
> 
> 
> In the Salt Lake City meeting, the Condition/ARC MIB
> http://www.ietf.org/internet-drafts/draft-ietf-disman-conditio
> nmib-01.txt
> was discussed and some open issues were noted (see the meeting details
> posted by Randy on December 18).
> 
> To progress the Condition/ARC MIB, I have extrated those open 
> issues to here
> to solicite your input. The issues are mainly related to the 
> terminology,
> definition, and relationship with the Alarm MIB (Sections 3, 
> 4 and 5 of the
> document).
> Attached is the modified Sections 3, 4, & 5 for your comments.
> 
> > 4. Condition MIB and ARC MIB
> > - changes from version 00 to version 01
> > - open issues
> > - terminology - condition to be taken on the mailing list - Kam to
> > initiate the thread
> 
> One of the comments on the document is that it should point 
> to the alarm MIB
> for the definitions. Agree. Once the definitions (Error, 
> Fault, Alarm, Alarm
> Raised, Alarm Cleared, Event, and Notification) are removed, 
> the only term
> left is Condition. So I think the current Section 3.1 
> "Terminology" can be
> deleted and embed the definition of Condition in the first 
> couple paragraphs
> at the beginning of Section 3 as follow.
> 
>    The Condition MIB module defines MIB objects and 
> notifications that 
>    provide mechanism to monitor abnormal conditions currently active 
>    and the history of abnormal conditions being set and cleared on a 
>    managed system.
> 
>    The list of abnormal conditions that can be monitored by 
> using this 
>    MIB are based on the Probable Causes defined in ITU-T 
> Recommendations 
>    M.3100, X.733, and X.736. A textual convention, 
> IANAItuProbableCause, 
>    has been defined in the Alarm MIB to assign values to the ITU-T 
>    Probable Causes. The IANAItuProbableCause textual 
> convention is being 
>    used by the Condition MIB to represent the abnormal conditions. 
> 
> > - Alarm Raised and Clear - should point to the Alarm MIB
> 
> Agree. See the attached file, Section 3.
> 
> > - Alarm type definition  - delete section 3.2
> 
> Agree. See the attached file, Section 3.
> 
> > - Section 4.1 readability  - text needs fixing, diagram 
> should be taken
> > out
> 
> Agree. See the attached file, Section 4.1. The diagram and 
> associated text
> have been deleted.
> 
> > - change 'clarification' in Section 5 that says that when a 
> resource is
> > in ARC mode active alarm information SHALL be available for 
> retrieval by
> > the managing system - change active alarm with condition information
> 
> Agree. See the attached file, Section 5, third paragraph, 
> last sentence.
> 
> > - section 5.1 - ARC impact on alarm notifications - needs 
> to be further
> > worked on the list.
> 
> The text has been modified to describe the general impact on alarm
> notifications according to M.3100 Amendment 3, and not to describe its
> impact on specific notifications, such as those in the Alarm MIB and
> Condition MIB. See attached file, Section 5.1. 
> 
> > - relationship with Alarm MIB - Sharon to propose text on 
> the mailing
> > list
> 
> To be provided. Any input or suggestion on this item.
> 
> Regards,
> Kam
>  <<cond_mib_sec3-4-5.txt>> 
>  
> 
> 
> 
>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 6 Feb 2002 09:40:17 -0500

hi

I had a few discussions with people in Salt Late City
about one possible way to move forward with all this.
There appeared to be some interest in this approach.

I proposed that the Condition/ARC draft only stores
suppressed conditions. It seems to me that this simplifies
the overall architecture and eliminates a lot of the
confusion. You could even start calling suppressed
conditions suppressed alarms without causing too much
confusion.

The condition/ARC draft would then consist of
	- Alarm Suppression via ARC
	- Suppressed Alarms

This could either be done tightly coupled with
the alarm MIB, using its ResourceId and alarmModelTable,
or more independently if it better supports what's
defined in ITU's ARC.

Would this work for those people interested in conditions
and ARC? What about those not interested in conditions
and ARC, but interested in reducing the confusion level
around this and the Alarm MIB?

Sharon

-----Original Message-----
From: Lam, Hing-Kam (Kam) [mailto:[email-masked]]
Sent: Tuesday, February 05, 2002 4:25 PM
To: [email-masked]'
Cc: Chisholm, Sharon [CAR:NM50:EXCH]; 'Dan Romascanu'; 'David Perkins';
Huynh, An-Ni (An-Ni)
Subject: RE: Progressing the Condition/ARC MIB

Dear All,

Regards,
Kam

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 6 Feb 2002 15:42:09 -0500

I support Sharon's proposal.
This will work for the Optical Interface MIB in AToMMIB WG.
Originanlly, the ARC mib was started with the Optical Interface MIB in the
AToMMIB WG.
It was transferred to the Disman WG because of the generic nature of the ARC
function (as defined in ITU-T).

So, the draft would consist of one single module. It supports the Alarm
Suppression function via the existing objects defined in the ARC module
(i.e., the current section 7) plus Suppressed Alarms information via an
alarmSuppressedTable. The alarmSuppressedTable would contain information
similar to those in the existing condActiveTable.

I prefer "suppressed alarms" then "suppressed conditions" as this will be
consistent with the terms used in ITU-T.

Randy: Couple questions. Need your guidance.
(1) If no objection to this approach, can we simply call the document "ARC
MIB" (or Alarm Reporting Control MIB), instead of "CONDITION & ARC MIB"?
(2) How about the file name of the I-D?
draft-ietf-disman-conditionmib-02.txt or draft-ietf-disman-arcmib-02.txt or
draft-ietf-disman-arcmib-00.txt ?

Regards,
Kam

> From: Sharon Chisholm [mailto:[email-masked]]
> Sent: Wednesday, February 06, 2002 9:40 AM
> To: [email-masked]'; Lam, Hing-Kam (Kam)
> Cc: 'Dan Romascanu'; 'David Perkins'; Huynh, An-Ni (An-Ni)

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 6 Feb 2002 18:08:19 -0800 (PST)

Hi -

> Message-ID: <[email-masked]>
> From: "Lam, Hing-Kam (Kam)" <[email-masked]>
> To: "'Sharon Chisholm'" <[email-masked]>,
>         "[email-masked]'" <[email-masked]>,
>         "Lam, Hing-Kam (Kam)" <[email-masked]>,
>         "'AToM Working Group'" <[email-masked]>
> Cc: "'Dan Romascanu'" <[email-masked]>,
>         "'David Perkins'" <[email-masked]>,
>         "Huynh, An-Ni (An-Ni)" <[email-masked]>
> Date: Wed, 6 Feb 2002 15:42:09 -0500
...
> MIB" (or Alarm Reporting Control MIB), instead of "CONDITION & ARC MIB"?

If there are no objections, the title change is fine with me.
However, I'd be surprised if there were no objections because
much of the functionality is in the condition MIB part of
the document.  (For example, all that good stuff from X.733
and M.3100)

> draft-ietf-disman-arcmib-00.txt ?
...

draft-ietf-disman-conditionmib-02.txt is the only name that will
work.  I won't be around around to approve a -00- draft before
the deadline, and a new series of names must start with sequence
number 00.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 7 Feb 2002 09:21:18 -0500

Hi,

The M.3100 & X.733 Probable Causes are already defined as
IANAItuProbableCause in the Alarm MIB and imported by the condition/arc mib.

As said in the previous email, the ARC mib part will also include the
Suppressed Alarms information via an alarmSuppressedTable. The
alarmSuppressedTable would contain information similar to those in the
existing condActiveTable. Therefore it will need the Textual Conventions
similar to the existing ones in the Condition mib part. (However, instead of
calling them ConditionIndex, ConditionLocation, ... etc., they will be
AlarmIndex, AlarmLocation, etc.)

Therefore the remaining portions of the Condition mib part are mainly the
condActiveTable, condRetiredTable, condTransientTable, condActiveEvent
notification, and condRetiredEvent notification. This is exactly the open
issue we try to solve - i.e., "the relationship of the condition mib with
the alarm mib".

I thought Sharon's proposal is to drop the Condition mib part and let the
ARC mib part move forward. I have no problem with this proposal. (That is
why I asked about the document title and file name.)

If we want to keep the Condition mib part, then we still need to resolve the
"relationship" issue.

Since the Optical Interface MIB is on AToMMIB WG Last Call review now, I
hope the ARC mib part can move forward quick too. If the "relationship"
issue cannot be resolved soon, may be an alternative is to split the
condition/arc mib I-D into two documents, one for ARC and one for Condition.
In the way, the Condition mib can progress in its own path.

Any comments or suggestion?

Regards,
Kam

> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Wednesday, February 06, 2002 9:08 PM
> To: [email-masked]; [email-masked]
> > Message-ID:
> <[email-masked]
> cent.com>
>  Tel: +1 408 546-1006   San Jose, California 95131  USA