Subject: comments on expression draft

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Mar 1999 12:28:02 +0100

Here are my comments on the expression MIB draft:

1) It might be helpful to break the second sentence in the section
   "Overview" (which is also identical to the second paragraph itself)
   into smaller pieces.

2) It think it should be tables instead of table in the third
   paragraph in section "No Wildcards".

3) I think the second paragraph in section "One Object Expressions"
   can be removed since the event MIB now has its own delta sampling
   mechanism.

4) Change `final section of object identifier' to `final section of
   the object identifier' in the secon paragraph of section "Value".

5) Line up the indentation of the OID for personBlessing and
   townPersonBlessing in section "Wildcarding".

6) The example which shows how you would calculate interface loads
   needs to be updated to reflect owner indexing. To keep the example
   short, I suggest to add ".0" after all descriptors (thus using an
   empty owner index).

7) The formula used to calculate interface loads does not work for
   full duplex point to point links. In this case, you have to use:

     max (ifInOctets, ifOutOctets) * 800 / seconds / ifSpeed

   (See Simple Times, 1(5), November/December, 1992.) I do not request
   to make the example more complicated than necessary. But it might
   be helpful to point out that the formular only works on some of the
   interface types we have.

8) The range for expResourceDeltaMinimum is similar to
   mteResourceSampleMinimum and probably needs also clarification.

9) Typo in the description of expResourceDeltaWildcardInstanceMaximum: 
   evalutation

10) Now that we have expOwner, is there still a need for
    expExpressionOwner? Or should we toss expExpressionOwner (remove
    the OwnerString import from IF-MIB) and rename expOwner to
    expExpressionOwner?

12) The MIB does not use StorageType. (This is more an observation
    since I get more and more afraid of Bob's dog.)

13) DateAndTime should be mentioned in the description of
    expObjectDeltaDiscontinuityID.

14) The description of expValueEntry probably needs to talk about
    expObjectSampleType changedValue in addtion to deltaValue.

15) The text in the description of expValueEntry starting "To maintain
    security of MIB information, when creating a new row in this
    table, ..." seems to be misplaced since a manager does not create
    entries in this table. Its probably sufficient to point to the
    description of expExpressionEntry which already has similar text.

16) Remove the phrase "and expression names with hierarchical
    structure" from the "Security Considerations".

17) There is an asymmetry between the event MIB and the expression MIB
    wrt to contexts. The event MIB allows to monitor objects and to do
    set operations in multiple contexts. It even supports context
    wildcarding. (Note, the current ID leaves it open in which context
    notifications are generated.) The expression MIB only works in a
    single context. I realize that making the expression MIB work over
    multiple contexts similar to the event MIB (ie you can have
    objects from multiple contexts in a single expression) will add
    quite a bit of complexity.

    This boils again down to the question of how one should think
    about contexts. I don't object against what is written down in the
    IDs (although I have mixed feelings about context wildcards since
    a manager has no idea what it means when turing it on).

							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)