Re: Examples of ASN.1 for SMIng.txt

[Andy Bierman <abierman@cisco.com>]

At 10:57 AM 12/12/2001, Arnold Jansen wrote:
>With the risk of sounding paternal...


You have been asked more than once to summarize the benefits
of this proposal, in terms of benefits for end-users.
All I keep hearing is "It's ASN.1". 
  
We one level too deep in discussion here.
The real question to be answered is "What advancements
in the state-of-the-art are gained by foo, at what price?"

I think the syntax used to convey the data definition language
is important, but not nearly as important as the actual innovations
added to the SMI. 

There some significant innovations in SMI-DS which
are independent of the syntax used to express them.  I could
translate these SMI-DS features to another syntax, such as XML,
to demonstrate this point, if you want.  

I am not willing to accept the premise that human ease-of-use
is not achievable, or should in any way be sacrificed
for the benefit of MIB compiler writers.

Andy


>Formal notations are never human friendly, and simply created
>to support machine compilation. However, that's the cost of
>avoiding ambiguity. Standards are almost never the best solution 
>technically possibly, because they must represent a consensus and
>come to a conclusion at a given time. ASN.1 has been used as a basis 
>for specifying many standards in the carrier space to specify information 
>models in transport, mobile, voice and data networking.
>
>There in fact quite some commercial ASN.1 tools around if you check
>and in addition many vendors and I guess also service providers have
>developed proprietary compiler back-ends to generate custom implementation
>API code based on formal ASN.1 input. And these tools often relied on
>commercial tools like ISODE to name just one example.
>
>Although with SMI coming more from the networking side and GDMO
>more from the telco side, I hope with SMIng we can as much as possible
>stick to a common and agreed set of atomic data structures to support
>a management convergence story in NGN and see what we can leverage
>from the legacy.
>
>The fact you can point out individual shortcomings in a standard may not
>be a good enough reason for abandoning the philisophy of it. It's probably
>easier to do a small concession now and then to get around the problem
>and avoid the distraction and controversy. If you build an ASN.1.1 we'll
>be for ages in all kind of transition scenarios.
>
>my 2 cents
>
>Arnold
>----- Original Message ----- 
>From: "Andy Bierman" <abierman@cisco.com>
>To: "Olivier DUBUISSON" <Olivier.Dubuisson@francetelecom.com>
>Cc: <sming@ops.ietf.org>
>Sent: Wednesday, December 12, 2001 12:31 PM
>Subject: Re: Examples of ASN.1 for SMIng.txt
>
>
>> At 05:25 AM 12/12/2001, Olivier DUBUISSON wrote:
>> >Andy Bierman wrote:
>> >> 
>> >> 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.
>> >
>> >Put it the other way round: Without ever leaning ASN.1, you've learned a
>> >big part of it anyway. So you're ready to take ASN.1 as the language for
>> >SMIng ;-)
>> >
>> >> So the fact that there is a 'better' ASN.1 out there is
>> >> also irrelevant to me.
>> >
>> >Are you saying that you don't mind using a flawed notation or at least a
>> >notation that is not the best one? Are you saying that you don't mind
>> >burdening the future by keeping away of a powerful technology?
>> 
>> I want the best notation we can get for the least amount
>> of training and development costs.  I don't think the SMIv2
>> syntax is very good, but it is familiar, and it's what we
>> picked many years ago.  I don't want to make a lot of gratuitous 
>> changes to the syntax -- I don't like upper case DESCRIPTION
>> better than lower case, but some things you just have to get
>> as correct as possible the first time.  
>> 
>> >I'm afraid I'm going to be a bit rude (but John Larmouth has been before
>> >me when he wrote that "ASN.1 was not born in the right world"! -- and
>> >please Andy don't take this as an attack against you):
>> >I've not yet seen a good argument against ASN.1. IMO most of the remarks
>> >seem to be along the lines of "We don't want ASN.1 because it is ASN.1".
>> >I honestly hope it is not the case. I don't want to be considered as a
>> >zealot, I just want the contribution to be validated against the
>> >requirements with real/good technical arguments.
>> 
>> I don't want to use ASN.1 because I think it's difficult to read, 
>> difficult to write, not widely used  (either by a large number
>> of people or a significant number of technical domains), and 
>> no substantial body of tools (free or commercial).
>> 
>> Do you have a reason why we SHOULD use ASN.1, other than "it's ASN.1"?
>> 
>> >-- 
>> >Olivier DUBUISSON
>> 
>> Andy
>> 
>> 
>>