Re: AUGMENTS and SPARSE-AUGMENTS

[Andy Bierman <abierman@cisco.com>]

At 03:18 AM 12/16/2001, Andy Bierman wrote:
>Hi,
>>...
>  hcIpStats                     ::=   { myObjects 4 }
>  hcIpStats[17]                 ::=   N/A
>  hcIpStats[17][1]              ::=   N/A
>  hcIpStats[17][1][192.168.0.1] ::=   N/A
>  hcIpStats[17][1][192.168.0.1].inHCPkts    ::= { hcIpStats 1 1 17 1 4 192 168 0 1 }
>  hcIpStats[17][1][192.168.0.1].outHCPkts   ::= { hcIpStats 1 2 17 1 4 192 168 0 1 }
>  hcIpStats[17][1][192.168.0.1].inHCOctets  ::= { hcIpStats 1 3 17 1 4 192 168 0 1 }
>  hcIpStats[17][1][192.168.0.1].outHCOctets ::= { hcIpStats 1 4 17 1 4 192 168 0 1 }
>  hcIpStats[17][1][192.168.0.1].timeData    ::= { hcIpStats 1 5 17 1 4 192 168 0 1 }
>  hcIpStats[17][1][192.168.0.1].timeData.createTime  ::= 
>                                                { hcIpStats 1 5 1 17 1 4 192 168 0 1 }
>  hcIpStats[17][1][192.168.0.1].timeData.updateInterval  ::= 
>                                                { hcIpStats 1 5 2 17 1 4 192 168 0 1 }
>
>Note 3)
>Except for the timeData STRUCT in this example, the 4 SCALAR counters
>demonstrate a transparent transformation of an SMIv2 table which uses the AUGMENTS
>clause instead of an INDEX clause.
>
>Note 4)
>The augmenting container is conceptually unwrapped inside the augmented container,
>instead of being added with another level of containment, i.e., 'hcIpStats' is not 
>the descriptor conceptually added to 'ipStats', but rather its contents 
>('inHCPkts', etc.). This doesn't apply to SCALARs, because they are not containers.

The behavior described in Note 4 is broken.
In order to get the numbering in Note 2, the ipStats would really
have to be augmented 5 times with 4 scalars and 1 struct, not
1 time with 1 struct (containing 4 scalars and 1 struct).

An alternate plan for ease-of-use is to add the keyword "UNWRAPPED"
(or whatever) in place of the first <object-descriptor>.
In this case, the <aug-construct-type> must be "STRUCT".
ARRAYs and UNIONs cannot be unwrapped.

Andy