Dave Shield wrote:
> It's certainly unacceptable to define MIBs within an enterprise subtree
> administered by someone else. But that's not what's being suggested
> here.
>
> Cisco have defined a MIB "...to describe and store the system
> messages generated by the IOS and any other
> OS which supports syslogs."
>
> If this MIB matches the requirements of another organisation,
> I don't personally see a problem with implementing that particular
> MIB - either in terms of the management objects for GET/SET
> requests, or the notifications defined within it.
>
> Andre would have to abide by the specification outlined by the
> MIB, of course - he couldn't amend the semantics of the trap
> (or any other object) without re-naming things to use different
> OIDs. But if the agent reports syslog information using this
> particular trap, with the correct contents - does it really matter
> whether the originating box has the appropriate label on it or not?
Adhering to Cisco's trap definition would be within the bounds of
reason. From the perspective of a Netview maintainer, it's not a
particularly useful trap, since it doesn't include the originator as an
OID and it may have been forwarded.
However, since it is Cisco's MIB, they are able to modify, deprecate and
drop the trap.
Using an RFC defined trap, or an enterprise specific trap is safer.
However, MIBs in draft RFCs tend to be a nuisance. The OIDs often change
when they become standardised, and so you wind up with early adopters
using the draft OIDs and later adopters the standardised OIDs.
--
There's no point in being grown up if you can't be childish sometimes.
-- Dr. Who
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
