Subject: [Disman] comments for draft-ietf-disman-alarm-mib-09.txt

From: Harrie Hazewinkel <[email-masked]>
Date: Tue, 18 Mar 2003 17:34:57 +0100

Hi,

I noticed there would be a new revision of the ALARM-MIB,
maybe some of these comments could be addressed also.
See below.

> 3. Alarm Management Framework
>
> 3.1 Terminology
>
>   Error
>      A deviation of a system from normal operation.
>
>   Fault
>      Lasting error or warning condition.

Since 'error' is defined as a term, I believe it may be wise to
define the 'warning' as well.

Since I cannot find a real definition of 'alarm model' and
'alarm list', but only usages I would suggest these terms
to be defined here as well.

> 3.2 Alarm Management Architecture

FORMAT NIT: Put this section header on the same page as the beginning
of the section.

What I miss is a small description of the components and there 
interactions
of the figure.

> 3.3.1 Modular Alarm Architecture
>
>    The subject of alarm management can potentially cover a large number
>    of topics including real-time alarms, historical alarms, alarm
>    correlation, and alarm suppression, to name a few. Within each of
>    these topics, there are a number of established models that could be
>    supported. This memo focuses on a subset of this problem space, but
>    describes a modular SNMP alarm management framework.

What is this subset??

> 3.3.3 Problem Indication
>
>    The Alarm MIB provides a means to tell what Notifications are just
>    informational events or not of interest to the manager for other
>    reasons by not including them in any alarm models.

How does this work for multiple managers?? For some it may be an alarm 
needing
a notification and others not. Is that where you need the 
SNMP-NOTIFICATION-MIB
and SNMP-TARGET-MIB??

> 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.

> 3.3.6 Means of obtaining ITU alarm information
>
>    Alarm Information, as defined in ITU alarm models [M.3100], is
>    optionally available to implementations through the optional support
>    of the ITU-ALARM-MIB.

Just for reference, where can I find this document?? As if this is a 
feature
of the architecture of the previous picture I do not see anything
related to ITU.

> 3.3.10 Historical Alarm Management
>
>    Some systems may have a requirement that information on alarms that
>    are no longer active is available. This memo provides a clear table

'a clear table' -> 'a table'. What is ment with 'a clear table' anyway??

>    to support this requirement.
>
>    This can also be achieved through the support of the Notification
>    log MIB [RFC3014] to store alarm state transitions.

Why would one to create in this document an alternative for
'Historical Alarm Management'??

>
> 3.4 Security
>
>
>    For the purpose of this discussion, "security credentials" means the

'For the purpose of this discussion' -> 'This document'

>    The Alarm MIB has the notion of a named alarm list.  By using alarm
>    list names and view-based access control [RFC2575] a network
>    administrator can provide different access for different users. When
>    an application creates an alarm model (indexed in part by the alarm
>    list name) the security credentials of the creator remain associated

'creator' of what?? The application or managed objects??
Explanation, if I implement an application I could be seen as the 
creator,
but the use here is defnitely different.

>     The managed system SHOULD NOT apply access control when processing
>    remotely-generated Notifications using the alarm models.  In those
>    cases the security of the information in the alarm tables SHOULD be
>    left to the normal, overall access control for those tables.

What is 'normal'?? Please, specify.

> 3.6 Notification Varbind Storage and Reference
>
>    In SNMPv1, the varbinds in the Trap-PDU sent over the wire map one
>    to one into those varbinds listed in the SMI of the trap in the MIB
>    in which it was defined. In the case of linkDown trap, the first
>    varbind can unambiguously be identified as ifIndex. With the
>    introduction of the InformRequest-PDU and SNMPv2-Trap-PDU types,
>    which send sysUptime and snmpTrapOID as the first two varbinds,
>    while the SMI in the MIB where the Notification is defined only
>    lists additional varbinds, the meaning of "first varbind" becomes
>    less clear. In the case of the linkDown Notification, referring to
>    the first varbind could potentially be interpreted as either the
>    sysUptime or ifIndex.

