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

From: Randy Presuhn <[email-masked]>
Date: Thu, 21 Jan 1999 20:54:20 -0800 (PST)

Hi - 

A few comments on BobS's proposed disposition of Juergen's
comments on the expression mib draft.

> Date: Thu, 14 Jan 1999 15:59:49 -0500
> To: Juergen Schoenwaelder <[email-masked]>
> From: Bob Stewart <[email-masked]>
> Subject: Re: review of draft-ietf-disman-express-mib-07.txt
> Cc: [email-masked]
> 
> 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.
...
> >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}

I also would like to see an owner in the INDEX clauses for these tables.

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

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

There's probably yet another paper on self-similarity out there
somewhere...  There are some interesting appropaches to sampling where
the sampling interval is not uniform, which are in some ways more robust
than those based on constant intervals.  However, let's crawl before we
try to walk.

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

Do we define "storage-related context" anywhere?
How does one create a volatile storage-related context with
a particular kind of persistance?

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

---

From: Bob Stewart <[email-masked]>
Date: Fri, 22 Jan 1999 10:42:30 -0500

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

>> >    expression MIB.

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

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

	Bob