Re: Examples of ASN.1 for SMIng.txt

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

Juergen Schoenwaelder wrote:

> But still, a generic
> tool can only check ASN.1 and not the SMIng based on ASN.1

Of course you are right.  This was the argument put forward by GDMO in
the mid 1980s.  There is always a balance:

	a)	Do something that is your own thing, and get a small set of tools to
support that as a niche market;  or

	b)	Latch onto a more general notation with a wider set of tools that
can meet most of your needs.

The balance may depend on whether you are interested in professional
quality tools or simply want public domain offerings.  Those
alternatives are also a difficult balance!

John L

> >>  The SMI is its own little language with its own syntax and
> >> semantic constraints.
> 
> Alessandro> True for the semantics, not necessarily true for the
> Alessandro> syntax. In our proposal, the syntax is completely and
> Alessandro> rigorously defined in ASN.1 in the I-D. As a consequence,
> Alessandro> MIB writers could avail themselves of the full power of
> Alessandro> the ASN.1 standard notation for defining
> Alessandro> arbitrarily-complex data structures (which doesn't seem to
> Alessandro> be questioned). This would enable them to create MIBs
> Alessandro> containing structures and arrays within structures,
> Alessandro> unions, optional components, and so on, with the ability
> Alessandro> to express sophisticated constraints on the components and
> Alessandro> between two or more components.
> 
> There is always a border line where the "rigorously" defines ends.
> Your ID contains constructions such as
> 
>     SMICharacterString ::= UTF8String(SIZE(0..65535))
>         (CONSTRAINED BY {--Not all characters are allowed--})
> 
>     Float32 ::= REAL
>         (CONSTRAINED BY {-- Encodable in 4 octets --})
> 
> which I doubt a generic tool understands. There are also things like
> linkages between statements which you can't express in ASN.1.
> 
> : If the entity class of an entity instance is an array type without
> : an INDEXING-ATTRIBUTES parameter, the table is not indexed. Such a
> : table must be linked to another table by means of the BASE-ENTITY-
> : INSTANCE and RELATIONSHIP parameters.
> 
> Thus, I have some problems with strong claims such as "completely and
> rigorously defined".
> 
> Alessandro> This is also true of any other SMIng proposals, and any
> Alessandro> new languages that they define. The ASN.1 proposal doesn't
> Alessandro> need any special infrastructure in itself. Of course, if
> Alessandro> an implementor chooses to buy an ASN.1 toolkit, he must
> Alessandro> write his code against the toolkit API. Otherwise, he is
> Alessandro> free to write a compiler from scratch.
> 
> Your ID does not point out which subset of ASN.1 I need to implement
> in order to get SMIng. Or is the proposal that I have to have full
> ASN.1 support? If that is your proposal, please explain how that maps
> to protocols such as SNMP or COPS-PR.
> 
> /js
> 
> --
> Juergen Schoenwaelder      Technical University Braunschweig
> <schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
> Phone: +49 531 391 3289    Muehlenpfordtstr. 23, 38106 Braunschweig, Germany
> Fax:   +49 531 391 5936    <http://www.ibr.cs.tu-bs.de/~schoenw/>

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