[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [midcom] MIDCOM MIB design question

I know you can use views to separate out what one user sees vs. another, but I figured separation by module was cleaner. Juergen is talking about separating what the administrator is interested in from what the MIDCOM agent is interested in. Agreed that they both address the same underlying data structures, but I would think security setup would be simpler if you could specify access by module rather than having to do it object by object.

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.
Objects that "serve management purposes" means nothing to me. It depends
on the manager.

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.

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? 

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.

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

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.

dbh


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