Subject: Re: snmpconf RE: snmpconf New draft of the Policy Management MIB

From: Steve Waldbusser <[email-masked]>
Date: Mon, 06 Nov 2000 23:44:25 -0800

Mike,

   Excellent feedback! Thank You!

  Out of the many many coments, I am only responding to the several that require
feedback.

Ayers, Mike wrote:

> {8.1.1.3.  exists()}
>
>         9.)  This function and many following return 1 for success and 0 for
> failure, the reverse of the C convention.

It's not success or failure, it's true or false. exists() needs no failure
return code.

> {8.2.  Constants}
>
>         13.)  The SNMP error constants are not given their usual values.
> Since they will not appear in an ASN.1 type field, this makes no sense.  Is
> there a reason for this?

Yes, they will appear in an ASN.1 type field. I didn't finish that text yet.

> {8.3.4.  setScratchpad()}
>
>          15.)  Note that if one uses scratchpads during, say, iteration of
> rows in a table, it may be impossible to use the scratchpad elsewhere, since
> no row (and therefore translated scratchpad varIndex) may be guaranteed to
> be unused.

This will be changed to index scratchpad variables by strings. The main
motivation is to make the code more readable, but it will also increase the
"range" of the indexing.

Note that the design intent of the scratchpad is that scripts will typically
store just several variables between invocations (many scripts won't use the
scratchpad at all). But I still consider this a legitimate issue because the
namespace size could still be an issue if say I was selecting 1 row from 1 table
and 1 row from another table - they could conflict.

> {8.4.4.  oidsplice()}
>
>         16.)  The starting point of the splice is not specified for oid2.

It starts from the beginning. oid2 in it's entirety is spliced into oid1. It's
intended to be used commonly for replacing index variables. I'll try to make
this more clear.

> {pmElementTypeRegTable}
>
>         18.)  Wouldn't it be better to index this table via
> pmElementTypeRegOIDPrefix and eliminate pmElementTypeRegIndex?

I hate OIDs as indexes (I think most right-thinking people do :-). They are
complex and long and the integer index is a small price to pay.  (another minor
point: I don't think common mgt tools will be smart enough to decode the OID at
the end of the OID and pretty print it as a descriptor).

>  {pmTrackingPolicyToElementTable} & {pmTrackingElementToPolicyTable}
>
>         23.)  After reading these sections three times, I am still baffled.
> Questions include:
>
>         -  Why are there two tables?

One is an efficient way to find all elements that a certain policy has matched.
Another is an efficient way to find all policies that are acting on a certain
element.

>         -  Why the special objects for row status?  Won't a rowStatus work?

Well RowStatus is designed as a mutex mechanism for creating rows in tables.
These tables don't support row creation by SNMP requests so that is the wrong
tool for this job.

>         -  Why does pmTrackingElementToPolicyEntry vanish when the
> corresponding pmPolicyFilter fails?

So that we don't have to wade through this table to find the many things that
didn't match.

> {pmConformance}
>
>         25.)  This is instantiated as policyMgt.20, leaving 11 unused
> objects between it and pmDebuggingTable.  Is there any reason for this?

Just cutting down my bookkeeping work while the MIB is under development. This
way I don't have to renumber this subtree every time I add a table.

Steve