Subject: disman wg last calls update

From: Randy Presuhn <[email-masked]>
Date: Fri, 13 Sep 2002 17:09:45 -0700 (PDT)

Hi -

We're halfway through the disman WG last calls on the two
alarm-related documents.  I have seen no comments yet, and
have not even received any indication that anyone has read
either of the drafts.  This does not bode well.

If you do not want to see this work unceremoniously dumped
for lack of interest / progress, I strongly suggest reading
the documents, and sending your comments (favorable or
otherwise) to the disman WG mailing list.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  SJC-1.3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Glenn Mansfield Keeni <[email-masked]>
Date: Sat, 14 Sep 2002 19:16:33 +0900

Hi,
   The earlier mail on Comments on draft-ietf-disman-conditionmib-04.txt
left my keyboard before I wanted it to go.
    The rest of the comments follow.

    a. There are two notations used in this document for the states
        e.g. nalmTI and NALM-TI. Is there any subtle difference between
       the two ? If not, I suggest we use the enumerated state definitions
       of arcState.
    b. arcAlmTimeRemaining is Unsigned32 should it be a Gauge32 ?
    c. an example in the arcIndex DESCRIPTION would be very helpful.
    d. should we use the REFERENCE clause for IANAItuProbableCause
       in arcAlarmType.
    e. in arcNotificationId DESCRIPTION clause   s/ identify / identifies /
    f. arcState should have a default value. (What happens if
       arcEntry is without a value for arcState ?)
    g. The alm state seems to be redundant - there will never be an
       entry with this state according to the description
       "Once the resource enters the normal reporting mode (i.e., in the
        alm state) for the specified alarm type, the corresponding
        entry will be automatically deleted from the arc table."
        Not a big deal really.
    h. In arcRowStatus s/a arc/an arc/
    i. Security considerations : We MUST state clearly that the MOs in
       the MIB have significant impact on the security of the relevant
       devices and networks. A mischief maker will probably try to switch
       the alarm system off in the first place. Further, you would not
       want any mischief maker to know that your alarm system is switched
       off. Thus access to MOs in this MIB must be very carefully regulated.
       There IS some text about this , with emphasis on read-create objects
       but I am not sure that the implications are made clear enough.

Glenn