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

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 30 Oct 2000 08:27:40 -0600

hi

I start holidays tomorrow, so I will be reading any other
comments and suggestions when I get back November 26th.  
Please do reply though.

I can certainly incorporate the corrections, but I have a
question about the security information.  From my copy of
X.736:

Security alarm detector - This parameter identifies the detector
of the security alarm.

Service user - This parameter identifies the service-user whose
request for service led to the generation of the security alarm.

Service provider - This parameter identifies the intended service-provider
of the service that led to the generation of the security alarm.

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?

Also, are there any security implications of making this available in
a MIB?  I know a lot of systems have a way of turning off the SNMP
authentication failure trap for this reason.

thanks,

Sharon

PS.  I send explicitly as plain text, it just arrive as html. Network
     Gremlins.

-----Original Message-----
From: Ayers, Mike [mailto:[email-masked]]
Sent: Thursday, October 26, 2000 8:32 PM
To: Chisholm, Sharon [CAR:5K32:EXCH]
Cc: [email-masked]
Subject: RE: draft-chisholm-disman-active-alarm-01.txt

	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