Subject: RE: Alarm MIB questions

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 7 Mar 2002 14:46:50 +0200

This is a procedure answer to David's mail. I addressed the technical
issue in a previous mail.

Regards,

Dan

> -----Original Message-----
> From: David Partain [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 2:15 PM
> To: DISMAN Mailing List
> Subject: Re: Alarm MIB questions
> 
> 
> Hi all,
> 
> I'm following up Sharon's response regarding my two questions.
> Thanks for the mail, Sharon.
> 
> dlp> Question 1:
> dlp>
> dlp> The concern I have is the simplistic mapping we have in the
> dlp> Alarm MIB, where we have only a notification OID and one
> dlp> VarBind to distinguish alarms and alarm states.
> dlp>
> dlp> What do we do if the different alarm states cannot be
> dlp> distinguished by the current setup of the pair notificationID/
> dlp> one integer-based VarBind?  That is, if I have multiple alarm
> dlp> states that can exist on my system, where the individual
> dlp> alarm states -- each one of which should be a row in the
> dlp> AlarmModelTable -- can only be distinguished from one another
> dlp> using a combination of several of the varbinds carried in the
> dlp> trap/inform, how can I represent this with the Alarm MIB?
> 
> sc> The first issue is actually closed Alarm#8
> sc>
> sc> Alarm#8 Matching Notifications (closed)
> sc>   The question was raised in London as to whether using 
> notification OID
> sc>   plus one offset and value pair was sufficient for 
> modelling alarm
> sc>   states. Sharon sent an email on Sept 10th summarizing 
> her analysis
> sc>   concluding that it provided pretty good modelling.
> 
> Okay, so it's closed, but I'm going to ask about that decision
> nonetheless :-).  Feel free to ignore me if that seems the
> right thing to do.
> 
> Sharon's mail (assuming it's the one you meant) had the following:
> 
> sc> I've just completed an examination of 122 or so
> sc> notifications in standard MIBs.
> sc>
> sc> This is what I found:
> sc> 
> sc> 1. The method in the draft - offset + integer value -
> sc>    provides pretty good modelling.
> sc> 
> sc> 2. There were a few cases where richer modelling would
> sc>    have added more value. This could have been accomplished
> sc>    by a second offset and integer pair.
> sc> 
> sc> What you propose is interesting, but I think it might
> sc> be more than we need:
> sc> 
> sc> 1) It makes the solution more expensive. The agent now needs
> sc>    to support the expression MIB in order to do alarm management.
> sc> 
> sc> 2) Allowing for the inclusion of non-varbound variables is
> sc>    certainly neat, but I wonder if it goes beyond "basic fault"
> sc>    and starts entering into the area of alarm correlation and
> sc>    other aspects which are traditionally done in the upper
> sc>    layers of the manager. Do we actually want to do this?
> 
> I realize that standard MIBs are what we really can look at
> easily, but in my world (and I suspect most of the readers
> of this list), a significant portion of the work we do is
> with enterprise-specific MIBs.  I'm very worried that the
> limited mapping capability (only one VarBind and only integer
> varbinds) is going to make use of the Alarm MIB either limited.
> 
> A "relatively straightforward" way to get a little
> farther down the road would be to do something like the
> alarmActiveVariableTable for the model table and that would
> _at least_ allow us to have varbinds that aren't integers.
> This would admittedly make things a bit more complicated, but
> I suspect that the bang for the buck is worth it.
> 
> One _could_ take it a step further and have "next" pointers
> in the new variable table that would allow you to have a linked
> list of varbinds to look at.
> 
> I agree that we don't want to make the expr MIB a requirement
> for implementing the Alarm MIB.  Perhaps doing something like
> I've outlined would be something between?  Is there anyone
> else who thinks this would be useful?
> 
> Cheers,

David,

I think that this comment comes very late in the process. The issue was
open before London, and a proposal for closure was given in September
2001. Coming with a comment six months later, after two rounds of
drafts, and the WG Last Call period having expired does not seem right.

I am far from being a strict process addict. If serious flaws are found
in the standard it is never too late to comment and argue. However this
does not seem the case. Even if you prove to be right (I think that this
is not the case) this is at most an optimization. 

The IETF standards process has become a bad example in the industry for
being heavy and slow and not meeting schedules. Let us not make the
situation worth by making the process even longer if there are not very
good reasons for this.

Regards,

Dan

---

From: David Partain <[email-masked]>
Date: Thu, 07 Mar 2002 14:14:36 +0100

Hi,

> I think that this comment comes very late in the process.

Dan, I completely understand and I'm _really_ not trying to be a
problem.  I'm truly trying to be constructive.

> The issue was

I cannot always control what I work on.  The folks who pay
my salary told me a couple of months ago to look at this.
The fact that they didn't tell me to do so several months ago is
(unfortunately) out of my control to a large degree.

> is not the case) this is at most an optimization.

You and I might disagree about whether this is optimization or
fundamental, but the working group seems to have decided that
it's an optimization, so I'll be quiet.

I'm not interested in being obstructionist or slowing the process
down.

Cheers,

dlp