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

Re: [midcom] MIDCOM MIB design question

Juergen,

Thank you very much for this guidance.  I think it answers the open
question and we know now how to structure the first version of the
MIDCOM MIB.

--On 12.12.2003 10:44 Uhr +0100 Juergen Schoenwaelder wrote:

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?).

Basically, it is the midcom charter.

The midcom WG is chartered to select an existing standard protocol and
use it "as the basis for the development of a middlebox communication
protocol."  This term magically turned from 'odd' to 'puzzling' when it
entered the SNMP community.  I hope we do not have to change the charter
after selecting SNMP ;-)

   Juergen Q.
--
Juergen Quittek        quittek@ccrle.nec.de        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de


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