I understand the above described problem,  but I am not sure what
it adds.  The usage of 'first' in this section is left a bit in the 
open.
I would suggest to drop this paragraph, the next paragraph defines this
and better I would say.

>    The varbind storage approach taken in the Alarm MIB is that

'approach taken -> 'defined'

>    sysUptime and snmpTrapOID shall always be stored in the active alarm

'shall always' -> 'SHALL'

>    variable table as entry 1 and 2 respectively, regardless of whether
>    the transport was the Trap-PDU, the InformRequest-PDU or the
>    SNMPv2-Trap-PDU. If the incoming Notification is an SNMPv1 Trap-PDU
>    then an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be
>    determined by using the rules in section 3.1 of [RFC2576].
>
>    The varbind reference approach taken in the Alarm MIB is that, for
>    variables such as the alarmModelVarbindIndex, the first two
>    obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU are
>    ignored, and the index aligns with the Trap-PDU and the SMI. In the
>    case of linkDown, the first varbind would always be ifIndex.

I would for simplicitly reasons make both approaches equal.
I understnad this is a real semantic change, but if the WG
prefers this it is fine by me.

> 3.7 Relation to Notification Log MIB
>
>    The Alarm MIB is intended to complement the Notification Log
>    MIB[RFC3014], but can be used independently.  The alarmActiveTable
>    is defined in manner similar to that of the nlmLogTable.  This
>    format allows for the storage of any Trap or Notification that can
>    be defined using SMIv1 or SMIv2.  Using the same format as the
>    Notification log MIB also simplifies operations for systems choosing
>    to implement both MIBs.

If they use the same format, it could be a possibility to use
the nlmLogTable. I understand it is not possible, but an explaination
why will help an implementor, I guess.

>    The object alarmActiveLogPointer points, for each entry in the
>    alarmActiveLogTable, to the log index in the Notification log MIB,
>    if used.

I believe this can create confusion, since a RowPointer must
point to an accessible object in a table. In many cases the 'index'
of a table is 'not-accessible'.

> 3.8 Relationship with the Event MIB
>
>    During the work and discussions in the Working Group, the issue of
>    the relationship between the MIB modules and the Event MIB [RFC2981]
>    was raised.

I would say, only the outcome of the discussion is usefull. I suggest, 
to
drop the above sentence.

> 4.1 Overview
>
>    The alarmModelTable contains information that is applicable to all
>    instances of an alarm.  It can be populated at start-up with all
>    alarms that could happen on a system or later configured by a
>    management application.

I believe the above section part is confusing in the sense that
it uses the name alarmModelTable if it only provides a list of alarms.
Would therefore a table named alarmListTable not be better
representing its semantics??

> 4.1.1 Extensibility
>
>    The relationship between the Alarm MIB and the other alarm model MIB
>    modules is expressed by the following: The alarmModelTable has a
>    corresponding table in the specific MIB. For each row in the
>    specific MIB alarm model table there is one row in the
>    alarmModelTable. The alarmActiveTable has a corresponding table in
>    the specific MIBs. For each row in the specific MIB active alarm
>    table, there is one row in the alarmActiveTable. The
>    alarmModelSpecificPointer object in the alarmModelTable points to
>    the specific model entry in an extended alarm model table
>    corresponding to this particular alarm.  The
>    alarmActiveSpecificPointer object in the alarmActiveTable points to
>    the specific active alarm entry in an extended active alarm table
>    corresponding to this particular alarm instance.

Not sure if this section would be enough to make additional alarm 
modules.
Would it not be better add more guidelines on how to make a new model??
I also believe the making a specific alarm model involves duplicating
part of the generic alarm-mib. Is that what is needed?

