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

Re: snmpconf-pm-04 notes continued




Steve> Sorry I've backburnered your note for too long. Now that I have
Steve> the draft out I've been able to finish my response. Note that a
Steve> lot of the fixed things are in the 05 draft already.

And, identically, sorry for the delay.  My original message was too
long for me to respond to as well, so responding to the response is,
of course, only worse.

I may not get to all the points, unfortunately.  I also find it
humerous that I'm writing this about 3 hours before the meeting.  I'm
sure you'll read it and absorb it all by then, heh heh.

I've skipped over the "done" "ok" and "I'm still thinking on this"
notes.  (though the "I'm still thinking" ones are typically the ones I
find the most interesting).

> 23) The mib is sprinkled with text in the form of comments that
>     describe the table(s) below them.

Steve> The problem with this is that often it inhibits readability for
Steve> those reading the document the regular way. At the beginning of
Steve> a non-trivial table I like to describe why it is there and a
Steve> high-level overview of how it works.

I understand your point, but I'd still argue that those comments
should go in the table's description, since that's what your
describing.

Steve> I think you'll be happy with the results although I didn't do
Steve> the notification table yet pending my getting my act together
Steve> on your comment #22.

It was improved, yes, as I mentioned in another thread (BCP related).

Steve> Another very relevant thing is the rule that states that when
Steve> an element first matches, the action is run immediately.

I'd be tempted to make this statement blatantly clear in the
document.  I should re-read it before making that suggestion though.

>     The odd thing is that these items allow you to configure the row
>     in very odd ways, like the example described above where
> 
>       policyFilterActionMaxLatency > pmPolicyFilterMaxLatency*2
> 
>     which might produce both cases of an action not running for every
>     filter check, and a case where an action may not get run at all
>     (if a filter evaluates to true then false during the second
>     reading).  (I guess 5.3 also states it must be run immediately
>     upon the first discovery of a filter that returns true, but future
>     invocations may not happen).

Steve> The "immediate" clause is key here. Also, note that if it
Steve> disappears and comes back, it will be run immediately the
Steve> second time as well.

Part of the oddity, in my mind, stemmed from the fact the fact that
you could configure it such that the filters could be run with a
higher frequency (>2x) than the results would be used (in actions).
Again, not a "serious" issue.

> ***
> 27) Its still unclear to me when in the API (if ever) you're allowed
>     to reference oids by textual name.  I'm gathering that never is
>     the case for all APIs?  If so, I'd replace the examples (like
>     11.1.2) that reference textual oids with numeric ones (even if you
>     state earlier than some management apps may convert them for you
>     before uploading the code).

Steve> I want the reader to understand what the example is attempting
Steve> to do.  Further, we explicitely suggest that users be given the
Steve> ability to program scripts with descriptors (which are
Steve> translated before script installation). The fact that the
Steve> over-the-wire representation does not incude descriptors is
Steve> VERY explicitely spelled out right after the example.

I didn't find it very explicit in much of the document.  But I may
have missed it.  In short, you're expecting the script compiler to do
the translations, which wasn't clear to me.

> 37) subidwrite() and subid() says their  "int n" argument must
>     start at "0".  I'd suggest replacing the argument instead with
>     "unsigned int n", which solves the problem the correct way (and
>     forces a complier check).  In fact, I think all the function
>     definitions could probably use a once over for this type of
>     checking.  The "int subid" of subidwrite(), for example, is
>     another case where it should probably be an unsigned int (since an
>     oid can't have negative values in it).

Steve> I was trying to say indexing doesn't start at 1, that zero names the
Steve> first element. unsigned doesn't say that.

Yes, but do you understand my reasoning for wanting it to change to
unsigned is that it should never be negative, so unsigned still makes
more senes.

> 41) library accessor functions defines random, but doesn't state a
>     minimum acceptability of random-ness provided by the function.
>     Just a thought.

Steve> It's supposed to use the POSIX standard random() function.

That should be stated, IMHO.

> ***
> 45) You're tables are frequently indexed by arbitrary integer numbers,
>     which is another pet-peeve of mine.  This number has no meaning
>     what so ever and iterating through a table is always required if I
>     need information.  I'd much rather that things be indexed by a
>     string where possible.  For example, the pmPolicyIndex should be
>     "pmPolicyName" instead and be an snmpAdminString (IMHO, of
>     course).  Most of the other tables could use this type of indexing
>     change as well.  I'd be happy to come up with a list if the idea
>     is acceptable.

Steve> My modus operandi is to try to use a "natural" index if it
Steve> exists. In the case of policies, there is no natural
Steve> index. Trying to fake one leads to multiple-manager problems.

My only point was that an integer index, IMHO, is not "natural" to
humans.  It might be more natural to machines, though, so...

It's tables like the new pmSchedTable that, imho, should be referenced
by a name rather than a number.  It makes more sense to a human and
machines don't care that much.

> ***
> 46) If pmPolicyPrecedence values must be unique, then I *highly*
>     recommend making that the index (I know, I'm contradicting what
>     I'm suggesting in #45 above but now the number would have
>     significance).

Steve> They are no longer unique.

I actually think they *should* be unique, personally.  It makes
processing easier.  I'd sort the list by the precedence (note, not the
index, which I think should be the precedence, as mentioned
previously) thus making my process very streamlined.  I wouldn't need
to check for duplicates and I think having it implementation-dependent
is not a wise thing to do.  (but thats another pet-peeve)

(I don't think you were contradicting yourself - I think your pet peeve
is against non-natural (unnatural?) indexes, not against integer
indexes.)

That wasn't that long, actually...  :-)

-- 
Wes Hardaker
NAI Labs
Network Associates