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

Re: BCP and Notifications (was: snmpconf FW: MIBs for events and notification logging)

At 08:32 AM 10/31/2001 -0800, David T. Perkins wrote:

Hi--I'm redirecting this from the disman list to the snmpconf list, but 
keeping the cc'ed implicated parties from disman for continuity. :)

>But, the BCP draft that I previous reviewed had MANY problems
>with respect to using INFORMs. T

Hey David...wanted to give you an accurate heads up on how we've resolved 
this, so if you think this misses the point, you can generate discussion.

>The keys one are:
>    1) it specified incorrectly that MIB designers could indicate
>       that a notification MUST be sent using an INFORM operation.
>       This is just plain incorrect.

We sure didn't mean to imply that.  I recall how we've revised that 
section, it sure had eradicated any such insinuation--although the idea of 
using INFORMs as a superior preference to completely unacknowleged 
notifications (it is generally a matter of agent configuration, after all) 
is highly recommended.  In addition, we included an exhaustive discussion 
of the administrative issues with setting up INFORMs, and what the heck 
they are as opposed to unacknowledged traps in the first place (as 
background material, the likes of which I noticed you called for early and 
often :).

>    2) it incorrectly described INFORMs as "reliable". Again
>       this is just plain incorrect.

We softened that to indicate the shortcomings, but let's face it, they're 
the most reliable current practice in town for notifications.  In essence, 
they're only as reliable as the administrative structure that surrounds 
their implementation and control in the software, right?  Your comments 
mentioned these foreboding issues with INFORMs and seemed to insinuate 
these preferable current practices, but we really didn't know what you had 
in mind. :)  If that read is correct, would you mind expanding on that to 
the list or to us author-types privately?

The only one I came up with *is* the usage of the notification MIB, whose 
applicability seems to be more focused and whose current implementation 
state would probably stretch the meaning of the words "current practice" 
imho.  Would you agree?

I suppose there's also custom notification capabilities and exchange 
mechanisms "baked" into a lot of private MIBs--if you see enough of a 
design pattern here to merit mention, feel free to pass us along some 
pointers to examples we can consider for extracting.

>The BCP had a section covering the issue of synchronization of
>configuration, which had parts that were incorrect, incomplete,
>and not too usable. I hope that these technical problems are
>fixed in the next draft.

At the end of the day, we agreed with an observation of yours that the word 
"synchronization" was often misapplied.  To the extent it wasn't, we needed 
to expand what the discussion pertained to.  And we have.  :) Exact 
techniques to address this in the BCP are beyond the scope of this message, 
but I hope you agree when you see the next version of the draft, and will 
work with us to discuss and triage any remaining issues if you don't agree.

Regards (and thanks),