revised SMI-DS OID encoding rules

[Andy Bierman <abierman@cisco.com>]

Hi,

Here are the revised SMI-DS OID encoding rules.
The lexi-next traversal is now across columns instead
of rows (in SMIv2-speak).

The WG decided to use the SMI-DS hierarchical naming,
if we can make it work.  I think we can maintain
existing naming for existing SMIv2 MIB modules translated to
SMI-DS naming, without sacrificing ease-of-use or
feature-set for new MIB modules. This new naming will now
work with VACM, in the same manner that SMIv2 works with VACM.

(Note that in addition to these encoding rules, the syntax
is modified so that 1 or more (not 0 or more) <object-decl>'s
must be present for all complex types. Placeholder containers
are not worth the complexity they create.)

SMI-DS Naming Variant 1:
------------------------

A SCALAR variable declaration is named as follows:

<oidBase>.0

  where:
     <oidBase> is a well-formed OBJECT IDENTIFIER base fragment
               (called the left anchor)

SMI-DS Naming Variant 2:
------------------------

All variable declarations other than SCALAR are named as follows:
     
<oidBase>.1.<childNode> [.<childNode> ...] [.<indexNode> ...]

   where:
     <oidBase> is a well-formed OBJECT IDENTIFIER base fragment
               (called the left anchor)

     <childNode> is the data object attribute identifier, which
                 must be an INTEGER between 1 and 4294967295. (Similar to
                 a column identifier in an SMIv2 table.)

     <indexNode> is present only if the variable declaration resolves to
                 a type that contains any ARRAY constructs, which must
                 be an INTEGER between 0 and 4294967295. (Similar to
                 an instance identifier in an SMIv2 table.)

OIDs are constructed in a recursive manner, using two conceptual
buffers: 
  - the "base buffer" is used for building the OID, starting from the 
    anchor, left to right
  - the "index buffer" is used for building a sequence of ARRAY indices,
    similar to the instance identifier portion of an SMIv2 OID for a tabular 
    object, left to right
When the algorithm terminates the index buffer is appended to the base buffer.

The expansion algorithm for <childNode> is repeated if the current
node represents a complex data object. If it represents an ARRAY construct, 
then all <index> components for this array type are appended to index buffer.

The algorithm terminates when a SCALAR data object is encountered.

Note 1)
Just like with SMIv2, an OID has no semantics whatsoever, by inspection.
That's why everybody hates them. (But we need them for efficient 
implementation of agents). An SNMP application needs to have knowledge of 
the semantics of the OID to correctly interpret the OID. In particular, 
the index components need to be conceptually placed in their natural 
position in the containment hierarchy, and applied to all subsequent layers.

Note 2)
The new algorithm gives up to ability to conceptually represent
an instance of an ARRAY construct (see N/A in the example below), 
in order to maintain compatibility with SMIv2. Just as before, only 
the whole container or a leaf node can be represented. Jeff's ideas 
for protocol enhancements in EOS are needed to allow these (and other) 
conceptual aggregations to be transported on the wire.

Note 3) 
Complex data types other than ARRAY do not really need the 
extra dot-1, since they don't exist in SMIv2. I gave them the 
baggage anyway to keep the algorithm simpler. The dot-1 may
be needed for all complex types, for EOS aggregate object support.


SMIv2 SEQUENCE --> SMI-DS ARRAY transformation 
-----------------------------------------------

The InetHostStats example from SMI-DS draft is an example of
a transformation of an SMIv2 table, and the new naming algorithm
now produces the same SMI-DS OIDs as the SMIv2 version:
   
 ipStats                     ::=   { someBase 1 }
 ipStats[17]                 ::=   N/A
 ipStats[17][1]              ::=   N/A
 ipStats[17][1][192.168.0.1] ::=   N/A
 ipStats[17][1][192.168.0.1].inPkts    ::= { ipStats 1 1 4 192 168 0 1 }
 ipStats[17][1][192.168.0.1].outPkts   ::= { ipStats 1 2 4 192 168 0 1 }
 ipStats[17][1][192.168.0.1].inOctets  ::= { ipStats 1 3 4 192 168 0 1 }
 ipStats[17][1][192.168.0.1].outOctets ::= { ipStats 1 4 4 192 168 0 1 }


SMI-DS to SMIv2 Data Transformations
-------------------------------------

TBD -- not as easy as transforming the other way, but deterministic 
algorithms are possible. ARRAY --> SEQUENCE(s) explained in SLC slides.
STRUCTs expand out to objects related only via DESCRIPTION clause text,
same as simple UNIONs. Complex UNIONs are harder.

Andy