> 4.1.3 Alarm State Transition Notification
>
>    Alarms are modelled by defining all possible states in the
>    alarmModelTable, as well as defining alarmModelNotificationId,
>    alarmModelVarbindIndex, and alarmModelVarbindValue for each of the
>    possible alarm states.  Optionally, ituAlarmPerceivedSeverity models
>    the states in terms of ITU perceived severity.

Here I start getting confused of what the alarmModelTable is about.
Before it said it contains all alarms available in a system, now
it defines all possible states of an alarm.
OK, I admit I did not read the MIB definition itself yet (at this 
point).

>
> 4.1.4 Active Alarm Resource Identifier
>
>    If alarmModelResourcePrefix has a value of 0.0, then
>    alarmActiveResourceId is simply the variable identifier of the first
>    Notification varbind that matches the prefix defined in
>    alarmModelVarbindSubtree. Otherwise, alarmActiveResourceId is
>    calculated by appending the instance information from the first
>    Notification varbind that matches alarmModelVarbindSubtree to the
>    prefix defined in alarmModelResourcePrefix. The instance information
>    is the portion of the variable identifier following the part that
>    matched alarmModelVarbindSubtree. If no match is found, then
>    alarmModelResourceId is simply the value of 
> alarmModelResourcePrefix.

'alarmModelResourceId' -> 'alarmActiveResourceId'.

>
>    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'
Not sure if that is ment here.

>     To set the resource Id to be the ifIndex, configure as follows:
>           alarmModelVarbindSubtree = ifIndex (1.3.6.1.2.1.2.2.1.1)
>           alarmModelResourcePrefix = 0.0
>
>     Alternatively, since ifIndex is the first varbind, the following
>     would also work, but might be less meaningful to a human reader

Why 'human reader' does it not count for an automatic as well?

>
>    B) Consider an alarm modelled using the bgpBackwardTransition

'B)' -> 'C)'

>
> 4.2 Definitions
>
>    ALARM-MIB DEFINITIONS ::= BEGIN
>
>
>      alarmMIB MODULE-IDENTITY
>          LAST-UPDATED "200208280000Z"
>          ORGANIZATION "IETF Distributed Management Working Group"
>          CONTACT-INFO
>               "WG EMail:  [email-masked]
>               Subscribe: [email-masked]

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)

>    -- Textual Conventions 	
>
>    ResourceId ::= TEXTUAL-CONVENTION
>        STATUS current
>        DESCRIPTION
>                "A unique identifier for this resource.
>
>                The type of the resource can be determined by looking
>                at the OID that describes the resource.
>
>                Resources must be identified in a consistent manner.
>                For example, if this resource is an interface, this
>                object MUST point to an ifIndex."

How are multiple indexes handled?? It looks like that a resource is
that part of a system that has just a single index.
Some clarification would help I believe.

>      alarmModelVarbindSubtree  OBJECT-TYPE
>      alarmModelResourcePrefix  OBJECT-TYPE
>
Since both descriptions speak of 'indexes' are scalars excluded?

>    alarmListName OBJECT-TYPE
>       SYNTAX     SnmpAdminString (SIZE(0..32))
>       MAX-ACCESS not-accessible
>       STATUS     current
>       DESCRIPTION
>        "The name of the list of alarms.  This SHOULD be the same as
>        nlmLogName if the Notification Log MIB [RFC3014] is supported.
>
>        An implementation may allow multiple named alarm lists, up to
>        some implementation-specific limit (which may be none).  A
>        zero-length list name is reserved for creation and deletion
>        by the managed system, and MUST be used as the default log
>        name by systems that do not support named alarm lists."
>       ::= { alarmActiveEntry 1 }

I am not seeing why this object needs to be defined. One could use the
nlmLogName directly in the indexes where alarmListName is used.
The nlmLogName is not-accessible and therefore it is
not needed to implement the NOTIFICATION-LOG-MIB module.
And as it looks the association is needed if the NOTIFICATION-LOG-MIB
exist.

