Subject: Re: [midcom] MIDCOM MIB design question

From: "Tom Petch" <[email-masked]>
Date: Thu, 11 Dec 2003 12:38:35 -0000

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-masked]

-----Original Message-----
From: Tom Taylor <[email-masked]>
To: Juergen Quittek <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
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
>
>

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 11 Dec 2003 18:21:47 +0100

Tom,

Thanks a lot for your advice!

> with one or 100 modules..

We tried to follow this rule and group our objects well (while also reducing
the number of objects).

After doing so we found a portion of objects in one subtree that was
completely optional with respect to our main goal (implementing the MIDCOM
protocol over SNMP) and that would be of relevance rather to one or the
other network management application than to the users of the MIDCOM
protocol.  Also there were very few dependencies.  Three index objects are
shared.

Therefore, we started thinking about separating this portion.
But considering the response we got so far, this does not seem
to be the right idea.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]        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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Dec 2003 11:20:30 -0800

Hi -

> From: "Juergen Quittek" <[email-masked]>
> To: "Tom Petch" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, December 11, 2003 9:21 AM

...
> protocol.  Also there were very few dependencies.  Three index objects are
...

I agree that this is sufficient reason to think seriously about splitting
it into two modules.  A deciding factor for me would be whether
the implementation of the MIDCOM protocol is at all likely to be a
separate software component.  If it is, then separate modules,
even if published in the same RFC, would be a distinct aid to
developer sanity.

Randy