Subject: [Disman] Section 3.1 in draft-ietf-disman-alarm-mib-15.txt

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 15:32:34 -0700

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Cc: <[email-masked]>; "Randy Presuhn" <[email-masked]>; "Romascanu, Dan (Dan)" <[email-masked]>
> Sent: Monday, September 29, 2003 7:34 AM
> Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt
...
> 12) Page 4: "ITU" acronym should be expanded, for
>     "ITU model" a reference should be given.
...

Although this item was marked "Changed", I see there is still
no reference for "ITU model".  Is there a rationale for omitting
the reference, or was it just an oversight?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 15:32:34 -0700

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 15:36:39 -0700

Hi -

...
> 17) Page 6: "OID" acronym should be expanded
...

Although this one is marked "Changed", the result is that
the acronym now occurs for the first time on page 16, but
still without expansion.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 15:36:39 -0700

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 15:57:17 -0700

Hi -

...
> 33) Section 4.1.1: one consequence of this approach is that
>     one cannot use multiple extensions for a single alarm.
>     So, for example, one couldn't make an extension to the
>     ITU Alarm MIB and have it work using the method described here.
>     This may be the intent, but it would be good to be explicit about it.
...

The -15- text for section 4.1.1 still doesn't really acknowledge the
inherent limitation of alarmModelSpecificPointer.  Its syntax limits it
to referring to a single extension.  If one were to define another MIB
containing a table augmenting the ITU alarm stuff, the value of
alarmModelSpecificPointer would still presumably point to the
ITU alarm stuff rather than the augmentation, so a management
station would be left to grope around for this (and any other second-
level) extensions.  I'm *not* proposing that we change the design.
I was (and still am) concerned as a technical contributor that we
be upfront about the (perhaps theoretical) design limitation.

If no one else cares about this, as WG chair I'm willing to let it go
as is. but as a technical contributor I wanted to be sure that folks
understood why I'm not 100% happy with the revised text here.

Randy

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 15:57:17 -0700

Hi -

...
...

Randy

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 16:04:06 -0700

Hi -

...
> RFC Editor
> ----------
> 2) the FF character is merged with the header lines,
> resulting in many too-long lines.  The RFC editor can
> fix these.

Agreed.  I just wish the secretariat would stop accepting
mis-formatted I-Ds.

> 7) Page 3: "be able to determine current problems on a system" ->
>            "be able to determine what the current problems on a system are"
>
> 13) Page 4: formatting of "Alarm State" paragraph is odd;
>     there is a premature line break after "also".
>
> 15a) (global) The document is inconsistent in its use of space
>     after period at the end of a sentence.  There should
>     consistently be two spaces after each period ending a sentence.
>
> 16) (global) "modelling" -> "modeling",
>     "modelled" -> "modeled"
>     "behaviour" -> "behavior"
>     A spelling check would be advisable to extirpate the briticisms.
...

I think you'll find that you'll end up fixing (7), (13), and (16) yourself
during AUTH48, and that not having fixed (15a) yourself will make
the task a real pain.  I speak from experience.  The RFC editor does
a superhuman job, but you'll find that errors do creep in, and being
able to do a word-for-word check during AUTH48 is important.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 16:04:06 -0700

Hi -

...

...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 16:22:41 -0700

Hi -

...
> 35) Section 4.1.3: (see comment 14 above) this paragraph doesn't
>     tell the whole story of what a manager needs to do to get
>     these notifications.  The sentence beginning with "alternatively"
>     only makes things worse, since it will result in a configuration
>     that is contrary to the goal in the paragraph's topic sentence.
...

The updated text is better.  However, the last sentence in the first
paragraph is misleading:

   in an architecture as described in section 3.2. Specifying no
   Notifications in the alarmModelNotificationId, regardless of what is
   defined in the SNMP-TARGET-MIB, would result in no Notifications
   being logged or sent to management stations.

Suggested replacement:

   in an architecture as described in section 3.2. Specifying no
   Notifications in the alarmModelNotificationId, regardless of what is
   defined in the SNMP-TARGET-MIB, would result in no Notifications
   being logged or sent to management stations as a consequence of
   this particular alarm state transition.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 16:22:41 -0700

Hi -

