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

Re: [midcom] MIDCOM MIB design question



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