On Wed, Dec 10, 2003 at 06:53:49PM +0100, Juergen Quittek wrote:
[...]
Usually, this problem does not occur, because most control protocol,
say GSMP are not defined on top of SNMP. Therefore in GSMP there is
a clear separation between the protocol and the MIB with objects serving
network management purposes. But in our case, SNMP is used for both
purposes.
What puzzles me is the notion of the "MIDCOM protocol" in the context
of SNMP. I have read the MIDCOM semantics document and I think I do have
some understanding what the _services_ are that MIDCOM wants to define.
But by using SNMP, you will probably realize these abstract services
defined in the semantics documents via a bunch of MIB tables that
can be tweaked to create holes and so on. So from this MIB perspective,
I fail to see why there is a certain MIBCOM protocol - there are just
MIDCOM MIB objects which allow you to achieve the services described in
the MIDCOM semantics objects. Let me know if I am completely on the
wrong track and I have to read the document (which one?).
Regading the question how to split things into modules:
1) There are absolutely no implications concerning access control.
2) Different implementation requirements should be expressed by
compliance statements.
3) MIB objects generally try to offer functionality without saying
or prescribing how the functionality is used. Sometimes this
causes problems because developers have a hard time to figure
out how to use the objects to achieve a certain goal. On the
other hand, trying to be neutral wrt. the expected usage
allows for flexibility. So I think a good approach is to just
define objects that offer a certain functionality in the MIB
and to augment that with a textual description how the objects
are typically used to solve certain problems.
4) I strongly recommend to keep things simple (you are done if there
is nothing left which can be removed). However, some MIBs just
require a certain complexity and trying to hide that by having
multiple MIB modules does not help.
5) As we all know, there are some implications imposed by the IETF
standardization process. Personally, I recommend to not worry too
much about this while working on a Proposed Standard. If you
later run into debates because someone want to advance while
others want to add/change stuff, you are in the very fortunate
situation that your document has been implemented and is being
used.
<soap>
Perhaps this is an issue totally ignored in the IETF problem
discussions: The IETF rewards success with pain. The more
pain you feel, the more successful you likely are. ;-)
</soap>
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany