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 8:43 AM


>
> >>>>> DUBUISSON Olivier writes:
>
> Olivier> For example, that would allow SMIng designers to use OSS
> Olivier> Nokalva's syntax checker that can be freely downloaded from
> Olivier> their website, that is, use the full power of ASN.1 (or be
> Olivier> able to use it at any time if needed in the future) and
> Olivier> benefit of the tools that are in place.
>
> A generic ASN.1 tool will only understand ASN.1 and not SMIng. There
> are several semantic things in the ASN.1 proposal which a generic
> ASN.1 tool has no chance to understand and check and thus you still
> need a specific SMIng compiler.


A generic ASN.1 tool will detect many possible errors that are ASN.1 syntax
errors. Of course, you need a SMIng specific tool to check the semantic
consistency of the module (for example, whether OIDs are assigned to
instances in a meaningful way).

One important point to note about the facilities present in current ASN.1 is
that *every* aspect of the syntax is now rigorously defined, whereas the
form of ASN.1 that has been used in SMI relied upon an old macro facility
that was flawed.  As a consequence, there are more kinds of inconsistencies
that a generic syntax checker can detect now in an ASN.1-based SMIng module,
than there were for a SMI module.


>
> The SMI is its own little language with its own syntax and semantic
> constraints.

True for the semantics, not necessarily true for the syntax. In our
proposal, the syntax is completely and rigorously defined in ASN.1 in the
I-D. As a consequence, MIB writers could avail themselves of the full power
of the ASN.1 standard notation for defining arbitrarily-complex data
structures (which doesn't seem to be questioned). This would enable them to
create MIBs containing structures and arrays within structures, unions,
optional components, and so on, with the ability to express sophisticated
constraints on the components and between two or more components.


> If you base this language on other languages such as
> ASN.1 or XML, you will be able to use generic tools to validate the
> input whether it is "valid" ASN.1 or XML. But generic tools will never
> be able to check the specific SMI syntax and semantic constraints.
>
> Also note that there are several SMIv1/SMIv2 implementations and
> whatever comes out of SMIng will have to be integrated into these
> implementations.

This is also true of any other SMIng proposals, and any new languages that
they define. The ASN.1 proposal doesn't need any special infrastructure in
itself. Of course, if an implementor chooses to buy an ASN.1 toolkit, he
must write his code against the toolkit API. Otherwise, he is free to write
a compiler from scratch.

Alessandro Triglia
OSS Nokalva


> None of the SMIv1/SMIv2 implementations I am aware
> of is based on a generic ASN.1 instrastructure.
>
> /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/>
>
>
>
>