Subject: review of draft-ietf-disman-express-mib-07.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Nov 1998 14:11:10 +0100

Here are my comments on draft-ietf-disman-express-mib-07.txt. (Some of
the comments will not surprise you anymore, but I repeat them here so
that things are documented in the mailing list archive.)

 1) The Abstract says that this memo "describes managed objects used
    for managing expressions of MIB objects". I am not sure whether
    this really indicates what the MIB is all about.

 2) Section 3, first sentence: "End users of MIBs..." I propose to
    change that to "Users of MIBs..."

 3) The third paragraph in section 3 says that the expression MIB is a
    "relatively powerful, complex, high-level application". The fourth
    paragraph says that "it is not reasonable that the MIB should
    assume a full-blown application-level environment." I think I
    understand what you are trying to say here. But the fact that a
    relatively powerful, complex, high-level application can't assume
    a full-blown application-level environment seems a bit
    contradictionay. You probably want to change the last sentence to
    something like: "This is appropriate since a MIB implementation
    must be possible in resource constraint environments."

 4) Section 3.2.2 says: "All wildcarded objects in an expression must
    have the same semantics for the missing portion of their object
    identifiers or the results are unpredictable." I think there is a
    difference between unpredictable results and meaningless results.
    I think the MIB definition must be precise enough to create only
    predictable results and the user of the MIB is responsible to
    configure expressions that create meaningful results. I am not
    100% sure what the text in section 3.2.2 tries to tell me.

 5) Rename EXPRESSION-MIB to DISMAN-EXPRESSION-MIB. (I guess I know
    you answer.)

 6) The description of expressionMIB says: "The MIB module for
    defining expressions of MIB objects for network management
    purposes." I think we should remove `network' since SNMP is not
    limited to network management only. What about shortening it to:
    "The MIB module for defining expressions of MIB objects."

 7) The usage of the 0.0 prefix in the wildcarding example is not
    explained if you read the MIB from the beginning to the end.  Even
    the text in expValueInstance does not mention the technical reason
    for the 0.0 prefix. What about adding a section 3.2.4 which gives
    a high-level explanation of how values are stored?

 8) The description of expResourceDeltaWildcardInstanceMaximum does
    not explain what happens if the maximum is reached.

 9) The security related paragraph in the description of
    expExpressionEntry should be more explicit. I think we need to be
    explicit that every access has to go though access control and
    what the security credentials are that need to be recorded in
    order to do that.

10) Using IMPLIED in expExpressionEntry means that the instance
    identifier for the same expression name is different in the
    expExpressionEntry and the epxObjectEntry. This creates special
    cases or encoding steps on managers as well as different sorting
    orders in both tables. I therefore suggest to remove IMPLIED from
    expExpressionEntry.

11) I would like to see an owner in the INDEX of expExpressionTable,
    epxObjectTable and expValueTable, but I know Bob's answer.

12) What is the motivation for the size bounds of expExpression as
    defined in the current draft?

13) There needs to be a reference to the ANSI C version used by the
    expression MIB. Most of the definitions can only be understood or
    implemented with the ANSI C standard on the desk. (BTW, I did not
    check whether the description of expExpression is complete and
    consistent because I do not have the ANSI C standard available
    right now.)

14) The description of expExpression says that an OID constant
    "comprises 32-bit, unsigned integers and at least one period, for
    example: 0. and .0" I think that OIDs with only one component are
    illegal and the text and the examples should therefore be changed.
    I also dislike the notation with leading dots. This will let some
    people assume that there is a magic prefix that is applied when no
    dot is used (especially those guys familiar with CMU derived
    tools) and this will lead to mis-configurations. We should avoid
    this problem.

15) I guess there is a missing `type' in the following sentence: "The
    following function definitions indicate their by naming the data
    type of the parameter in the parameter's position in the parameter
    list."

16) Write 4,294,967,295 as 4294967295 in order to avoid confusion.
    (The usage of , and . in numbers is differs between languages.)

17) Typo: availiable

18) Change unsignedOrGauge32 to unsigned32 in expExpressionValueType.

19) expExpressionComment should allow UTF-8 characters. (You can not
    even refer to the name of the expression in the comment. ;-)

20) The description of expExpressionDeltaInterval says: "In general
    one interval embedded below another must be enough shorter that
    the higher sample sees relatively smooth, predictable behavior."
    I am not sure how to implement or enforce this if I were to build
    a manager configuring the MIB. Is it possible to be more precise
    on this?

21) The error objects are only instantiated when the first error
    happens. This means that we have holes in the expExpressionTable.
    I think it would be nice to either give all these objects suitable
    values if no error has happened yet so that they exist all the
    time, or move them to a separate table which extends the
    expExpressionTable.

22) Typo in expExpressionError: evalutaion

23) OwnerString is not UTF-8, although it can contain the personnel's
    name (according to IF-MIB).

24) The expExpressionTable and the expObjectTable should have a
    StorageType column.

25) There are notes that wildcarding is not required. These notes
    should go into the compliance statement.

26) expObjectDeltaDiscontinuityID, expObjectDiscontinuityIDWildcard
    and expObjectDiscontinuityIDType are only instantiated if
    expObject is not deltaValue. Note that `expObject' does not
    exist. I think you mean expObjectSampleType. Anyway, I would
    prefer if we can avoid holes in the expObjectTable.

27) The only discontinuity types are timeTicks and timeStamp. Note
    that it is possible (and has been done) to use other objects
    (e.g. DateAndTime) as discontinuity indicators.) I think that
    timeStamp actually boils down to the comparison of current with
    the previous value of the discontinuity object. Should
    expObjectDiscontinuityIDType be changes to accomodate that?
    Would it not be helpful to spell out what the check actually
    looks like?

28) I think the security related text in expValueEntry should be more
    explicit. It might be helpful to refer to the isAccessAllowed ASI
    of the SNMP architecture.

29) I am missing a real-world usage example. It would be nice if the
    memo could in the text portion explain how you use this MIB to
    calculate interface loads or something similar. I would also like
    to see an example which explains how to setup access control in
    order to protect things.

30) Are there any protection issues that should be described in the
    security considerations section? For example, it is possible that
    the value table contains information accessible to a user which is
    computed over objects that are usually not accessible by the same
    user. This way, information can leak through, even if it is now
    part of a more complex computed value. (This actually means that
    the VACM access control rules for the expValueTable can depend on
    the access rights associated with the user creating the entry in
    the expression table and the VACM access control rules of the
    objects that are input for the expression.)

							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)