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

From: Randy Presuhn <[email-masked]>
Date: Fri, 27 Oct 2000 09:30:12 -0700 (PDT)

Hi -

Yet another forwarded posting.

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

> Received: from creeper.bmc.com (creeper.bmc.com [172.17.1.166])
> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA17785
> 	for <[email-masked]>; Thu, 26 Oct 2000 17:28:57 -0700 (PDT)
> Received: from ec03-hou.bmc.com (localhost [127.0.0.1])
> 	by creeper.bmc.com (8.10.2/8.8.6) with ESMTP id e9R0TZU13806;
> 	Thu, 26 Oct 2000 19:29:35 -0500 (CDT)
> Received: by ec03-hou.bmc.com with Internet Mail Service (5.5.2650.21)
> 	id <VJ74HRRL>; Thu, 26 Oct 2000 19:30:19 -0500
> Message-ID: <[email-masked]>
> From: "Ayers, Mike" <[email-masked]>
> To: "'Sharon Chisholm'" <[email-masked]>
> Cc: [email-masked]
> Subject: RE: draft-chisholm-disman-active-alarm-01.txt
> Date: Thu, 26 Oct 2000 19:31:41 -0500
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2650.21)
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> 
> 	Here's my commentary.
> 
> {AlarmDetailsEntry}
> 
> 	X.736/10164-7 (my copy dated 16Jul91, "almost final") mandates
> security alarm detector, service user, and service provider objects.  If
> these were added, not only would this MIB be mostly X.733/10164-4 and
> X.736/10164-7 compliant (other than that CMIP thing...), but I suspect such
> objects would appeal to the security folks as well.  Could these be added?
> 
> 	I can think of one way to do it.  The objects could be filled by
> declaring objects for them in the MIB which, when found in a trap, would be
> routed to the alarmDetailsEntry instead of the alarmActiveVariableEntry.  So
> long as these objects are defined in this MIB, there should be minimal risk
> of confusion.
> 
> 	On the other hand, one could argue that the ability to put
> independent objects with such a meaning into a trap (which would wind up in
> the alarmActiveVariableEntry) in itself fulfills the requirements.  However,
> this method would preclude transformation of X.736/10164-7 tables into the
> active alarm MIB (for, say, remote monitoring).
> 
> 	Therefore, if there is real possibility of the Active Alarm MIB
> being used to reflect or source an X.736/10164-7 table, the creation of such
> objects is important, otherwise it is just desireable (or possibly
> pointless).
> 
> {alarmDetailsEventType}
> 
> 	"communityAlarmType" s/b "communicationsAlarmType"
> 	"qualityOfServerAlarmType" s/b "qualityOfServiceAlarmType"
> 
> 	Need to add integrityViolationType, operationalViolationType,
> physicalViolationType, securityServiceOrMechanismViolationType, and
> timeDomainViolationType.
> 
> {alarmDetailsAdditionalText}
> 
> 	This is type DisplayString, which is limited to 255 bytes of 7 bit
> ASCII.  A UTF8String type would be much much better.  Please consider
> snipping that TC from draft-ietf-snmpconf-pm-03.txt.
> 
> {alarmActiveTime}
> 
> 	"tends to be is a valid" - delete "is".
> 
> {alarmActiveEngineAddress}
> 
> 	Wouldn't a TDomain/TAddress pair be more friendly to less mainstream
> implementations?
> 
> {alarmActiveVariableValueType}
> 
> 	If octetString=5 and ipAddress=6, then the index of the desired
> value will be a constant offset plus alarmActiveVariableValueType -
> otherwise, a lookup table will be needed.  I am sending a matching note to
> the Notification Log MIB author.
> 
> {alarmActiveListGroup}
> 
> 	[niggly] alarmActiveGroup would seem to fit the pattern better.
> 
> {alarmActiveSummaryGroup}
> 
> 	[niggly] alarmActiveStatsGroup would seem to fit the pattern better.
> 
> {ALARM-MIB DEFINITIONS}
> 
> 	[niggly] "END" should be at the left of the following line. (Yes, I
> know it affects nothing, that's why it says "niggly"  ;-)
> 
> 
> 	HTH,
> 
> /|/|ike
>