RE: MIDCOM MIB design question

Hi David,

--On 10.12.2003 21:24 Uhr -0500 Harrington, David wrote:

> Hi Juergen,
>
> SNMP is a protocol that manipulates sets of data on remote devices. The
> set of data is typically used by many users. You separate mib data sets
> by the functionality they contain, not by which "user" will use it.
>
> It would be really helpful if you were more explicit about the
> requirements and the separate objects you think are needed in each mib.

Martin Stiemerling and I sent you a description of the requirements in November,
but you did not reply.  That's why I asked on  the mibs mailing list.

> Objects that "serve management purposes" means nothing to me. It depends
> on the manager.

Are you happier with "may be useful for fault, configuration,
accounting, performance and/or security management"?

I used the generic term not to describe exactly the functionality
provided by this particular group of objects, but to separate this
group from the other one containing managed objects that primarily
serve for implementing the MIDCOM protocol which signals application
layer requests to a middlebox and IMHO does NOT "serve management
purposes".

> I might have one network manager or application whose job is to monitor
> performance, and he/it might use ifInOctets in its calculations. I might
> have a second application whose job is to isolate faulty interfaces, and
> it might use ifInOctets. I might have an intruder detection system that
> watches for anomalies and it might use ifInOctets. I wouldn't want three
> duplicate ifInOctet objects to rpvoide this information just because I
> happen to have three different managers/users looking at the datum for
> different purposes.

As I said in the original message below, we aready identified separate
groups of objects.  We do not have the intention to duplicate any object.
Just Martin and I found that we could idenitify a group of objects (the one
implementing the MIDCOM protocol semantics) that is relevant to applications
that want to use the MIDCOM protocol for signaling their application layer
communication requests.  These applications are no network management
applications, i.e. applications "serving network management purposes".

> You did list three things as management:
> 1)  the priority with which requested pinholes are configured in the
> firewall,
> 2) a table showing the mapping of MIDCOM pinholes to firewall resources
> or of MIDCOM NAT sessions/bindings to NAT resources,
> 3) a protocol statistics table listing the set of active MIDCOM
> sessions, protocol errors, etc.
>
> I'm not quite sure what type of priority you are referring to in 1).
> Priority relative to what? To other pinholes? To other firewall rules?
> To other MIDCOM rules within a group? To other MIDCOM groups? The
> priority of the operator performing the opeation? The priority of the
> operation versus other tasks the device needs to perform?

Sorry for not explaining it in sufficient detail.  This is a request from
Wes Hardaker which we discussed at the last MIDCOM MIB design team meeting
in Minneapolis.  Yes, the requirement is to set the priority of firewall
rules requested via the MIDCOM protocol with respect to all other firewall
rules entered by the administrator or a NMS.  Firewall process rules in an
order defined by the rule priority. The administrator certainly wants to be
able to configure the priority of rules resulting from MIDCOM protocol
operation such that he/she is still able to insert rules of higher priority.

> The MIDCOM MIB manipulates the mappings of MIDCOM pinholes to resources,
> so the map available to monitor this mapping belongs in the same mib, in
> my opinion. You don't need to duplicate the information just so another
> user can read it.

As I said, there is no intention to duplicate anything.
The point is that the MIDCOM protocol operates on a more abstract level
where most concrete mappings are irrelevant to the application using the
MIDCOM protocol.  For network management applications, the ones that serve
management purposes, it might be relevant to identify, which MIDCOM policy
affects which resource, for example an application monitoring resource
usage on middleboxes.  But this is of no interest to the applications using
the MIDCOM protocol.

> Statistics are about the MIDCOM sessions and whatnot being configured in
> this mib. You don't need to separate which mib this is in.

Yes, statistics are rarely writeable.

But statistics on open MIDCOM sessions does not belong to the information
that should be available to an application using the MIDCOM protocol.  It
should be accessible only to application that are authorized to monitor
the entire protocol engine.

Just compare it to TCP:
Not every user of the TCP protocol should be allowed to access objects in
the the TCP-MIB module.

> It is generally better to keep the status related to a functionality in
> the same mib as the configuration of the functionality. Statistics are
> part of status, and so are the configuration settings.

Yes, I fully agree.  But all objects serving configuration purposes are
in the group that I labeled "serving management purposes".  There is no
configuration object in the group of objects serving the MIDCOM protocol.

Thanks for your detailed comments,

    Juergen

> dbh
>
>> -----Original Message-----
>> From: Tom Taylor [mailto:[email protected]]
>> Sent: Wednesday, December 10, 2003 1:13 PM
>> To: Juergen Quittek
>> Cc: [email protected]; [email protected]
>> 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 protected]
>> https://www1.ietf.org/mailman/listinfo/midcom
>>