Subject: Re: Disman WG last call: expression MIB

From: Randy Presuhn <[email-masked]>
Date: Thu, 25 Mar 1999 15:27:39 -0800 (PST)

Hi -

> Date: Wed, 10 Mar 1999 16:30:12 -0800 (PST)
> From: Randy Presuhn <rpresuhn>
> To: [email-masked]
> Subject: Disman WG last call: expression MIB
...
> I have seen no comments since the editor posted the updated
> <draft-ietf-disman-express-mib-08.txt>, so let's start a
> two-week WG last call, expiring at 1999-03-25 01:00:00 UTC
> (5 pm pacific time on March 24).
...

The disman chair says:

During the working group last call on this document, I've seen one
question regarding built-in min/max/avg functions, and a list of seventeen
issues (thanks Juergen!).  There have been no requests for additional
time for review.  In order to finish the WG last call, we need to come
to some resolution on these issues, even if the resolution may be to
not deal with a particular issue.

As technical contributor, here are my comments on the 17 issues:

> Date: Thu, 25 Mar 1999 12:28:02 +0100
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked]
> Subject: comments on expression draft
...
> 1) It might be helpful to break the second sentence in the section
                                              paragraph?
>    "Overview" (which is also identical to the second paragraph itself)
>    into smaller pieces.

The paragraph's ponderous prose was not easy to parse.

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

I agree.

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

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

Either "the" or "an" would work for me;  "the" is probably a little
better.

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

I agree.

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

I'd like it even better with a string, but the ".0" would at least
make the example correct.

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

Would a health warning be sufficient?

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

Agreed.

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

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

The IF-MIB OwnerString isn't UTF-8 anyway, so it should go.
If we keep the expExpressionOwner, then, since it's presumably
human-readable, it had better support UTF-8.

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

At a minimum, we should be absolutely clear on what the expectations
are for persistance.  If I were implementing, I'd probably do an
enterprise MIB augmenting  expExpressionTable.

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

yup.

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

yup.

> 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 text talks about "managed system", not manager.  I'm missing
something here...

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

Agreed.  Hierarchical naming is not needed to provide security.

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

To me this sounds more like an item for discussion rather than a request
for a specific change at this time.  It seems to me like this is an area
where we should get some implementation feedback from both the manager
and agent worlds.  So, I suggest we leave this as it is, but revisit
and resolve this question before it comes time to consider advancement
from proposed to draft, recycling the document at proposed if we find
that a change is needed here.

 -----------------------------------------------------------------------
 Randy Presuhn           [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
 -----------------------------------------------------------------------
 Any relationship between my opinions and BMC's is coincidental.
 -----------------------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Mar 1999 13:16:00 +0200

>>>>> Randy Presuhn writes:

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

Randy> The text talks about "managed system", not manager.  I'm
Randy> missing something here...

Here is the text in the third paragraph of the description of
expValueEntry:

:    To maintain security of MIB information, when creating a new
:    row in this table, the managed system must record the security
:    credentials of the requester.  These security credentials are
:    the parameters necessary as inputs to isAccessAllowed from [1].
:    When obtaining the objects that make up the expression, the
:    system must (conceptually) use isAccessAllowed to ensure that
:    it does not violate security.

Entries in the expValueTable are created by the expression MIB
implementation itself. I do not understand why you want to record any
"security credentials of the requester" in this case. I think the
description of expValueEntry wants to say the following:

1) In case of 'deltaValue' and 'changedValue', the evaluation of the
   expression takes place under the security credentials of the
   creator of the associated expExpressionEntry. These security
   credentials are recorded when the expExpressionEntry is created.

2) In case of 'absoluteValue', the evaluation of the expression takes
   place under the security credentials associated with the message
   which contains the read operation to the ExpValueTable.

I had the impression that the current text in the description is not
to the point and potentially misleading. Note, the text describing the
two cases above is also not 100 % clear since you can have mixed
expressions which include 'absoluteValue' and 'deltaValue' objects.
In the case of a mixed expression, is the whole expression evaluated
under the recorded security credentials? Or are parts evaluated under
the recorded security credentials while other parts are evaluated
under the security credentials of the read request?

[The key here is that 'deltaValue' and 'changedValue' implement a
`setuid model' where a user X installs an expression and users Y and Z
may be able to obtain the results of the expression evaluation. This
is pretty different from 'absoluteValue' where the credentials
associated with Y and Z determine whether they are able to evaluate
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)