Re: Examples of ASN.1 for SMIng.txt

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Alessandro Triglia writes:

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

Todays ASN.1 might be better than the old ASN.1. But still, a generic
tool can only check ASN.1 and not the SMIng based on ASN.1

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