[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf Capabilities Question
on 09/20/2000 12:58 PM, Frank Strauss at email@example.com wrote:
> Thanks, Jon, for the detailed answer!
> I think, do understand that the capabilities handled by the PM MIB are
> different from what the (broken) AC concept can do. But I'm convinced
> that it's not a good idea to do what the pmCapabilitiesTable does in
> the current way and scope.
> The basic reason for my scepticism: Policy management per se as
> represented by the PM MIB should be independent from domains and
> mechanisms (as defined in the diffserv I-D).
We very much agree. The policy module is at a layer of abstraction above the
mechanism and implementation-specific details. It is independent, that is
why the mechanism specific MIB Modules (or their equivalent objects in other
MIB Modules) must have their capabilities registered into the Policy MIB
Module. The capabilities are far from the details which are below the level
of the Policy MIB Module. To use your DiffServ example, the base OID of the
DiffServ objects is all that would be in the capabilities table.
Enhancements or restrictions would also be registered. This avoids the
problem of the manager having to 'poke' around the entire device for
information such as does this device support DiffServ and what are its
restrictions. The capabilities table is a list of pointers to the details,
not the details.
The manager must know what the 'capabilities' of the system are to
efficiently send policies that are relevant to managed devices. Otherwise
all policies would be sent to all devices, far from efficient. The mechanism
and implementation specifics are dealt with in modules outside of the Policy
MIB Module as in the case with our Policy MIB Module (or its equivalent
objects if integrated into the current DiffServ Module).
> [I'll be on vacation from now on until the end of this month. So I'll
> probably not be able to follow this list during the next days.]
have a good vacation