[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
snmpconf thoughts on the pm document (fwd)
Steve referenced this mail in his list of to-do items. In the
interest of everyone knowing what he meant, since I sent it to
him and Jon directly, I'm forwarding the mail to the list.
Note that not all of this mail is relevant any more, and many of
the items are on the list, but it's better to get the
unadulterated truth than filtered.
Just some random thoughts I've collected. I've just gone through
- I think the "Element Discovery" section would be well served
by some concrete examples of elements (both tables
and scalars) and how they are exposed via the
pmElementTypeRegTable. Although I know it's a forward
reference, something like:
pmElementTypeRegOIDPrefix.1 = blah
pmElementTypeRegMaxLatency.1 = blah
pmElementTypeRegName.1 = blah
pmElementTypeRegOIDPrefix.2 = blah
pmElementTypeRegMaxLatency.2 = blah
pmElementTypeRegName.2 = blah
pmElementTypeRegOIDPrefix.3 = blah
pmElementTypeRegMaxLatency.3 = blah
pmElementTypeRegName.3 = blah
would be very helpful.
- the "Operators" section would do equally well with a set of
- the "PolicyScript QuickStart Guide" includes several "forward
references" that are important to the understanding of things.
For example, iv(0), newPDU(), and so on. Would it be better
to move this later in the document after these concepts have
- definition of searchcolumn(): "If the `case` argument is 0,
the search will be case insensitive, otherwise it will be
case sensitive." is, I believe, supposed to be, "If the 'mode'
argument is 1, 3, or 5, the search will be case insensitive,
otherwise it will be case sensitive." or am I missing
something? There is no 'case' argument.
- should searchcolumn()'s definition try to stop people from
doing stupid stuff?
oid = "";
searchcolumn("1.3.6", oid, "hooglebarth", 2 /* case ins. substring */);
is evil. That is, perhaps the definition should make it clear
that this is evil. Or do we just say, "with freedom comes
- I think the example and definition of counter32Delta should be
- in the description of general snmp functions, the terms
varbindlist and PDU are used interchangeably. i don't think
that's correct. we're actually talking about vblists,
so we should call them that. i'd actually call newPDU()
newVBList() (that'll make Microsoft happy 'cause they'll
think we mean visual basic :-)) but won't get too worked
up about it...
- capMatch: "Argument 'capability'" -> "Argument 'capOid'"
- getParameters(): examples would be good.
- regexp(): i don't really understand what's supposed to be in
"match". It says, "the text of the first match will be copied
to 'match'". Does that mean that 'str' will be in 'match' or
that a substring out of 'str' will be in 'match'?
- oidsplice() is begging for an example.
- parseindex() is equally begging for examples, including tables
with multiple indices, with variable-length and fixed-length
- Actually, all of the accessor functions need examples. Shall
I write them?
- Do we _have_ to have our own UTF8String TC? Let's put it
in a separate document called
draft-ietf-snmpconf-utf8tc-00.txt and try to harmonize it
with others and get a single definition...
- pmPolicyAdminStatus: "The policy will be runnable only
if the associated pmPolicyRowStatus is set to active(1)
or activeAutoRemove(2) and this object is set to active(1)."
is mucked up. pmPolicyRowStatus cannot possibly be
- Can we whack the IMPLIED in pmRoleEntry? IMPLIED is, in my
opinion, far more trouble than it's worth (after having taught
about it a number of times). Saving 1 byte ain't worth it.
Let the manager deal with the fred/barney problem.
- pmRoleElement: why a RowPointer when all other cases like
this were handled with shared integer values? The DESCRIPTION
needs to say what this may point at and give examples.
- pmDebuggingElement: this should also say where the rowpointer
- Indices to pmRoleTable might be very long and exceed 128
subidentifiers. It will look like this:
It's not hard to see that this could easily break the 128
The same is actually possible for pmTrackingPolicyToElementEntry,
pmTrackingElementToPolicyEntry, and pmDebuggingEntry, but
pmRoleTable is the "worst case scenario", I think.
With kind regards,
David Partain David.Partain@ericsson.com
Ericsson Radio Systems AB Tel: +46 13 28 41 44
Research and Innovation Fax: +46 13 28 75 67
P.O. Box 1248 http://linlab.ericsson.se/~epkpart
SE-581 12 Linköping, Sweden