...
...

Suggested replacement:

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 16:27:14 -0700

Hi -

...
> 42) 4.1.7: "therefore," -> ""
...

There's a superfluous comma left over in this line on page 14:
 named alarm lists.  A middle manager could, create an alarmListName

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 16:27:14 -0700

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 16:51:03 -0700

Hi -

...
> 43) page 15 (ResourceId):  I agree with the intent of the last
>     sentence in the description, but if there is a MUST requirement
>     here, how do we ensure that implementations know what to choose
>     for any arbitrary table?
>
> Sharon -> I added this, but I probably should not have. I guess we can
> consider it clarifying editorial in nature.
...

What's there now is (still) problematic.  Specifically:

               For example, if this resource is an interface, this
               object MUST point to an ifIndex and if this resource
               is a physical entity, then this MUST point to an
               entPhysicalIndex. In general, pointing to objects that
               act as index into an IETF MIB tables for the resource
               will provide the most consistency."

I see two problems:
    1) entPhysicalIndex is not-accessible
    2) no guidance is given as to which element of a row should be chosen

I suggest borrowing from the description of RowPointer in RFC 2579.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 16:51:03 -0700

Hi -

...
...

I see two problems:

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 17:00:43 -0700

Hi -

...
> 49) alarmModelRowStatus should spell out that the
>     alarmModelVarbindIndex and alarmModelVarbindValue
>     MUST be set before row can go active.
>
> Sharon-> I've fixed this another way.
...

AlarmModelRowStatus *still* needs to spell out what objects are necessary
for the row to be activated.  See
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-02.txt

     - The DESCRIPTION clause of the status column MUST specify which
       columnar objects (if any) have to be set to valid values before
       the row can be activated.  If any objects in cascading tables
       have to be populated with related data before the row can be
       activated, then this MUST also be specified.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 17:00:43 -0700

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 18:35:23 -0700

Hi -

...
> 55) alarmModelRowStatus does not permit modification of a
>     model while active alarms exist.  This would seem to create
>     the possibility of "un-throttle-able" alarm storms, contrary
>     to the spirit of draft-ietf-ops-mib-review-guidelines-01.txt
>     section 4.7 last paragraph.
...

The updated text is still problematic. Specifically, this text remains:

       This row can not be modified or deleted while it is being
       referenced by a value of alarmActiveModelPointer. In these

As long as there is an active alarm referencing the model, one would
not be able to take action using this MIB to throttle it.

Also, the entry removal text doesn't specify a lifetime, and the famous
five minutes in 2579 are only a suggestion, so the current text really
leaves it up to the implementation.  This is OK with me, but I want to
be sure it's what is intended.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 18:35:23 -0700

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 18:51:20 -0700

Hi -

...

...
> 58) alarmActiveEngineAddress: "IP Address" -> "address"
>     ditto alarmClearEngineAddress
...

One step forward, two steps back.  :-) * 0.5
   - "Address" should be "address"
   - the sentence "This is used to identify the source of an SNMPv1
       trap, since an alarmActiveEngineId cannot be extracted from the
       SNMPv1 trap PDU." leaves me wondering why it's there, since even
       if one can extract an SnmpEngineId from a wrapper, it still won't
       reliably yield an address.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 18:51:20 -0700

Hi -

...

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 20:51:29 -0700

Hi -

...
> 59) alarmActiveContextName: this is defined to be an SnmpAdminString.
>     This is fine for the case where its value is a context name.
>     However, in the case where it is a community, provision needs
>     to be made for the possibility that the community name would not
>     be a well-formed SnmpAdminString.  (for example, 0xFF would be
>     a legal community, but would violate the rules for UTF-8.)
>     ditto alarmClearContextName
...

I think this probalem hasn't been addressed.
The current text says:

   alarmClearContextName OBJECT-TYPE
      SYNTAX      SnmpAdminString (SIZE(0..32))
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The name of the SNMP MIB context from which the alarm came.
          For SNMPv1 traps this is the community string from the Trap.
          Note that care needs to be taken when selecting community
          strings to ensure that these can be represented as a
          well-formed SnmpAdminString.

