DEFVAL in dsmonAggGroupIndex - SMIC error

[Andy Bierman <abierman@cisco.com>]

At 06:33 PM 11/1/2001 -0800, Harrie Hazewinkel wrote:



Now that I looked at this some more, I think the SMIC is wrong.
This DEFVAL should not be a syntax error.

The dsmonAggGroupIndex object itself is read-write object
and not an INDEX in the table its defined in.  The DEFVAL clause
indicates that the initial aggGroup value an agent should set for each
DSCP mapping. All DSCPs in the same group -- perfectly valid concept,
perfectly valid SMIv2 syntax.

However, the dsmonAggGroupIndex object is also declared as one of the
INDEX components in the dsmonAggGroupEntry. SMIC is complaining about
the DEFVAL that is only meant to apply to original OBJECT-TYPE macro,
not a DEFVAL for the INDEX -- that doesn't even make sense.

>--On Thursday, November 1, 2001 7:40 AM -0800 Andy Bierman 
><abierman@cisco.com> wrote:
>
>>At 01:39 PM 11/1/2001 +0100, Wijnen, Bert (Bert) wrote:
>>>OK, 2 issues basically came out after your approval.
>>>
>>>- SMICng complains about having a DEFVAL for dsmonAggGroupIndex
>>>   since this object is used as an index object as well. Andy
>>>   did put it in since you insisted. I am discussing the matter
>>>   with the SMIv2 doc editors
>>>- Frank Strauss (I asked him to check to see if his compiler
>>>   would also complain about that indexing thing, which it did not,
>>>   but then Juergen has now added a lvl 4 warning about it).
>>>   Frank brought out that the OID could become too long based on
>>>   some index definitions. So Andy has posted a new rev to address
>>>   that

 >....


>>The rules are too strict!
>
>I agree here. When a default value is written in a description
>it seems to be allowe, but when a DEFVAL is used it is
>not because of compilers complain. That sounds
>contradictionary to me. The DEFVAL-cluase is
>(IMHO) there to support more formally the
>semantics of the object, but it may neither
>create a conflict with the semantics provided in
>the description-clause.
>
>
>Maybe far fetched, but I can envision such a scenario.
>Someone can create some object in X-MIB with
>a read-create ACCESS and a DEFVAL seems appropriate.
>Later someone else in Y-MIB uses that object in an
>index, because it wants to extend information for
>that perticular object only.
>The only option (to keep compilers happy) will then
>be create/duplicate the object and provide the same
>semantics without DEFVAL.
>
>Hmm....

Someone already did that -- in DSMON-MIB !




>My thoughts about it,
>
>
>Harrie Hazewinkel

Andy