Re: Examples of ASN.1 for SMIng.txt

["Alessandro Triglia" <sandro@mclink.it>]

----- Original Message -----
From: "Juergen Schoenwaelder" <schoenw@ibr.cs.tu-bs.de>
Sent: Tuesday, December 11, 2001 10:34 AM


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

The constraint in SMICharacterString can be expressed more formally as
follows:

     SMICharacterString ::= UTF8String(SIZE(0..65535))
         (FROM(" 0123456789ABCDEFGHIJKLMNOPQ..."))

The constraint in Float32 is slightly more complicated, because it involves
knowledge of the encoding. However, this constraint can be expressed by
constraining the range of the mantissa and the range of the exponent.

     Float32 ::= REAL
         (WITH COMPONENTS {
            mantissa(<some range>), base(2), exponent(<some range>) })


In both cases, we just chose to make the specification simpler.



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

The syntax of all the statements ENTITY-CLASS, ENTITY-INSTANCE, NODE, etc.
is rigorously defined.  For example, if an ENTITY-INSTANCE statement in a
module does not contain a value of type OBJECT IDENTIFIER in its OID clause,
or does not reference an ENTITY-CLASS definition in its ENTITY-CLASS clause,
or these two clauses are absent or misplaced, then you have a syntax error,
that a generic ASN.1 tool will detect.


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


This is intended, at least if MIB writers are to use the full expressiveness
of the ASN.1 notation to define MIBs containing complex data structures.


> If that is your proposal, please explain how that maps
> to protocols such as SNMP or COPS-PR.

The ENTITY-INSTANCE statements assign OIDs to all the components of the data
structures defined in ENTITY-CLASSES, down to the leaf level. The elementary
data are therefore accessible by SNMP as objects. As for COPS-PR, a SEQUENCE
of elementary components, that has an OID assigned, is to be made accessible
by the protocol as a PRI.

Alessandro


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