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

From: Bob Stewart <[email-masked]>
Date: Thu, 14 Jan 1999 15:59:49 -0500

At 02:11 PM 11/9/98 +0100, Juergen Schoenwaelder wrote:
>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.)

I'm working on draft 8 and applying the comments.

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

I added more details.

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

Done.

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

Done with a bit different wording.

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

Changed the terminology to "meaningless" and added a bit more explanation.

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

Done.

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

Done.

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

It was already explained in the DESCRIPTION for expValueInstance but I
repeated it redundantly in a new section in the beginning.

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

Result added.

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

Done, referencing isAccessAllowed.

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

I did that in the Notification Log MIB because I wanted to use a
zero-length name to mean something special and couldn't use IMPLIED.

I'm sympathetic to your concern but I hate to give up the ability easily to
GetNext just the part of the name table for the prefix you like.

Hmmmm.  Tradeoff.  OK.  You win on this one.  You owe me one.

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

I'll take that one you owe me.  :-P}

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

Just having a bound so friendly implementations know when they've been
friendly enough.  Would it be better with a different bound or no bound?  I
don't think so, so I didn't change it.

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

Somebody's going to have to tell me the right one.  This is down to a level
of (admittedly probably necessary) hair splitting that's beyond me.  There
are so many standards you need an expert to tell you which one to choose.

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

OID *fragments* with one subidentifier make perfectly good sense.  The
intention is, for example, to be able to see if a substring of an OID
matches something you care about.

I added text to say nothing is added on the beginning or end.

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

The missing word is "parameter."

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

Carrying internationalization to the point where it makes the number harder
to read is counter-productive.  Anyone who can't figure out what it means
isn't smart enough to implement it anyway.

>17) Typo: availiable

Fixed.

>18) Change unsignedOrGauge32 to unsigned32 in expExpressionValueType.

Fixed.

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

Done.  (You won that one, too, but you don't owe me.  Much.)

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

I'm far from expert on this and put what's there in due to concerns from
others.  I'll add that a beginning point is for the underlying sample to be
at least twice as often as the one above it.  Does anyone out there have a
better suggestion?

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

Yeah, that does sound rather cleaner.  It makes the main table look
smaller.  As a general rule I try to avoid "don't care" values, as they
clutter up a GetBulk.  Rearranged.

>22) Typo in expExpressionError: evalutaion

Fixed.

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

I figure a good compromise is to change one and leave the other.

No?

OK.  I changed this one, too.

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

Nope.  They and everything else should be viewed in the appropriate,
storage-related context.

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

OK.

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

This one didn't seem worth creating a separate table and as I said I don't
like uninteresting values.  The trend in newer MIBs is not to instantiate
irrelevant objects.  I'm going to stick with that trend.

I did fix 'expObject' and make the statement more clear (no double
negative) and apply it to 'changedValue' as well.

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

I added 'dateAndTime'.  As to the comparison algorithm I agree it should be
documented, but not in any individual MIB.  It should be written down once
for all MIBs and all discontinuities.

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

Done.

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

OK for the real example.  I'll consider how that relates to the contrived
example and if both are necessary.

The access control setup is a bit different story.  It's the same sort of
setup you'd use for the SNMPv3 MIBs, so again I believe that should be
documented separately and centrally.

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

It is indeed possible for someone with access to the raw objects to create
values that are then accessible to someone who wouldn't have been able to
get those.  That may or may not be intentional.

I'll take a swing at that in the security section.

Thanks for the comments.

	Bob

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 22 Jan 1999 11:51:56 -0800 (PST)

Hi - 

(Working group input sought near the very end of this message!)

> Date: Fri, 22 Jan 1999 10:42:30 -0500
> To: [email-masked]
> From: Bob Stewart <[email-masked]>
> Subject: Re: review of draft-ietf-disman-express-mib-07.txt
> 
> At 08:54 PM 1/21/99 -0800, Randy Presuhn wrote:
> >A few comments on BobS's proposed disposition of Juergen's
> >comments on the expression mib draft.
> 
> I peeked ahead.  We're down to the really sticky, global issues.
> 
> >I also would like to see an owner in the INDEX clauses for these tables.
> 
> Definitely a global issue.  I strongly object to putting an owner in the
> index clause.  I'm convinced we're taking an expensive cheap shot at a
> bigger problem and side-stepping the implications of the v3 security work.
> 
> Reasonable security mechanisms in SNMP should not require such intrusive
> structures in MIBs.
> 
> If such changes are necessary, either because SNMP security is less than
> reasonable or because reasonable security really is that intrusive, we
> should have one central, agreed, reviewed, published, standardized
> explanation of what has to be done and when to do it.
> 
> I had hoped that would be in the DisMan framework but that fell through.
> Anyway, it should be an SNMPv3 document, not a DisMan document.
> 
> Without that document we're left to what ever more limited means we have to
> make decisions.
> 
> My technical judgement says to stick with named entries, as we did in the
> v3 MIBs, and not go down the path of adding complexity to some or all MIBs
> to make up for what some people believe are inadequacies in SNMPv3.
> 
> If Randy tells me as working group chair that the document can not go
> forward without owner indexing, as editor rather than primary MIB designer
> I will put it in under protest in the interest of getting the work done.

Based on the discussion at the WG meeting in Orlando, the discussion on
the mailing list, and words from our AD, I, as working group chair,
hereby instruct the document editor to put in the indexes.

(And I didn't even need to invoke the flying monkeys.)

> >> >    expression MIB.
> Unless I get a recommendation that receives no serious objections I have no
> choice but to do nothing about this.

Here's information I got from ISO's web site, http://www.iso.ch/
(specifically from http://www.iso.ch/cate/d17782.html#0)

|ISO/IEC 9899:1990
|Programming languages -- C 
...
|Technical Corrigendum 1:1994 to ISO/IEC 9899:1990
|Technical Corrigendum 2:1996 to ISO/IEC 9899:1990
|Amendment 1:1995 to ISO/IEC 9899:1990
|C Integrity 

> >...
> >Do we define "storage-related context" anywhere?
> >How does one create a volatile storage-related context with
> >a particular kind of persistance?
> 
> See previous discussion and replace references to security with references
> to the persistence of information.
> 
> My attitude about StorageType has encrusted similarly to my attitude about
> owner indexing.  We're avoiding a real solution and cluttering MIBs with
> kludges.
...

This issue did not get the same kind of discussion in Orlando as
owner indexes did.  As I see it, we've been presented with two
choices:
    1) storage type, the officially blessed approach as in RFC 1903,
       extensively discussed on the snmpv3 and smi mailing lists.
    2) "storage-related context", which sounds suspiciously like
       an SNMPv2p "time domain", which was abandoned with SNMPv2p.

I have not heard any consensus to deviate from the approach suggested by
RFC 1903; if anything the discussions on the snmpv3 list suggest that it
is indeed workable.  I'd like to hear from others in the working group;
the strawman position I'd start from is to use the StorageType TC for
handling persistance of configuration information.

 -----------------------------------------------------------------------
 Randy Presuhn           Email: [email-masked]     http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy, I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 -----------------------------------------------------------------------