[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

snmpconf thoughts on the pm document (fwd)



Greetings,

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.

Cheers,

dlp



Hi again,

Just some random thoughts I've collected.  I've just gone through
things quickly.

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

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

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

 - I think the example and definition of counter32Delta should be
   switched.

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

 - 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
   activeAutoRemove(2).

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

 - Indices to pmRoleTable might be very long and exceed 128
   subidentifiers. It will look like this:

   pmRoleContextName.RowPointer.UTF8String.SnmpAdminString.pmRoleTDomain.pmRoleTAddress

   It's not hard to see that this could easily break the 128
   subid rule.

   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