Subject: RE: disman wg last calls update

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 18 Sep 2002 01:07:17 -0400

Glenn,

Thanks for your comments.
Please see inline below for response.

Regards,
Kam

> -----Original Message-----
> From: Glenn Mansfield Keeni [mailto:[email-masked]]
> Sent: Saturday, September 14, 2002 6:17 AM
> To: [email-masked]
> Subject: Re: disman wg last calls update
> 
> 
> 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.

I didn't receive your earlier email. Is a through i the complete list? 

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

There is no subtle difference between the two. 
The notation of NALM-TI etc. is used in M.3100 Amendment 3. 
This notation is mapped to nalmTI etc. in the ASN.1 of the mib. 
Agree with your suggestion. 
Will use the enumerated state definitions of arcState.

>     b. arcAlmTimeRemaining is Unsigned32 should it be a Gauge32 ?

Agree, as arcAlmTimeRemaining can increase and decrease. 
It will be changed to Gauge32.

>     c. an example in the arcIndex DESCRIPTION would be very helpful.

Agree and will add the following text to the arcIndex DESCRIPTION clause:
        
        If this resource is an interface, 
        this object will point to an instance of interface, e.g., ifIndex.1.

By the way, the syntax of arcIndex will be changed to the ResourceId TC 
from the alarm mib as suggested by Sharon Chisholm.

>     d. should we use the REFERENCE clause for IANAItuProbableCause
>        in arcAlarmType.

Agree. The sentence

        'IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC 
         module in the Alarm MIB document.'

will be updated to

        'IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC 
         module in the Alarm MIB document [RFCxxx].'

where xxx will be filled by the assigned RFC number of the alarm mib 
document. The Reference clause will be updated also.

>     e. in arcNotificationId DESCRIPTION clause   s/ identify 
> / identifies /

Agree.

>     f. arcState should have a default value. (What happens if
>        arcEntry is without a value for arcState ?)

M.3100 Amendment 3 doesn't define a default value for arcState.
According to the requirements in M.3100 Amendment 3, a resource 
supporting the ARC feature shall support the ALM state and at 
least one of the NALM, NALM-TI, and NALM-QI states.

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

The inclusion of alm is to allow the manual setting of the arcState to 
alm such that have the effect of removing the entry from the arc table.
Now with the inclusion of the RowStatus object in the mib, setting RowStatus 
to destroy will have the same effect of removing the entry from the arc table.
So, I agree that the alm state can be removed from the enumerated state 
definition of arcState.

>     h. In arcRowStatus s/a arc/an arc/

Agree.

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

Agree. I will include the examples into Section 6. 
They are indeed good examples.

> 
> Glenn
> 
> Randy Presuhn wrote:
> > 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: "Tom Petch" <[email-masked]>
Date: Wed, 18 Sep 2002 21:56:45 +0100

Coming back to this document after a break, I got thrown once or twice
while reading it and would suggest a few changes of wording; these are
not (I hope) semantic changes.

3.4 (mostly) gives Notification an initial capital which I think is
right.  The rest of the document does not leaving me with a slight
doubt that this is always the same thing.  I like consistency, initial
capital preferred.

3.3.1
Suggest

   The subject of alarm management can potentially cover a large
number
   of topics including real-time, historical, correlation, and
   suppression, to name a few.

becomes

   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.
(if that is what is meant:-)

3.3.2 Flexible Alarm Modeling

   Alarm states modelled** (not modeled)

3.3.3 Problem Indication

suggest ITU-ALARM-MIB (as in 3.3.6)

3.3.5 Identifying Resource under Alarm

suggest

     context/IP pair**? is its own list.
becomes
     context/source IP address pair is its own list.
(or should it be engine address since that is what the MIB specifies?)

3.7 Relation to Notification Log MIB

Suggest nailing down which version of SMI this supports; I expect new
ones!

4.1 Overview

   counts as well as the time of the last alarm raise and alarm clear
(**singular)

   The MIB also defines generic alarm notifications that can be used
   **when there is no**
rather than
   in the event that there is not an

event is a (contentious) technical term, best avoided which it is easy
to do

4.1.1 Extensible**ibility ??

Had to read this several times to understand it and I am not sure I
do.  It is the switch from other modules to specific MIB to specific
MIBs to extended that gives me pause; are these all the same concept
or a single table extension?
There is only one alarmModelSpecificPointer
object/alarmActiveSpecificPointer object so an alarmActiveTable row eg
can only point to one other row (I deduce); can there be multiple MIB
tables in multiple MIB modules with different rows pointing into rows
from different modules? or even can rows be chained from
alarmActiveTable to specificActiveTable to anotherActiveTable?

I don't want to change the semantics, just to have one clear meaning
from this paragraph.

4.1.3 Alarm State Transition Notification

   defined in alarmModelNotifiationId**
wants another c in there

4.1.6 Active Alarm Management

   Lists of alarms currently occurring on an SNMP entity are stored in

Suggest active rather than occurring

4.1.7 Distributed Alarm Management

     alarmListName for each of the devices it managed
suggest manages

Tom Petch
[email-masked]