Re: Examples of ASN.1 for SMIng.txt

[Andy Bierman <abierman@cisco.com>]

At 09:34 AM 12/11/2001, Juergen Schoenwaelder wrote:

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


I don't know if others feel this way, but to me, the fact that
SMIv2 is derived from ASN.1 is irrelevant. The syntax is what it
is, and I learned SMIv2 without ever learning ASN.1.
So the fact that there is a 'better' ASN.1 out there is
also irrelevant to me. 

Andy



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