If an SNMPv1 trap had a community string with a value of 0xFF,
what value would the corresponding instance of this object have?
The alarm MIB implementation has no control over the community
strings it might encounter.

          If the alarm's source SNMP engine is known not to support
          multiple contexts, this object is a zero length string."
      ::= { alarmClearEntry 6 }

Is this intended to be a MUST or a MAY?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Oct 2003 20:51:29 -0700

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 15:31:36 -0700

Hi -

...
> 65) 5.1: "about alarms" -> "about alarms modeled using the ituAlarmTable"
>     "total alarms" -> "total alarms modeled using the ituAlarmTable"
...

Though this item is identified as "changed", it looks like it only got half done.
As it stands, I think this sentence is still incorrect:

   The ituAlarmActiveStatsTable provides statistics on current and
   total alarms.

The number is the total for stuff modeled using the ituAlarmTable,
not total alarms in the system, right?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 15:31:36 -0700

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 15:41:38 -0700

Hi -

...
> 66) 5.2: we will probably need to give IANA more guidance on how additions
>     should be approved.  We agreed that we didn't want an immortal WG, but
>     we do need to tell them what kind of review, if any, is needed before
>     a addition is made.
...

Though this is marked "changed", I can't find a statement about what
kind of review is needed for additions.  I think RFC 2434 section 4 is
pretty clear that this is needed.  I propose the "specification required"
level of review.  Other thoughts?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 15:41:38 -0700

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 15:49:47 -0700

Hi -

There's a superflous " " at the beginning of the text of the description
clause for ituAlarmActiveTrendIndication.
Ditto alarmActiveStatsGroup, alarmClearGroup, and ituAlarmTc.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 15:49:47 -0700

Hi -

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 15:56:20 -0700

Hi -

...
> 75-2) This section should also mention throttling / DoS attacks based on
> notification generation.
>
> Sharon->Neither of the examples given in the MIB Review Guidelines do
...

Given the IESG's comments on the ARC MIB, I believe we need to reconsider this
comment.

Randy Presuhn, disman WG chair

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 15:56:20 -0700

Hi -

...
...

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 16:06:19 -0700

Hi -

...
> 70) ituAlarmActiveDetector, ituAlarmActiveServiceProvider, and
>     ituAlarmActiveServiceUser need better DESCRIPTIONs.  I think
>     it needs to be more explicit that their values are the names
>     of the object instances corresponding to these resources.
>
> 72) The DESCRIPTION of ituAlarmServiceUserGroup isn't helpful.
>
> Sharon->These are the descriptions used in the ITU. It would be a new
> Sharon->design item to provide 'improved' descriptions.
...

If the ITU definitions really are that vacuous, I guess we're stuck with them.
The repeated "This group is optional" DESCRIPTIONs in ituAlarmCompliance
don't make me feel any better, but if no one else is bothered by this, I'm
willing to let it go and hope the IESG feels the same way.

Randy, as disman WG chair.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 16:06:19 -0700

Hi -

...
...

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 19:53:31 -0700

Hi -

...
> 62) alarmActiveStatsActives, the SYNTAX says this is a Counter32,
>     but the DESCRIPTION sure makes it sound like it's supposed to
>     be zero-based.
>
> 71) ituAlarmActiveStatsIndeterminates,
>     ituAlarmActiveStatsCriticals,
>     ituAlarmActiveStatsMajors,
>     ituAlarmActiveStatsMinors, and
>     ituAlarmActiveStatsWarnings are all Counter32, but their
>     DESCRIPTIONs sound like they're assumed to be zero-based.
>
> Sharon-> Counter32 can have a value of 0.
...

Let me put it another way:
  if none of these events have occured since system restart,
  what will the value of these objects be?

  a) zero, since the descriptions say they are counts "since system restart"
     if this is the case, they should use the ZeroBasedCounter32 TC
  b) not predictable, given the defnition of Counter32 in RFC 2578 clause 7.1.6
     if this is the case, then the "since system restart" words are misleading

Randy (technical contributor)

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 19:53:31 -0700

Hi -

...
...

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 20:17:31 -0700

Hi -

...
> 44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION
>     talks about "instantiation" doesn't make sense.  I think it's
>     referring to use of the TC in an OBJECT-TYPE definition, rather
>     than object instantiation.
>
> Sharon -> This seems more a wordsmith thing.
...

