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

[Keith McCloghrie <kzm@cisco.com>]

> Keith, is this not a really really exceptional corner case?
> Have we seen it used up til now?

It is exceptional; I hadn't seen it used until recently.

> 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?

That's fine with me.

Keith.


> 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.
> > 
>