Neither, I do not fully understand why it is defined in this
table and not in the alarmModelTable. A definition of the alarmListName
in that table looks more logic to me, but I am maybe missing something.

If the WG wants to keep this object, I do not object.

>
>    alarmActiveDateAndTime OBJECT-TYPE
>       DESCRIPTION
>           "The local date and time when the error occurred.

I would drop 'local', as long as it is known in which timezone
the alarm went active it is no problem. For instance, you can have
systems in all timezones, but still using UTC as its timezone.
Then 'local' is not really 'local'. (Also in some others)

>    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 beleive 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.

>    alarmActiveNotificationID OBJECT-TYPE

Is this not retrievable from the alarmModelTable by using the
alarmActiveModelPointer??

>    alarmActiveLogPointer OBJECT-TYPE
>       DESCRIPTION
>           "A pointer to the corresponding row in a
>           notification logging MIB where the state change
>           notification for this active alarm is logged.
>           If no log entry applies to this active alarm,
>           then this object MUST have the value of 0.0"

For clarity, I suggest using here a specific reference towards the table
in which the log index resides within the MIB.

>    alarmActiveVariableValueType OBJECT-TYPE
>       SYNTAX      INTEGER {
>             counter32(1),
>             unsigned32(2),
>             timeTicks(3),
>             integer32(4),
>             ipAddress(5),
>             octetString(6),
>             objectId(7),
>             counter64(8),
>             opaque(9)
>             }
>       MAX-ACCESS  read-only
>       STATUS      current
>       DESCRIPTION
>           "The type of the value.  One and only one of the value
>           objects that follow is used, based on this type."

Also 'the value' is better described by 'the value of the object
indicated by alarmActiveVariableID'.
The last part I am not sure what an implementor should do.
Should it provide dummy values for the 'not used' variables or
create 'holes' in the table.

>    alarmActiveVariableCounter32Val OBJECT-TYPE
>       SYNTAX      Counter32
>       MAX-ACCESS  read-only
>       STATUS      current
>       DESCRIPTION
>           "The value when alarmActiveVariableType is 'counter32'."
>       ::= { alarmActiveVariableEntry 4 }

About the 'alarmActiveVariable.....Val' objects it should be noted that
the value has no significance if 'alarmActiveVariableType' is 
indicating to
that type/object.
Also 'The value' is better described by 'The value of the object
indicated by alarmActiveVariableID'

>
>    alarmActiveVariableIpAddressVal OBJECT-TYPE
>       SYNTAX      IpAddress
>       MAX-ACCESS  read-only
>       STATUS      current
>       DESCRIPTION
>           "The value when alarmActiveVariableType is 'ipAddress'."
>       ::= { alarmActiveVariableEntry 9 }

Not sure what to do here. It is not recommended to use IpAddress as a 
type,
but replacing it by InetAddress is neither possible, that would result 
in
a alarmActiveVariableOctetStringVal.
Now the question, how can a management station detect which InetAddress
type is used??

>    -- Statistics --
>
>    alarmActiveStatsActives OBJECT-TYPE
>          SYNTAX Counter32
>          MAX-ACCESS read-only
>          STATUS  current
>          DESCRIPTION
>             "The total number of active alarms since system restarted."

How is the persistence defined when only the SNMP engine reboots??

>    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).

>
>    alarmClearLogIndex OBJECT-TYPE
>       SYNTAX     Unsigned32 (0..4294967295)
>       MAX-ACCESS read-only
>       STATUS     current
>       DESCRIPTION
>           "This number MUST be the same as the log index of the
>           applicable row in the notification log MIB, if it exists.
>           If no log index applies to the trap, then this object
>           MUST have the value of 0."

For clarity, I suggest using here a specific reference towards the table
in which the log index resides.

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

>    alarmCompliance MODULE-COMPLIANCE
>          STATUS  current
>          DESCRIPTION
>              "The compliance statement for systems supporting
>              the Alarm MIB."
>          MODULE -- this module
>              MANDATORY-GROUPS {
>               alarmActiveGroup,
>               alarmModelGroup
>              }
>       ::= { alarmCompliances 1 }

