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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Keith, is this not a really really exceptional corner case?
Have we seen it used up til now?
Why would we expect it to show up soon/anytime?
Can we not deal on a case-by-case basis on such corner cases
when/if they occur?

Bert


> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of Keith McCloghrie
> Sent: Monday, January 31, 2005 22:36
> To: heard@pobox.com
> Cc: kzm@cisco.com; mreview@ops.ietf.org
> Subject: Re: Corner case in 
> draft-ietf-ops-mib-review-guidelines-03.txt
> 
> 
> > 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.
>