Subject: RE: draft-chisholm-disman-active-alarm-01.txt

From: "Ayers, Mike" <[email-masked]>
Date: Tue, 5 Dec 2000 21:40:33 -0600

> From: Sharon Chisholm [mailto:[email-masked]]
>
> Comments in-line.
>
> >-----Original Message-----
> >From: Ayers, Mike [mailto:[email-masked]]
> >
> >> From: Sharon Chisholm [mailto:[email-masked]]
> >>
> >> These seem to apply to only a small subset of alarms.  Wouldn't it
> >> then be better to go with the option you also suggested of just
> >> having them as varbinds in the trap, and therefore present in the
> >> alarmActiveVariablesTable?
> >
> >	Actually, I think they apply to about half the alarms,
> since my copy
> >of X.736 states that they are mandatory for all security
> alarms.  Does
> yours
> >read the same (mine is not a final copy, unfortunately)?
>
> That is how mine reads, but I would think that security
> alarms would not be
> that big of a percentage of the alarms a system has.  Do you
> really see it
> being as much as half?  I was thinking closer to 5%.

	It all depends on how you do the counting.  You can count the two
major alarm groups, application and security, and get 50%.  You can count
the number of alarm types and get ~50%.  You can count the number of
individual alarms actually posted on deployed systems and get a number
(hopefully) vastly smaller than 5%.  Finally (I think this is the important
one), you can count the number of deployed ITU alarm systems which use the
security objects (my terminology may be slipping, I don't have the ITU specs
handy) and get a percentage I cannot even guess at.

> >	I don't object to these objects being in the
> >alarmActiveVariablesTable, but I do think that there should
> be objects
> >defined specifically for them somewhere in the Active Alarm
> MIB so that
> they
> >can be identified as such.
> Maybe, I think this depends on the percentage of traps that
> would actually
> use these parameters.

	I don't see why.  Perhaps you misunderstand my suggestion.  I am
looking for something like:

<Proposal>

alarmStandardObjects OBJECT IDENTIFIER ::= { alarm 3 }

  alarmStandardObjectsSecurityAlarmDetector OBJECT-TYPE
       SYNTAX OCTET STRING
       MAX-ACCESS not-accessible
       STATUS  current
       DESCRIPTION
          "The detector of the current security alarm."

  alarmStandardObjectsServiceUser OBJECT-TYPE
       SYNTAX OCTET STRING
       MAX-ACCESS not-accessible
       STATUS  current
       DESCRIPTION
          "The user of the currently alarmed service."

  alarmStandardObjectsServiceProvider OBJECT-TYPE
       SYNTAX OCTET STRING
       MAX-ACCESS not-accessible
       STATUS  current
       DESCRIPTION
          "The provider of the service currently experiencing security
alarm."

</Proposal>

	This would allow objects to be mapped into the Alarm MIB from ITU
tables and vice versa.  Without them, there can be no transformation with
the ITU tables.  Note that they are not accessible, since it is only their
OIDs that we would make use of.

> >> PS.  I send explicitly as plain text, it just arrive as
> html. Network
> >>      Gremlins.
> >>
> >
> >	Some network admin is doing us a "favor", isn't that sweet?
> >
> I'm trying something new.  Let me know if it's better or worse.

	Very nice, thank you!  Nothin' but text!

/|/|ike