[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
> 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),