The DESCRIPTION still doesn't make sense.  It currently says:
               "An SNMP Engine ID or a zero-length string. The
               instantiation of this object will provide guidance
               on when this will be an SNMP Engine ID and when it
               will be a zero lengths string"

This is a TC definition, so "instantiation of this object will
provide guidance" makes no sense at all to me.  In both cases
where this TC is used, the conditions for a zero-length string
value are the same: either the notification came from a protocol
(SNMPv1 is not the only one! don't forget SNMPv2c) which doesn't
use SNMP Engine ID, or all entries in the table currently have the
same Engine ID.  (I guess that means that when one arrives from
some other engine, all these objects' values will change from
zero-length string back to their "real" values.  Am I the only person
bothered by this?)

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 20:17:31 -0700

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 21:41:44 -0700

Hi -

...
> 11) Page 4: "transmissions of management" ->
>     "transmission of management"  (I personally think that
>     defining "notification" in terms of transmission is a
>     mistake, but it's too late to re-hash that discussion.)
...

The typo "transmissions" -> "transmission" still needs to be fixed.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 21:41:44 -0700

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 21:49:15 -0700

Hi -

...
> 14) Page 4: "A notification SHOULD be sent on alarm raise."
>     Given the definition of notification, and the role of RFC
>     3413, this sentence should be deleted.  Whether a notification
>     should be sent depends on whether some manager is interested
>     in it and has configured the SNMP-NOTIFICATION-MIB and
>     SNMP-TARGET-MIB accordingly.
>
> Sharon -> This was explicitly discussed and wg consensus was that it was OK
> to indicate a preference for sending notifications.
...

Perhaps I'm just getting denser, but I still don't see how this belongs
in the definition for "Alarm Raise".  The current text says:

  Alarm Raise
     The initial detection of the fault indicated by an alarm or any
     number of alarm states later entered, except clear. A Notification
     SHOULD be sent on alarm raise.

The second sentence simply does not belong in the definition.  Furthermore,
the SHOULD language directly contradicts the normal functioning of this
MIB module, which provides a means of controlling whether a Notification
is issued, and the operation of RFC 3413, which controls whether it is
sent anywhere.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 21:49:15 -0700

Hi -

...
...

  Alarm Raise

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 22:00:04 -0700

Hi -

WG chair hat on...

...
> 63) alarmActiveState, alarmClearState: the names for these notifications
>     aren't terribly good. more importantly, something needs to be said
>     about throttling per draft-ietf-ops-mib-review-guidelines-01.txt
>     section 4.7 last paragraph, perhaps simply to the effect that these
>     are "second order" notifications that rely on lower-level throttling
>     and filter specification.
>
> Sharon->I did this more in line with the examples in the review guidelines.
...

There are some pretty significant changes to the definitions of these two
notification types appearing with the -15-draft.  I'd like to get a sense
of the working group that this particular approach to notification throttling
is appropriate for this MIB module.  I'd like to hear from those who think
this type of throttling is appropriate in this case, as well as from those who
would prefer something else.

As technical contributor: I still think "alarmActiveState" and "alarmClearState"
are lousy names for notifications, and would prefer to *not* do throttling
at this layer, but rather higher or lower in the processing stream.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 22:00:04 -0700

Hi -

WG chair hat on...

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 22:17:05 -0700

Hi -

...
> 47) (alarmModelVarbindIndex) (also alarmActiveVariableEntry)
> I repeat my comments from May, since they're still not reflected in the
> draft:
>
> > The words that are there now seem to be backwards from what I thought
> > was agreed: since RFC 3416 is Standard, and 1157 is Historic, that the
> > numbering should start with 1 for the SysUptime, which would be the
> > value extracted from elsewhere in the PDU in the case of a SNMPv1
> > trap.  What's there now (still) seems unnecessarily confusing.
> >
> > Note that Harrie Hazewinkel's message of March 18, 2003 also has
> > concerns with this same paragraph.
> >
> > The discussion back in April 22, 2002 went the same way, and Sharon's
> > post of June 3, 2002 gave the resolution of issue #38 as being to
> > treat everything "v2-style".
>
> Sharon-> See Section 3.6 of the document
...

