Re: Impressions of Bierman proposal

[John Larmouth <j.larmouth@salford.ac.uk>]

There are a great many different ways of producing "discriminators of
unions" (or "determinants for alternatives" as we would say in ASN.1)
that are used in legacy protocols (protocols designed by hand, with bits
and bytes pictures or using tabular notation).  The list you give below
covers some but not all of these approaches.

These issues have been widely studied as part of the development of the
ASN.1 Encoding Control Notation (ECN).

(Of particular importance and difficulty is the association of a list of
discriminators with the columns of a table, where each cell is (without
discrimination) allowed to have a variety of alternatives, but where
each row is constrained to have the same alternative in a particular
cell as all other rows, but the alternatives for each column differ in
each instance of communication of the table, and a single encoding is
desired for the discriminator.)

I have described this at the encoding level, but if your specification
level includes fields for discriminators/determinants (which it should
not!) then the discussion and concepts apply there too.

John L

"David T. Perkins" wrote:
> 
> HI,
> 
> I just finished a first pass of the Bierman proposal. If you haven't
> read it, then I suggest that you do so. It sets aside a long followed
> convention in identifying SNMP management information, and by doing so
> makes real progress in reducing the gap between the data structures
> used by the software in managed devices and their representation
> in MIB modules. By reducing the gap, I believe that more designers
> of software in managed devices will choose SNMP-based management
> over other approaches, and the quality of the SNMP support will
> improve.
> 
> I learned in the proposal a new approach for creating a discriminated
> union. (All unions are ultimately discriminated!) Interesting...
> So, now there are four ways to specify the discriminator, which are:
>   1) a value in a separate object (an efficient approach when
>        there are many unions that share the same discriminator,
>        but has the problems of how to tie the discriminator to the
>        each object, and enforcing update/create consistency)
>   2) the data type of the value acts as the discriminator (which
>        restricts the members of the union, and, thus, the usefulness
>        of the union, and typically results in falling back to
>        #1 approach)
>   3) make the value of member of the union to always be a two member
>        sequence, where the first member is the discriminator and
>        the second member is the "real" value (this is my favorite
>        because it makes the relationship explicit with a downside
>        of being slightly more complex and doesn't allow sharing of
>        the discriminator)
>   4) (AndyB's innovation) the discriminator is part of the identification
>        of the object (that is, part of the OID value that names the
>        object instance) (Anyone want to take a shot at listing the
>        pros and cons of this approach)
> 
> The proposal addresses an area that I didn't realize was an outstanding
> problem, which is essentially, "how does one add columns to a table (when
> you don't own the definition of the table) and have the OID value
> for each column "close" to the OID value used for columns in the
> original table?" This doesn't seem like such a big problem and the
> solution a big win, until you realize that it's really a building
> block that is used to create templates (defined with the proposal's
> TYPEDEF construct) for aggregates of values, which is a BIG innovation.
> 
> That's it for now. It will be interesting working through all the
> details and making a decision over the next few quarters.
> 
> Regards,
> /david t. perkins

-- 
   Prof John Larmouth
   Larmouth T&PDS Ltd
   (Training and Protocol Development Services)
   1 Blueberry Road                     
   Bowdon                               j.larmouth@salford.ac.uk
   Cheshire WA14 3LS                    Tel: +44 161 928 1605
   England				Fax: +44 161 928 8069