Subject: Comments on draft-ietf-disman-conditionmib-04.txt

From: "Faye Ly" <[email-masked]>
Date: Wed, 18 Sep 2002 19:17:53 -0700

Kam,

Great work on draft-ietf-disman-conditionmib-04.txt
and please see my comments:

1. The definition of 'alarm' probably deserve some
thinking and explaining.  Is this specifically
ITU-T standing/transient alarms you are talking
about or is this alarm defined in the alarm mib
you are controlling?

2. Relationship between ARC MIB and Alarm MIB?

3. In section 4.1:

"For alarm condition raised after entering ARC mode and not cleared
   when exiting ARC mode, the reporting of alarm raised will be
   deferred until the moment of exiting ARC mode. "

Does this mean network element MUST send the active alarm
exiting ARC mode if the alarm is not cleared??  Or not?

4. Objects xxTimeInterval describe transition from one state
to another.  I know these are well defined in M.3100 Amd3.
Can people use this MIB and not conforming to M.3100 Amd3,
is the question!  If it is true, this is not an issue but if
you intend to let people who do not wish to conform to M.3100
Amd3 to use this MIB as well, a simple picture description
of each state mentioned in the MIB DESCRIPTION clause is
highly recommended.

5. REFERENCE clause is highly recommended for sections in
M.3100 Amd3.

6. The description for arcEntry:

"A conceptual row that contains information about the ARC setting
     of a resource in the system"

A resource is a bit confusing for me.  If this table is indexed
by arc resource ID, alarm type and notification ID.  It seems
like it can be used on either a resource or a certain type of
alarm?  Having OID as the syntax of the arcIndex is also
confusing?  How do I inhibit all alarms triggered from chassis
1 board 2?  (Which is under testing now!)  Or is this MIB not
intended to be used for this purpose?

Best,

-faye

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 19 Sep 2002 08:35:20 -0700 (PDT)

Hi -

(I've cc'ed Faye and Nathan because neither is on the disman
subscriber list, as far as I can tell)

> From: "Faye Ly" <[email-masked]>
> To: [email-masked], [email-masked]
> Cc: [email-masked]
> Subject: Comments on draft-ietf-disman-conditionmib-04.txt
> Date: Wed, 18 Sep 2002 19:17:53 -0700
> Message-ID: <[email-masked]>
...
> intended to be used for this purpose?
...

Let me turn the question around a bit:  When a management
application receives an arbitrary notification, how does
it know whether that notification pertains to something on
chassis 1 board 2?

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  SJC-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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 19 Sep 2002 19:04:21 +0300

> it know whether that notification pertains to something on

If this information is interesting, the arbitrary notification could include the relevant objects from the Entity MIB in the varbind...which would make the notification not that arbitrary...oh, Joseph Heller, I miss you!

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 19 Sep 2002 11:01:10 -0700 (PDT)

Hi -

> Subject: RE: Comments on draft-ietf-disman-conditionmib-04.txt
> Date: Thu, 19 Sep 2002 19:04:21 +0300
> Message-ID: <[email-masked]>
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>, <[email-masked]>
> Cc: <[email-masked]>, <[email-masked]>
> 
> If this information is interesting, the arbitrary notification 
> could include the relevant objects from the Entity MIB in the
> varbind...which would make the notification not that arbitrary...
> oh, Joseph Heller, I miss you!

If we're lucky enough to be talking to an agent that has taken
the initiative to include that varbind.  How many notification-
type definitions actually require the inclusion of that information?

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 19 Sep 2002 13:56:30 -0700 (PDT)

hi -

...
...

Whether anything appears on the wire is subject to the configuration
of the MIBs in RFC 2573.  The flow diagram in the alarm MIB
document should make this relationship clear.  If it doesn't,
we should fix it.

---

From: "Faye Ly" <[email-masked]>
Date: Thu, 19 Sep 2002 14:02:36 -0700

I must have missed something, for all the NMS/
NE I have defined/built, there is always an index
varBind for the notification to indicate the
location (chassis 1 board 2 or port number or
something else ...)

How else can the NMS provide an alarm hiearchy?

-faye

>From: Randy Presuhn <[email-masked]>
>To: [email-masked]
>CC: [email-masked], [email-masked]
>Date: Thu, 19 Sep 2002 11:01:10 -0700 (PDT)
>
>Hi -
>
> > Message-ID: 
><[email-masked]>

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: "Faye Ly" <[email-masked]>
Date: Thu, 19 Sep 2002 14:07:51 -0700

Randy,

Do you mean standard MIB?  LinkUp/Down traps
have ifIndex that points to (eventually via
Entity MIB or some proprietary implementation)
Chassis 1, board/slot 15 and port 2.

We don't support Entity MIB for efficiency
reason but the corresponding board up/down
notification will definitely have the
chasis number and board/slot number as one
of the varBind.  How else will the NMS know
which board is up or down?  Ok I know I missed
something or we are not talking about the
same thing??  Can you please explain?

Thanks.

-faye

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: "Faye Ly" <[email-masked]>
Date: Thu, 19 Sep 2002 14:16:18 -0700

Thanks Randy,

When NMS receives an arbitrary notification,
it first determines if it is worth receiving?
If it is and the notification type says
something happened on a chassis on slot 3,
the notification has better include the
varBind that provides the chassis 1 slot 3
information.  Or else NMS can simply toss
the notification because it has no use.

-faye

>Subject: Re:  Comments on draft-ietf-disman-conditionmib-04.txt
>Date: Thu, 19 Sep 2002 08:35:20 -0700 (PDT)
>
>Hi -
>

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 19 Sep 2002 14:43:47 -0700 (PDT)

Hi -

> To: [email-masked], [email-masked]
> Cc: [email-masked]
> Date: Thu, 19 Sep 2002 14:02:36 -0700
> Message-ID: <[email-masked]>
> 
...

That's precisely the point of using the resource id
as an index for alarm report control.  If the management
system needs to know the mapping of varbinds to physical
entities, then it has the information it needs to find
the correct alarm report control entries.

---

From: "Faye Ly" <[email-masked]>
Date: Thu, 19 Sep 2002 15:34:47 -0700

Ah! Got it!  Why is arcIndex defined as OID
then?  Are we suppose to use for example:

entPhysicalTable.entPhysicalIndex.1

as the arcIndex?

-faye

>To: [email-masked], [email-masked]
>CC: [email-masked]
>Date: Thu, 19 Sep 2002 14:43:47 -0700 (PDT)
>
>Hi -
>

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 19 Sep 2002 16:37:21 -0700 (PDT)

Hi -

> Date: Thu, 19 Sep 2002 15:34:47 -0700
> Message-ID: <[email-masked]>
> 

What other type could it be?  Many of the things associated with
alarms won't necessarily be represented in the entity MIB.

...

No, I'd (for this example) expect the arcIndex to be equal to
the value of entAliasMappingIdentifier from some corresponding
row in entAliasMappingTable.

This means that the management application that wants to
supress everything related to "card 1" would have to rummage
around in the entity mib to find out what resources might
be affected.  However, even if the entity MIB is implemented,
there's no guarantee it represents all the things that might
result in the generation of notifications.

It may end up being simpler (though not necessarily scaling
at all well) to just walk through the ARC tables and, for
each entry, apply the algorithms that would be used to figure
out what to do with an incoming notification to figure out
whether something should be supressed or not.