Re: [midcom] MIDCOM MIB design question

[Juergen Quittek <quittek@ccrle.nec.de>]

Tom,

Thanks a lot for your advice!

--On 11.12.2003 12:38 Uhr +0000 Tom Petch wrote:

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

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

> Tom Petch
>
> nwnetworks@dial.pipex.com
>
> -----Original Message-----
> From: Tom Taylor <taylor@nortelnetworks.com>
> To: Juergen Quittek <quittek@ccrle.nec.de>
> Cc: mibs@ops.ietf.org <mibs@ops.ietf.org>; midcom@ietf.org
> <midcom@ietf.org>
> 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