Subject: [midcom] MIDCOM MIB design question

From: Juergen Quittek <[email-masked]>
Date: Wed, 10 Dec 2003 18:53:49 +0100

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

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

---

From: Tom Taylor <[email-masked]>
Date: Wed, 10 Dec 2003 13:12:40 -0500

I'd say they should be in separate modules because they are likely to be 
implemented on separate boxes on the SNMP client side.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Dec 2003 10:44:48 +0100

On Wed, Dec 10, 2003 at 06:53:49PM +0100, Juergen Quittek wrote:

[...]

> network management purposes.  But in our case, SNMP is used for both

What puzzles me is the notion of the "MIDCOM protocol" in the context 
of SNMP. I have read the MIDCOM semantics document and I think I do have
some understanding what the _services_ are that MIDCOM wants to define.
But by using SNMP, you will probably realize these abstract services 
defined in the semantics documents via a bunch of MIB tables that
can be tweaked to create holes and so on. So from this MIB perspective,
I fail to see why there is a certain MIBCOM protocol - there are just
MIDCOM MIB objects which allow you to achieve the services described in
the MIDCOM semantics objects. Let me know if I am completely on the
wrong track and I have to read the document (which one?).

Regading the question how to split things into modules:

1) There are absolutely no implications concerning access control.

2) Different implementation requirements should be expressed by
   compliance statements.

3) MIB objects generally try to offer functionality without saying
   or prescribing how the functionality is used. Sometimes this
   causes problems because developers have a hard time to figure 
   out how to use the objects to achieve a certain goal.  On the 
   other hand, trying to be neutral wrt. the expected usage
   allows for flexibility. So I think a good approach is to just
   define objects that offer a certain functionality in the MIB
   and to augment that with a textual description how the objects
   are typically used to solve certain problems.

4) I strongly recommend to keep things simple (you are done if there
   is nothing left which can be removed). However, some MIBs just 
   require a certain complexity and trying to hide that by having 
   multiple MIB modules does not help.

5) As we all know, there are some implications imposed by the IETF
   standardization process. Personally, I recommend to not worry too 
   much about this while working on a Proposed Standard. If you
   later run into debates because someone want to advance while 
   others want to add/change stuff, you are in the very fortunate 
   situation that your document has been implemented and is being 
   used.

   <soap>
     Perhaps this is an issue totally ignored in the IETF problem
     discussions: The IETF rewards success with pain. The more
     pain you feel, the more successful you likely are. ;-)
   </soap>

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 15 Dec 2003 22:57:54 +0100

Juergen,

Thank you very much for this guidance.  I think it answers the open
question and we know now how to structure the first version of the
MIDCOM MIB.

> wrong track and I have to read the document (which one?).

Basically, it is the midcom charter.

The midcom WG is chartered to select an existing standard protocol and
use it "as the basis for the development of a middlebox communication
protocol."  This term magically turned from 'odd' to 'puzzling' when it
entered the SNMP community.  I hope we do not have to change the charter
after selecting SNMP ;-)

    Juergen Q.