Subject: [Disman] Alarm MIB Edits from Harrie's Review

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 2 Apr 2003 15:21:27 -0500

hi

In San Francisco we agreed that, even though we are long
past working group last call, that it would be good to go
through Harrie's detailed review of the Alarm MIB and
classify his feedback into three categories: Gating;
not gating, but requires discussion; and editorial. The
intention being that anything truly gating should be
addressed before forwarding to the IESG and that anything
purely editorial could be done without slowing the progress
of the document.

I'll respond to Harry's email in more detail later, but
we went through it and did not find anything gating. We
did find some editorial changes that we think we can
squeeze into tomorrow's update. I figured I'd give these
a pre-airing on the list as well so we can then send the
update straight into the IESG.

Here goes:

H1
> > 3.3.5 Identifying Resource under Alarm
> >
> >    This MIB provides a generic method for identifying the resource by
>
> Which MIB?? There are 2 in this document. The use of 'This MIB' happens
> also later in the document. It may be mis-leading and, therefore,
> can better be specified which MIB is ment.
Proposal: Clarify which MIB

H2 

> >    sysUptime and snmpTrapOID shall always be stored in the active alarm
>
> 'shall always' -> 'SHALL'
Proposal: Make this change

H3
> > 4.1.4 Active Alarm Resource Identifier
<clip>
> >    matched alarmModelVarbindSubtree. If no match is found, then
> >    alarmModelResourceId is simply the value of
> > alarmModelResourcePrefix.
>
> 'alarmModelResourceId' -> 'alarmActiveResourceId'.
Proposal: Make this change

H4

> >    In addition to this, the variable bindings from the Notifications
> >    that signal the alarm state transitions are stored in the active
> >    alarm table.
>
> 'active alarm table' -> 'active alarm variable table'
Proposal: make this change

H5

> >    B) Consider an alarm modelled using the bgpBackwardTransition
>
> 'B)' -> 'C)'
Proposal: Make this change

H6

> A reference to the WG web-page?? As recommended in the
> mib-reviewers id draft-ietf-ops-mib-review-guidelines-01.txt
> (also valid for the other MODULE-IDENTITY-s)
Proposal: Make this change

H7

> >    alarmActiveVariables OBJECT-TYPE
> >       DESCRIPTION
> >           "The number of variables in alarmActiveVariableTable for this
> >           alarm. Also, the number of varbinds for the notification
> >           associated with this alarm state."
>
> I believe that the part 'Also,...' makes it more unclear on the value,
> since there is a difference in varbinds between V2 or V1
> trap/notification
> PDU. I suggest dropping that. The table refered to,
> 'alarmActiveVariableTable',
> provides enough information.
Proposal: Drop second sentence

H8

> >    alarmClearIndex OBJECT-TYPE
> >       SYNTAX     Unsigned32 (1..4294967295)
> >       MAX-ACCESS not-accessible
> >       STATUS     current
> >       DESCRIPTION
> >           "A strictly monotonically increasing integer which acts
> >           as the index of entries within the named alarm list.
> >           It wraps back to 1 after it reaches its maximum value.
> >
> >           This object has the same value as the alarmActiveIndex that
> >           this alarm instance had when it was active."
> >       ::= { alarmClearEntry 1 }
>
> The value will always have the same value as the alarmActiveIndex, but I
> believe that alarms will not always be cleared in the same order as they
> are active. Thus the requirement of a 'strictly monotonically increasing
> integer' is not usefull here (maybe even not possible).
Proposal: Drop the bit about being monotonically increasing

H9

> >    alarmClearState NOTIFICATION-TYPE
> >       DESCRIPTION
> >         "An instance of the alarm indicated by
> >         alarmActiveModelPointer has been cleared against
> >         the entity indicated by alarmACtiveResourceId."
>                                          ^
> 'alarmACtiveResourceId' -> 'alarmActiveResourceId'
Proposal: Make this change

H10

> >    ituAlarmActiveServiceUser OBJECT-TYPE
> >       DESCRIPTION
> >       "Represents the SericeUser object from [X.736]."
>                              ^
> 'SericeUser' -> 'ServiceUser'
Proposal: Make this change

H11

> > 6.5 RMON Alarm Example
> >
> >   alarmModelIndex                  6
> >   alarmModelState                  2
> >   alarmModelNotificationId         RisingAlarm
> >   alarmModelVarbindIndex           0
> >   alarmModelVarbindValue           0
> >   alarmModelDescription            "RMON Rising Alarm"
> >   alarmModelSpecificPointer        0.0
> >   alarmModelRowStatus              active (1)
> >   alarmModelVarbindSubtree         alarmIndex
> >   alarmModelResourcePrefix         0.0
> >   alarmModelRowStatus              active (1)
>
> Has twice 'alarmModelRowStatus' (first need to be deleted).
Proposal: Make this change

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada