Proposal 2. Class instance naming.

["Maria Greene" <maria@apparatenet.com>]

The complicated indexing mechanism of the SNMP mapping document is
unnecessary. I propose we replace it with two statements added to class:
snmp-name and snmp-parent. Both statements are optional and must be after
the attribute statements. The argument to snmp-parent is the class name of
the "containing " class. If absent, the value is understood to be "root",
the mythical top of the containment tree. The argument to the snmp-name
statement is a list of attribute names (possibly prefixed by implies for
compact encoding). The SNMP instance identifier for an attribute is formed
by concatenating the values of the snmp-names of the class instances from
the root of the tree to the class with the attribute. If none of the parents
or the leaf class instance have names, then use ".0".

Here's an example:

class Interface {
	//...
	snmp-name (index);
	//...
};

class RcvAddress {
	//...
	snmp-name (address);
	snmp-parent interface;
	/...
};

The INDEX clause for the SMIv2 table containing instances of RcvAddress
would be { index, address }.

Obvious questions:

Q. Why is a class only allowed to be the child of one other class?
A. Simplicity. The limitations of the way instance identifiers are formed
makes it sufficient. It is not a general-purpose way to define relationships
between arbitrary instances, but that's not possible without protocol
changes. (Instead, these sorts of relationships can be modeled as classes
themselves. The ifStack is an example. Each instance is a directed arc in
the stack.)

Q. How does this map to each of the indexing styles that have been
identified for SMIv2 MIBs?
A. Each of the five identified index types suggests a different use of
derivation and parent-child relationship:
	scalar (no index) - the instance identifier for attributes of the child
(and all parents) is .0.
	index - a multi-instance class with parent root or parents without their
own naming attributes.
	augments - this can indicate sub-classing for backward compatibility or
just distribution of a class' attributes among multiple tables.
	extends - this generally indicates sub-classing. For example, the ethernet
interface table sparsely augments the interface table because only some
interfaces are ethernet interfaces.
	reorders - this indicates a broken MIB (IMHO). We shouldn't have to warp
SMIng to support MIBs with this type of indexing. (It can still be modeled,
just not elegently.)
	expands - this indicates a parent-child relationship. The first indices are
the parents', followed by the child's.

2.1 The cardinality statement.

Cardinality is simply the number of instances of the related class that can
exist in the relationship. For example, a relationship can be one-to-one,
one-to-many, exactly 12, etc.

I propose we add a optional cardinality statement immediately following the
parent statement. Examples of cardinality statements are:

cardinality 1;		// exactly one child instance
cardinality ifNumber;	// an array of children of size indicated by the
attribute ifNumber
cardinality 0..255;	// a variable number of children up to a maximum of 255
cardinality 0..*;		// a variable number with an implementation-specific
upper limit
cardinality 0..EventLog::maxEntries; // a variable number with an upper
limit defined by 							 // another attribute

If the cardinality statement is absent from a class that has a parent, then
the basic cardinality can be determined from the naming. A child without any
additional naming attributes must exist in a one-to-one relationship with
its parent (which need not have any naming attributes either if all its
attributes are implemented as scalars). A child with one or more naming
attributes can be inferred to have cardinality 0..*.

Obvious question:

Q. Doesn't the cardinality statement really belong in the parent class? Why
not have the parent class definition list the children and the associated
cardinality?
A. This would require that we modify the parent class (which may be in a
standard SMIng module) to add new child classes. Having it in the child
class is more extensible.