Re: 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        [email protected]        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