The text now reads:
3.6 Notification Varbind Storage and Reference

   In SNMPv1 [RFC1157], 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[RFC1215]. 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.

   The varbind storage approach taken in the Alarm MIB is that
   sysUptime and snmpTrapOID SHALL always be stored in the active alarm
   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 [RFC3584].

So far, so good.  But then the next paragraph says:

   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.

This seems unnecessarily convoluted, and results in an even more complicated

   alarmModelVarbindIndex  OBJECT-TYPE
      SYNTAX  Unsigned32
      MAX-ACCESS   read-create
      STATUS       current
      DESCRIPTION
        "The index into the varbind listing of the notification
        indicated by alarmModelNotificationId which helps
        signal that the given alarm has changed state.
        If there is no applicable varbind, the value of this
        object MUST be zero.

        Note that the value of alarmModelVarbindIndex ignores
        the existence of the first two obligatory varbinds in
        the InformRequest-PDU and SNMPv2-Trap-PDU (sysUpTime.0
        and snmpTrapOID.0).  That is, a value of 1 refers to
        the first varbind after snmpTrapOID.0.

        If the incoming notification is instead an SNMPv1 Trap-PDU,
        then a value of 1 refers to the first varbind."
        DEFVAL { 0 }
       ::= { alarmModelEntry 4 }

As a technical contributor, I think it's really twisted to warp everything
into an SNMPv1 point of view.  1 should refer to the first varbind in
alarmActiveVariableTable for a particular alarm.  This is also needed
for internal consistency with the DESCRIPTION of alarmActiveVariableEntry,
which states:

          If the incoming notification is instead an SNMPv1 Trap-PDU and
          the value of alarmModelVarbindIndex is 1 or 2, an appropriate
          value for sysUpTime.0 or snmpTrapOID.0 shall be determined
          by using the rules in section 3.1 of [RFC3584]."

As WG chair, I thought we had a clear consensus to do it the SNMPv3
way.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 22:17:05 -0700

Hi -

...
...

The text now reads:

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 22:31:12 -0700

Hi -

...

...
> 75-4) I missed anything like an "alarmActiveMaximum", yet the document
> doesn't seem to describe what should happen if there are too many active
> alarms, as might happen if there are lots of instances of a particular type
> of resource, and an administrator inadvertently specifies a frequent,
> innocuous event as being of interest.
>
> Sharon->The design was normal table wrapping
...

What is "normal table wrapping"?  This is a new one for me.
The document still needs to specify what happens.  For example,
if the alarm raise is lost, will the clear also be siletly suppressed?
Even with frequency throttling in place, if alarms are sufficiently
long lived there may still accumulate a very large number of them.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 22:31:12 -0700

Hi -

...

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 22:49:40 -0700

Hi -

...
> 26) Section 3.3.5: "Solutions interested in being able to differentiate the
>    source of the alarm by means other than the source IP address and
>    resource ID"  is at odds with what's actually done in the
>    alarmActiveEntry and alarmClearEntry.  Both include information
>    for the LocalSnmpEngineOrZeroLenStr, AddressType, EngineAddress,
>    and ContextName.
...

The text still doesn't match the actual operation of the MIB.
The current text says:
   The Alarm MIB provides a generic method for identifying the resource
   by extracting and building a resource ID from the Notification
   varbinds. Solutions interested in being able to differentiate the
   source of the alarm by means other than the source IP address and
   resource ID should create separate alarm lists such that each
   context/source IP address pair is its own list.

I still don't see why one would need to create separate alarm lists,
nor do I see why we're talking about IP addresses when one also
needs a port (if one is even using IP!) to find an agent.

Proposed replacement text:
   The Alarm MIB provides a generic method for identifying the resource
   by extracting and building a resource ID from the Notification
   varbinds.  It records the relevant information needed to locate the
   source of the alarm.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 22:49:40 -0700

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Oct 2003 11:42:36 -0700

Hi -

...
> 24) Section 3.3.3: the first sentence is a bit hard to swallow:
>     as a practical matter, to find out which notifications are
>     not of interest, one would have to walk the alarm model table
>     to find out what *is* of interest, and then remove that set
>     from the set of all possible notifications, which isn't listed
>     in any convenient spot.
...

