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

["Durham, David" <david.durham@intel.com>]

Hi Maria,

I have a question about your proposal below. Currently, by splitting the
definition from the implementation, the current form of SMIng seems to allow
a significant amount of reuse (its classes essentially act like templates).
If the identification of an implementation of a class were integrated with
the definition of the class itself, wouldn't that limit the reuse of that
class? For example, suppose I define a class with a rowstatus, storagetype,
and ownerdescription attribute which could be reused 100's of times via
containment or through inheritance. If I assigned complete oids to these
three attributes within the class (and even define the index, which I can't
really do in this case), then how could I reuse this class definition?

-Dave

PS. Please excuse my example, there are other ones such as subnet, filter,
etc. that are data definitions that can be reused over and over again, by
being contained in other classes or through inheritance.

> -----Original Message-----
> From: Maria Greene [mailto: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.
> 
> 
>