Since there are read-create objects, the mib-review document indicates 
there
should be a FullCompliance and ReadOnlyCompliance statement.

> 5.1 Overview
>
>    This MIB module defines alarm information specific to the alarm
>    model defined in ITU M.3100 [M.3100], X.733[X.733] and X.736[X.736].

A short description of the ITU Alarm Model would not hurt a reader
its understanding. Perticular, those that cannot access the ITU
standards themselves, like me.

>     ianaItuAlarmNumbers MODULE-IDENTITY
>         LAST-UPDATED "200208280000Z"
>         ORGANIZATION "IANA"
>         CONTACT-INFO
>             "Postal:    Internet Assigned Numbers Authority
>                         Internet Corporation for Assigned Names
>
>           and Numbers

nit: little formatting. :-))

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

Maybe the description of the MODULE-IDENTITY should also state that
only values may be added when they are defined by the ITU alarm model.

>
>    ituAlarmActiveStatsIndeterminateCurrent OBJECT-TYPE
>       SYNTAX      Gauge32
>       MAX-ACCESS  read-only
>       STATUS      current
>       DESCRIPTION
>           "A count of the current number of active alarms with a
>            ituAlarmPerceivedSeverity of indeterminate."
>       ::= { ituAlarmActiveStatsEntry 1 }

Is it the idea to add an extra column for every later added
perceived severity?? Otherwise, the perceived severity
could be an index and the table has just 2 columns
current and total.

>    ituAlarmCompliance MODULE-COMPLIANCE
>       STATUS  current
>       DESCRIPTION
>              "The compliance statement for systems supporting
>              the ITU Alarm MIB."
>       MODULE -- this module
>           MANDATORY-GROUPS {
>               ituAlarmGroup
>               }
>      ::= { ituAlarmCompliances 1 }

Since there are read-write objects, the mib-review document indicates 
there
should be a FullCompliance and ReadOnlyCompliance statement.

> 6.4 Printer MIB Alarm Example
>
>     Consider the following Notifications defined in the
>     printer MIB [RFC1759]:

I understand the problem with copying from another document
for complete definitions, but here are some copied and not all
objects as defined in the OBJECTS-clause of 'printerV2Alert'.
I would suggest add all, or as it seems the most used 'prtAlertGroup'
or none.

>
>     prtAlertSeverityLevel OBJECT-TYPE
>      -- This value is a type 1 enumeration
>      SYNTAX     INTEGER {
>                   other(1),
>                   critical(3),
>                   warning(4)
>               }
>      MAX-ACCESS read-only
>      STATUS     current
>      DESCRIPTION
>        "The level of severity of this alert table entry.  The printer
>        determines the severity level assigned to each entry into the
>        table."
>      ::= { prtAlertEntry 2 }
>
>     printerV2Alert NOTIFICATION-TYPE
>      OBJECTS { prtAlertIndex, prtAlertSeverityLevel, prtAlertGroup,
>              prtAlertGroupIndex, prtAlertLocation, prtAlertCode }
>      STATUS  current
>      DESCRIPTION
>        "This trap is sent whenever a critical event is added to the
>        prtAlertTable."
>      ::= { printerV2AlertPrefix 1 }

> 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).

regards,

Harrie

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 18 Mar 2003 22:53:21 -0800

Hi Harrie -

Thanks, the quick and detailed comments are greatly appreciated.

I'd like to ask the document editors to make a quick pass through these
to identify the ones they consider purely editorial, so that we can spend
some time on the technical ones at the WG session Wednesday afternoon.
Ok, Sharon?  (Since I know Dan may not be able to attend the whole
session.)

Randy

> From: "Harrie Hazewinkel" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, March 18, 2003 8:34 AM
> Subject: [Disman] comments for draft-ietf-disman-alarm-mib-09.txt
>