Proposed fix:

CURRENT:
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. In addition,

REPLACEMENT:
The Alarm MIB provides a means to determine whether a given
notification is not of interest to managers for purposes of alarm
management by permitting inspection of the alarm models.
If no entries in the alarmModelTable could match a particular
notification, then that notification is not relevant to the alarm
models defined.  In addition,

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Oct 2003 11:42:36 -0700

Hi -

...
...

Proposed fix:

CURRENT:

REPLACEMENT:

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Oct 2003 11:48:22 -0700

Hi -

...
> 39) 4.1.5: "table can, and probably should, be" ->
>     "table MAY be".  I don't think we had consensus
>     to make this a SHOULD, but I'm open to the possibility.
...

Proposed change:

OLD:
  The alarm model table can, and probably should, be initially
  populated by the system. The objects in alarmModelTable and
  ituAlarmTable have a MAX-ACCESS of read-write, which allows managers
  to modify the alarm models to suit their requirements.

NEW:
  The alarm model table MAY be initially
  populated by the system. The objects in alarmModelTable and
  ituAlarmTable have a MAX-ACCESS of read-write, which allows managers
  to modify the alarm models to suit their requirements.

(I have no problems with "SHOULD", but I think "can, and
probably should" does not belong in standards-track material.)

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Oct 2003 11:48:22 -0700

Hi -

...
...

Proposed change:

OLD:

NEW:

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Oct 2003 12:18:56 -0700

Hi -

...
> 69-1) ituAlarmEntry: the DESCRIPTION needs to say something about how
>     rows in this table come into existence.  Currently, it looks like
>     immaculate conception.  If these things are created under management
>     control, then I'd strongly suggest DEFVALs for
> ituAlarmPerceivedSeverity,
>     ituAlarmEventType, ituAlarmProbableCause, and ituAlarmAdditionalText.
...

Let me step through my reasoning for wanting a clearer description of the
lifecycle of these things.  Perhaps someone can point out where I've gone
wrong, or, if my reasoning is correct, how we might fix things.

Currently, the table definition reads:
   ituAlarmTable OBJECT-TYPE
      SYNTAX      SEQUENCE OF ItuAlarmEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "A table of ITU Alarm information for possible alarms
          on the system."
      ::= { ituAlarmModel 1 }

   ituAlarmEntry OBJECT-TYPE
      SYNTAX      ItuAlarmEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Entries appear in this table for each possible alarm
           severity.
           This table MUST be persistent across system reboots."
      INDEX       { alarmListName, alarmModelIndex,
                   ituAlarmPerceivedSeverity }
      ::= { ituAlarmTable 1 }

The DESCRIPTIONs (and lack of RowStatus) would lead one to believe that
these are static tables that describe the possible severity levels that can
occur on a system.  However, the INDEX structure ties these to the alarmModelTable.
Entries in the alarmModelTable may be created (and deleted) using
AlarmModelRowStatus, so the values of alarmListName and alarmModelIndex
may be coming from a manager somewhere.  This begs several questions:
    1) when a new alarm model is created using RowStatus, do corresponding
        entries automagically appear in the ituAlarmTable?  Do they appear as
        a side-effect of setting alarmModelSpecificPointer?  If so, are the
        indexing constraints on possible legal values for this pointer enforced
        by the agent?
    2) If corresponding entries automatically appear in the ituAlarmTable when
        new alarmModelTable entries are created, how are the values for the
        various columns supplied?
    3) if an alarmModelEntry is deleted, what happens to the corresponding
        ituAlarmModelEntries (since it's a one-to-many relationship due to
        ituAlarmPerceivedSeverity, I assume they will always appear and disappear
        six at a time.)

Does this help to explain why I'd like the DESCRIPTIONs to better explain what's
going on with this table?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Oct 2003 12:18:56 -0700

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Oct 2003 12:25:05 -0700

Hi -

...
> 68) ituAlarmGenericModel: why is this object needed? the indexing
>     information needed to find the model entry is the same for both
>     tables.
...

ituAlarmGenericModel seems comepletely redundant.
All the information needed to find the alarmModelEntry
corresponding to an ituAlarmEntry is already present
in that entry's indexes.  This object serves no purpose.

