SMI-DS issued raised in SLC

[Andy Bierman <abierman@cisco.com>]

Hi,

I've thought a little bit about the SMI-DS issues that 
were raised this week, and I think I understand how to address
some of them.

1) Sub-Classes vs. AUGMENTS: Why we need both

I got AUGMENTS wrong. It only applies to variables,
not types. Classes can have sub-classes and object instances
can have augmenting instances. 

Sub-classing is not the same as augmenting. With AUGMENTS,
we want to preserve the original OIDs and add additional OIDs
to a particular instance of a base class.  We also need a
formal SPARSE-AUGMENTS clause with sub-clauses for machine 
and human readable "selection criteria" boolean expressions.
(Sub-classes are SPARSE-AUGMENTS for types.)

This means the augmentation node is not needed, since an 
augmentation will simply be a variable declaration of the
augmenting class. It won't be retrievable in the same
sub-tree as the base object -- only sub-classes will
have that property.  

A SMIv2 --> SMI-DS transformation of an AUGMENTS will
be transparent with these changes, preserving the SMIv2
instrumentation.

2) Instance Naming

I'm not as clever as Jeff and Randy, so it took me awhile
to understand why I can still design cascading method routines,
even if the instance components in the OID are all on the right.
I still like the sort order better with instance components
in their 'natural' position, but they have to be on the right
to preserve the agent instrumentation. 

This way, a SMIv2 --> SMI-DS transformation will be an (almost) 
transparent to the agent instrumentation code. We also have to
preserve IMPLIED (as deprecated), so instrumentation code for 
tables using it doesn't need to change. We have to preserve
the dot-zero on the end of non-scalar variable declarations
as well.

We still need to account for the stupid "dot-1" in the SEQUENCE. 
We decided we want to stop using ASN.1 sequences, and use hierarchical 
naming instead, but the dot-1 is baggage we have to keep forever.
It will still be in "old" OID pointer values (as will the 
dot-0 in scalars).

The first OID component after the left anchor in a non-scalar
variable declaration needs to be the dot-1. This will preserve
SMIv2 naming for transformed non-scalar variables, and keep
it out of class definitions.

4) Early vs. Late Binding of Indices for ARRAYs

I think I understand a little of Randy was talking about.
The answer is -- it depends.

Sometimes you want to put the index in the class definition 
(like the array of 64 DSCP to counter aggregation group mappings
in the DSMON-MIB example). Sometimes you want to put the index 
outside the class definition (like the array of aggregation 
profiles in the DSMON-MIB example).  It's up the data structure 
designer to decide.

Andy