Subject: Re: comments on expression draft

From: Bob Stewart <[email-masked]>
Date: Fri, 25 Jun 1999 14:30:09 -0400

I'm replying to Juergen's original message in light of an exchange between
him and Randy.

At 12:28 PM 3/25/99 +0100, Juergen Schoenwaelder wrote:
>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.

I tried to give it a ponderectomy.

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

Agreed and fixed.

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

I agreed with a vengence and removed the whole one object expression
ability.  It was there only to try to avoid putting delta values in the
Event MIB.

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

Agreed and fixed.

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

Agreed and fixed.

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

They now belong to .2."me".

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

I changed it to say it's for a half-duplex link.

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

I had trouble understanding this comment, but I think it meant I needed to
make the description of expResourceDeltaMinium more clear.  It wasn't clear
to me what was unclear about it but I tried to clarify it.

>9) Typo in the description of expResourceDeltaWildcardInstanceMaximum: 
>   evalutation

Agreed and fixed.

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

Removed old expExpressionOwner and gave it's name to the former expOwner.

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

And it won't on my watch.  Gryphon says, "WOOOF!"

At Randy's suggestion, I added a section on persistance in the introductory
prose.

This is an overall problem area that you SNMP guys really need to get
sorted out.

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

Agreed and fixed.

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

Agreed and fixed.  (You really read this thing carefully.)

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

The discussion between Juergen and Randy on this one convinced me to change
it so that access control for the objects that make up all expressions is
based on the recorded security credentials of the expression creator.
There is no longer a difference between absolute and delta or changed.

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

Agreed (modulo my concession on the general point) and fixed.

>17) There is an asymmetry between the event MIB and the expression MIB
>    wrt to contexts.

I agree with Randy that this is an area where the community needs more
understanding based on experience and there's nothing clear to change now.

As painful as it is to keep editing these documents, I do appreciate a
review that obviously took considerable time to do.

	Bob