Re: Examples of ASN.1 for SMIng.txt

["Arnold Jansen" <arnold.jansen@alcatel.com>]

With the risk of sounding paternal...

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