Subject: [Diffserv] Re: [RMONMIB] RE: DEFVAL in dsmonAggGroupIndex - SMIC error

From: Andy Bierman <[email-masked]>
Date: Sat, 03 Nov 2001 21:42:17 -0800

At 01:11 PM 11/2/2001 -0800, Andrew Smith wrote:
>I've (still) got serious problems with this MIB, its relationship to the
>DiffServ MIB and the "aggregation group" concept. Haven't spoken up recently
>because I thought others would taken care of it by now.
>
>1. You're duplicating functionality from the DiffServ MIB here. If that's
>fine with IESG then OK but it seems like a bad idea to me. People have
>argued on the RMON list before that DSMON is meant for probes, not switches
>but I believe a large proportion of DSMON implementations will end up inside
>switches with consequent waste of resources. I do not think there is a good
>case to be made for optimising this MIB for the "standalone probe" case.

Which objects exactly are being duplicated?

>2. You're inventing a new grouping concept with its own number space for
>something that the DiffServ conceptual management model, MIB and PIB do
>using their "data path" concept and which they have their own numberspace
>for. You should re-use that concept or else persuade DiffServ to use your
>concept but there is no excuse for having duplicate mechanisms in MIBs that
>are being developed/published at roughly the same time by IETF (is this due
>to OPS and TSV ADs not talking to each other enough? No apologies for adding
>Diffserv WG to this message).

Please be specific.
What exactly are you talking about?

Are you referring to the DSMON Aggregation Profiles?
We try to make it very clear in the draft that these DSCP to aggregation group
mappings are for monitoring purposes only, intended for the case where the 
DSMON
probe has less then 64 'buckets' per counter object (e.g. packet counter).

>3. You're overloading your dsmonAggGroupIndex numberspace with the
>"convenience functionality" of letting the group index equal the DSCP.
>There's no need for this and it cannot be useful unless you have some
>mandated behaviour that relies on this 1:1 mapping e.g. a default setting
>for the table on power-up or initial state. Leaving it as an option (see
>"SHOULD" below) makes it useless in a multi-vendor world.

I don't understand the objection here.  Are you referring to the INDEX
range that starts from zero instead of one? This is a rather minor SMI
warning, isn't it?  What is useless in a multi-vendor world?

>Specifics:
>
>4. "dsmonAggGroupIndex OBJECT-TYPE
>     SYNTAX      DsmonAggGroupIndex
>     MAX-ACCESS  read-write
>     STATUS      current
>     DESCRIPTION
>             "The aggregation group which contains this DSCP value.  Upon
>             creation of a new sub-tree (set of 64 entries with the same
>             dsmonAggControlIndex value) in this table, the agent SHOULD
>             initialize all related instances of this object to the value
>             zero.
>
>             This object MUST NOT be modified if the
>             dsmonAggControlLocked object is equal to 'true'."
>     DEFVAL { 0 }"
>
>a)  This description does not make sense (to me): dsmonAggControlIndex does
>not appear in this table so how is creation of a new sub-tree related to
>entries in this table? Please clarify this wording. Or is this a typo?

dsmonAggControlIndex is the first INDEX component of the dsmonAggProfileEntry,
where dsmonAggGroupIndex is defined. Not a typo.

>b) What's the point of the "SHOULD" directive here?

Some people insisted that there should be a default configuration,
with all DSCPs mapped to the same aggregation group.  I don't
really agree, but that's the point.

>c) Define "related instances" more precisely.

All entries in this table with the same INDEX values. Standard meaning.

>d) You can't say that a read-write variable "MUST NOT" be modified (by
>whom?) - you can define that if you try to do so then the operation will
>pass/fail etc. but you can't use a MIB to enforce what a manager can/cannot
>attempt (you might as well add "please" :-)).

Where in the SMI does it say this type of 'lock statement'  is not allowed?
There is a high-level lock for modifying any of the aggregation profiles
in the MIB design. Modifying the DSCP mappings on the fly is bad
for statistics aggregation and may make implementation harder.

>e) I don't think you can rely on "0" as a special value of DSCP here - use
>something like -1 if you really need to use a DEFVAL.

Zero is not really a special value -- and I think you are referring
to the aggregation group index zero, not a DSCP value of zero.
There's nothing special about this group index value either -- people
thought that some number had to be picked for a default.

>That's all on this particular issue, I guess I ought to read the rest of the
>MIB now ...
>
>Andrew Smith

Andy

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf
>Of Andy Bierman
>Sent: Friday, November 02, 2001 8:31 AM
>To: Harrie Hazewinkel
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: DEFVAL in dsmonAggGroupIndex - SMIC error
>
>
>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
> ><[email-masked]> 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
>
>
>
>
>_______________________________________________
>RMONMIB mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/rmonmib

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Andrew Smith" <[email-masked]>
Date: Fri, 2 Nov 2001 13:11:46 -0800

Specifics:

Andrew Smith

-----Original Message-----

Andy