Re: Discriminated unions in MIBs

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

On Tue, Feb 24, 2004 at 03:58:29PM -0000, Adrian Farrel wrote:
 
> What we currently have in the label table (gmplsLabelTable) is a 
> complex union.

[...]
 
> I could compress the whole into an OCTET STRING and give guidance about 
> interpretation. This is what the signaling protocol does, but I don't
> want to do this because I want it to be simpler to read or write 
> (for example) gmplsLabelSonetSdhBranch.
> 
> I could follow the example of InetAddress and define a set of syntaxes 
> for each member of the union. This is fine for the simple members, but 
> for the more complex members I would have to give DISPALY HINTs and 
> interpretation clauses in the DESCRIPTION. And it would
> still be impossible to read or write a single component.
> 
> I could leave the table entry as currently defined. This is most readily 
> accessible, but it leaves a lot of unused objects in any logical row.

Another option would be to use multiple tables. So depending on the
type, you will find the type specific attributes in sparse table
augmentations. The downside with this approach is that you usually
end up doing multiple requests to read the data of a specific entry
(well, you can still try to read all sparse augmentations and in
this case it boils down to roughly the same number of requests 
variables).

I am not saying this is better - I just wanted to mention this approach
for completeness.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany