Re: Corner case in draft-ietf-ops-mib-review-guidelines-03.txt

[Keith McCloghrie <kzm@cisco.com>]

> I think that I must have missed your point.  My thinking was as follows.
> 
> If you mean auxiliary objects in the new table,

Sorry, I made two mistakes.  I shouldn't have used the term "auxiliary
object", and I had a typo in the syntax within the SEQUENCE in the
example I gave.  I've fixed the typo in the following:

> > The case that I'm thinking of is not an "expansion table"; here's
> > an example:
> > 
> >    xxxTable  OBJECT-TYPE
> >       ...
> >    xxxEntry  OBJECT-TYPE
> >       ...
> >       INDEX   { xxxPhysicalIndex }
> >      ...
> > 
> >    SEQUENCE { xxxPhysicalIndex PhysicalIndex }
> > 
> >    xxxPhysicalIndex OBJECT-TYPE
> >       SYNTAX      PhysicalIndex
> >       MAX-ACCESS  read-only
> >       ...
> > 
> > It's a sparse augments.  The INDEX clause cannot be "identical to that
> > of the original table" because the entPhysicalTable has
> > "INDEX { entPhysicalIndex }"  and then the SEQUENCE for xxxTable would
> > be empty !!
> 
> I do not understand the example.  Sorry if I am being thick.
 
No, it was my fault.  This xxxTable only contains rows for a subset of the
rows in the entPhysicalTable.  The purpose of the table is to indicate which
physical components have a particular capability, let's call it capability X.

The same functionality could be obtained by a table defined using
"AUGMENTS { entPhysicalEntry }" with the augmenting table having one
object: a TruthValue with 'true' meaning has capability X, and 'false'
if not, but this requires an object instance for every physcial
component, which could be thousands of instances (e.g., at least one
per physical port).  In contrast, the sparse augmentation above could
only be applicable to some modules, not other modules (but never
ports), and thus has at most, say, a dozen instances.

Keith.