Proposal:  remove ituAlarmGenericModel.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Oct 2003 12:25:05 -0700

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Oct 2003 12:06:11 -0700

Hi -

...

> 56) alarmListName's DESCRIPTION should spell how this object's
>     value hooks into the SNMP-NOTIFICATION-MIB.  Without out this
>     bit of explanation, the whole thing is magic.

It's good that it explains the non-normative relationship to nlmLogName.
However, it's more important that it also be explicit about the fact
that the notification got here by matching an RFC 3413 snmpNotifyFilterProfileName,
since that's the mechanism for selecting the notifications in the first place,
as sketched out in the diagram in section 3.2

> 60) alarmActiveLogPointer: should spell out that the log's name
>     would be the same as alarmListName for this instance.
>     ditto alarmClearLogIndex

I'll relent on this one, since adequate text for (56) would make this
redundant.

> 75-1) Section 7 should describe the need for security administrators to
> configure a coherent VACM policy for the configuration of the
> SNMP-NOTIFICATION-MIB, the log MIB, and these MIBs based on log name.
>
> Sharon->We agreed back when everyone was complaining about the
> Sharon->notification log MIB to not tie this document to it. The goal

agree we don't need a normative reference

> Sharon->was to be able to support it and any other log.
...

That wasn't the reasoning as I recall it.  The problem was that the
initial versions of this tied alarms to log entries, and the life-cycle
of a log entry may be different from that of an alarm.

Anway, that's not the issue.

This is *not* a question of making a normative reference to the log
MIB.  Rather, it's about explaining how this MIB is meant to be used.
We've seen enough complaints that I'd prefer to err on the side of
being overly clear.

The relationship between RFC 3014's nlmLogName and RFC 3413's
snmpNotifyFilterProfileName (particularly since 3014 calls it
snmpNotifyFilterName) is practically an FAQ, even though 3014 2.2.1
spells it out.  The -15- i-d  only hints at the relationship in the diagram
in section 3.2

For item 75-1, the issues are similar to those we faced when we did
the log MIB: how to design the MIB and write the security considerations
section so that we didn't "leak" information.  To me, this means providing
a modicum of guidance to security administrators in the security considerations
section so that this MIB can be used with reasonable safety.  The relationship
between nlmLogName, snmpNotifyFilterProfileName, and alarmListName
is deliberately chosen to make life easier for the security administrator.

Proposed words to add to security considerations:  "This MIB module can
provide access to information that may also be accessed through
manipulation of the SNMP-NOTIFICATION-MIB and the NOTIFICATION-LOG-MIB.
This is expressed in part through the common indexing structure of
nlmLogName [RFC3014], snmpNotifyFilterProfileName [RFC3413],
and alarmListName.  Consequently, it is RECOMMENDED that security
administrators take care to configure a coherent VACM security policy.
The objects alarmActiveLogPointer, alarmActiveModelPointer,
alarmActiveSpecificPointer,  and alarmClearModelPointer
are object identifiers that reference information to which a particular
user might not be given direct access.  The structure of these
object identifiers does not permit the extraction of any sensitive information.
Two other objects, alarmClearResourceId, and alarmActiveResourceId,
are also syntactically object identifiers, but their structure
could provide a user with potentially useful information to which
he or she might not otherwise be granted access, such as the
existence of a particular resource."

Whew.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Oct 2003 12:06:11 -0700

Hi -

...

...

Whew.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Oct 2003 14:03:54 -0700

Hi -

...
> 28) Section 3.7: "This format allows for the storage of any Trap
>     or Notification that can be defined using SMIv1 or SMIv2."
>     Not quite consistent with definition of "Notification";
>     suggest "instance of any TRAP-TYPE or NOTIFICATION-TYPE",
>     though I think talking about SMIv1 and SMIv2 isn't helpful here.
>     See #47 below.
>
> Sharon-> I actually meant the SMI.
...

How about this proposed replacement text:
"This format allows for the storage of any Trap
or Notification type that can be defined using the SMI,
or can be carried by SNMP."

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Oct 2003 14:03:54 -0700

Hi -

...
...

Randy