Re: Examples of ASN.1 for SMIng.txt

[Andy Bierman <abierman@cisco.com>]

At 11:29 AM 12/5/2001, John Larmouth wrote:
>Andy Bierman wrote:
>
>> Silence could mean a proposal is being ignored, or it
>> could mean nothing at all.
>
>Which is why I sent my e-mail!
> 
>> I don't think this proposed syntax is very user-friendly.
>
>A subjective remark.  Can you substantiate that?  The detailed syntax
>can be varied in a fairly flexible manner (not quite with the full
>flexibility of BNF, but close, and you balance that against the added
>tool support).


I'll let others state their opinion on the ASN.1 syntax.
It is quite obvious that SMIv2, C, and java are much more
well-known than ASN.1, and I think it's quite obvious that
it will require less training costs to learn something 
that's already familiar, than it is to learn something
that is not familiar.


>> I strongly oppose using this syntax because it is not
>> familiar to a significant percentage of the user population.
>
>Oh Boy!  Not invented here!  (Sorry to be rude!)  I did not see
>"familiar syntax" as one of the criteria in the London output (or maybe
>I missed it?)

Human Readability and Writability is in the SMING Objectives.
I believe the highest design priority should go to the MIB readers,
followed by the MIB writers, followed by the MIB compiler writers.



>Actually, the syntax is very like SMI v2 except that it has surrounding
>curly braces in a number of places.  This is to make the syntax more
>"computer friendly" which should also not be neglected.
>
>> Also, it does not appear that the ASN.1 proposal advances the
>> state-of-the-art in any significant ways.
>
>I have had an off-line chat with David Perkins, in which he tried to
>explain to me the precise areas in which you wish to "advance the
>state-of-the-art". It appears to relate at least partly to avoidance of
>repetitive definitions (re-use, or inheritance features in the notation)
>and to provision for alternative but equivalent definitions based on
>different data models. Such requirements need to be more clearly
>expressed if they are to be properly addressed.


I want to replace the associated tables data model with a 
data model that allows complex aggregation and containment,
among other things.



>As far as avoidance of repetitive definitions is concerned, there are
>features (perhaps not clearly presented) of the ASN.1 approach that
>address that.
> 
>John L 


Andy