Subject: MIB Report 3/3: A Structural Issue

From: "Zhu, Rupert" <[email-masked]>
Date: Fri, 8 Nov 2002 18:25:03 -0600

------------------------------------------------------------
MIB Report 3/3: A Structural Issue

Similar to relational database design, a very important aspect of
MIB design is its overall structure.  That is, how to partition
total data, or how to group basic data items to form tables.

In MIB design process, general object modeling techniques and principles
should apply.  For example, any of the following.

o  Entity-Relationship Model (E-R Model).
o  Relational Data Model.
o  Common Information Model (CIM) by DMTF.
o  Universal Modeling Methodology (UML) by Rumbaugh, etc.

As a rule of thumb, each object class should be mapped to a distinct
MIB table.  In particular, if two object classes have a one-to-many
relationship, DO NOT combine them into the same MIB table.

The current MPLS-TE-MIB design does not comply with object modeling
principles because it lumps two distinct object classes in a single
MIB table.  It results in a big, 37-field table.  This design causes
undesirable data duplications and obscures logical relationship
to MPLS-FTN-MIB.

I would like to recommend a modular design that splits the big
monolithic table into two separate tables, each representing
exactly one object class.

Although I won't be able to attend the upcoming MPLS MIB Review in
Atlanta, I hope this proposal could be considered.

Rupert Zhu
System Engineering
Santera Systems Inc
3605 E. Plano Parkway
Plano, TX 75074
Phone: 972-461-6383

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 08 Nov 2002 20:30:56 -0500

Speaking of style problems, please DON'T send doc files to the mailing
list.  Microsoft free sites can't read these files.

Curtis