Proposal 1: Improve alignment between SNMP mapping statements and core SMIng statements.

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

The SMIng base language is elegant and simple. However, I was disappointed
to see that the legacy of the old SMI's table and indexing structure is
being perpetuated. Its arcana is even being expanded in the form of the five
"flavors" of index statements. This is confusing and unnecessary. The
primary requirement of an SNMP protocol mapping is to assign OIDs to
attributes, events and nodes and to specify how instance identifiers are
formed. There are secondary requirements such as specifying the attributes
that get sent in a Notification PDU and hints to allow SMIv2 MIBs to be
generated.

I propose we move the SNMP extensions for OID assignment and instance naming
into the SMIng statements, rather than externally in the snmp statements.
The major benefits of this are clarity and maintainability. In the first
version of my class macro language I kept many extensions separate from the
class macro for the benefit of "purity" of the language. The users
complained often because it was difficult to maintain the definitions. For
example, when an attribute name changed or got added or removed from a class
there were two or more places (often in separate files) that needed to be
updated. Also, it was just a lot more work to have them external because the
statement being extended needed to be imported.

The lack of clarity is compounded in the current draft because the statement
names do not reflect the relationship between the extensions and the base
SMIng statements. There are two sets of terms and definitions for the same
things (which have redundant information like status and description).

So, I specifically suggest:
	a. Do away with the node, scalars, table, and notification statements.
	b. Add an snmp-oid statement to identity.
	c. Add an identity statement to module, class, attribute, and event.
	(d. Use a different term than "statement" for the sub-statements. Perhaps
"clause", "part", or field"?)
	e. Add snmp-attrs statement to event.

The identity statement in the module signals that this SMIng module has an
SNMP mapping. For new modules (not based on existing SMIv2 MIBs) that is the
only OID that is required since OIDs for attributes and events can be
determined by MIB compilers based on the position of the class definition
and the attributes and events in the class. (With the extra sub-ids added
for the "table entry" node that would have existed in the MIB, just to
facilitate generation of a SMIv2 MIB.) This leads to the requirement that
revisions to the SMIng module not re-order or remove existing definitions.

For SMIng modules that replace existing MIBs, the identity statements in
class, attribute, and event can be used to supply the descriptor and the OID
mapping to the MIB definition. Multiple identity statements may be used to
reflect nodes added to the MIB just for grouping. Note that the convention
of having the name of the identity be the descriptor is just a convenience
for human mapping to SMIv2 MIBs since it descriptors are never used in the
protocol and there's never any reason to convert to a MIB since it already
exists!

Adding the snmp-attrs statement to event removes the need for the
notification statement. Note also that we always use the attribute name and
don't have to remember when to use attribute and when to use the
SNMP-version of the name.

Note that the compliance statement stays external to the class definition
statements. This is appropriate since there can be more than one compliance
for a module. (However, is compliance really SNMP-specific?)

Here is an example:

module IETF-FOO {
	import mib-2 IETF-SMING;
	//...
	identity fooMIB { snmp-oid mib-2.88; };
	identity fooObjects { snmp-oid fooMIB.1; };
	identity fooNotifications { snmp-oid fooMIB.2; };

	//...
	class Foo {
		//...
		identity fooTable { snmp-oid fooObjects.1; };
		identity fooEntry { snmp-oid fooTable.1;};
 	    	// ...
	 	attribute Gauge32 speed {
			//...
			identity fooSpeed { snmp-oid fooEntry.1; };
			//...
		};

  	   	// ...
        		event down {
			//...
			identity fooDown { snmp-oid fooNotifications.1; };
			//...
      		};
	};
};

Obvious questions:

Q.  Can the attributes of a class be split across multiple SNMP tables with
this proposal?
A. Yes. The class definition would have two identity statements for each
table (table plus entry). The attributes fully specify their OID so it's not
a problem.

Q. What about the information in the index/augments/extends/reorders/expands
statement?
A. Move it into the class definition. See the next proposal for an
alternate, more object-oriented way of specifying this information.

Q. But what about the "purity" of the SMIng class definition?
A. Maintaining the purity of the SMIng class statements by not mixing in
protocol-specific information is ill-advised, in my opinion. If the language
is difficult to use for SNMP there will be little incentive to go to it
rather than use the "simpler" SMIv2. I expect 90% of the use of SMIng will
be for next generation MIBs. I'm not sure if the goal is for COPS-PR and
SNMP to share common models and not just a modeling language, but if that is
a goal then having both mappings in front of us should force us to keep both
protocol's needs in mind when as we define new classes. I don't see the need
for too much SNMP-specific information added to the base statements, so it
is  not too painful to ignore them, especially if this is a new module which
will have very little.

Q. What about SMIv2 descriptors now that you don't have the table's
attribute to descriptor mapping?
A. These can be taken from the identity statements.