Re: MIDCOM MIB design question

I agree with Dave that it is mostly the non-technical aspects, the
administration, that should colour your choice, the likely future
evolution, the need for revision, conformance, ownership by working
groups/IANA/ID editors and such like.  A MIB module is a useful chunk of
definition to be administered as one item.

Technically, once it is in an agent, then you just have the one tree of
objects and how many modules the tree came from is irrelevant.

But I suggest you consider the tree structure carefully.  Several aspects
of SNMP revolve around the tree structure and it is much easier to define
eg midcom.4 as available to all and midcom.5 as restricted to
administrators, as opposed to having to define eg midcom.4 as available to
all except for midcom.4.2, midcom.4.4.1 and the table entries of midcom.4.5
with entries starting with x... except on weekends and Bank Holidays :-)

ie group your objects in the tree structure so that whole branches have the
same pattern of access, use, security etc.  This can be achieved - or not -
with one or 100 modules..

Tom Petch

[email protected]

-----Original Message-----
From: Tom Taylor <[email protected]>
To: Juergen Quittek <[email protected]>
Cc: [email protected] <[email protected]>; [email protected]
<[email protected]>
Date: 11 December 2003 10:46
Subject: Re: [midcom] MIDCOM MIB design question


>I'd say they should be in separate modules because they are likely to be
>implemented on separate boxes on the SNMP client side.
>
>Juergen Quittek wrote:
>
>> Dear all,
>>
>> In the MIDCOM working group we are developing a protocol for dynamically
>> requesting pinholes in firewalls and bindings/sessions on NATs.
>>
>> The working group decided to use SNMP as basic protocol and now we are
>> defining a MIDCOM MIB module.  While doing this, we found that we are
>> defining two separate groups of objects:  Objects implementing the
MIDCOM
>> protocol (for which we already have a protocol semantics document, see
>> draft-ietf-midcom-semantics-06.txt) and objects serving management
>> purposes.
>> Management purposes include for example configurations, such as
>>  - the priority with which requested pinholes are configured in the
>> firewall,
>>  - a table showing the mapping of MIDCOM pinholes to firewall resources
>>    or of MIDCOM NAT sessions/bindings to NAT resources
>>  - a protocol statistics table listing the set of active MIDCOM
sessions,
>>    protocol errors, etc.
>>
>> For these two groups of objects there are also two separate groups of
>> users:
>>  - middlebox controllers sending requests for dynamic pinholes and NAT
>>    sessions/bindings
>>  - network managers configuring the middlebox (firewall or NAT) and
>>    monitoring its operation
>>
>> The middlebox controllers only need access to the objects implementing
>> the MIDCOM protocol.
>>
>> The network managers would rather use the objects serving management
>> purposes
>> although in some cases they might need to access the other group also.
>>
>> Now, we have a draft defining these objects and the following question:
>>
>> Does someone have an opinion about whether these two groups of objects
>> should be contained in a single MIB module or in two separate ones?
>>
>> 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.
>>
>> Thanks,
>>
>>   Juergen
>
>