Re: Examples of ASN.1 for SMIng.txt

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

>> FIZBIN-MIB { iso(1) identified-organization(3) dod(6) internet(1)
>> private(4) enterprises(1) asn1(11502)
>> applications(1) sming(1) example-module-1(1001) }
>> 
>> -- This OID based modules identification is still optional, right?


Alessandro> Yes, it is. However, if used, this addresses the objective
Alessandro> "4.1.9 Namespace Control [...]"

Please correct me, if I'm wrong. I think this unique module namespace by
OID would only be helpful, if module references would be based on it. But
as far as I know, they are not. At least, in SMIv2 absolutely qualified
definitions are based on a module prefix, e.g. `SNMPv2-TC.DisplayString',
and not on an OID.

>> 
>> DEFINITIONS AUTOMATIC TAGS BEGIN ::=
>> 
>> -- From the SMI application point of view: 5 useless tokens.


Alessandro> "AUTOMATIC TAGS" is meaningful in ASN.1 and is especially
Alessandro> useful when a SEQUENCE or CHOICE is defined in the
Alessandro> module. Basically, it simplifies the ASN.1 syntax by
Alessandro> eliminating the need to insert a tag (such as [1], [2],
Alessandro> ...)  on each component of the SEQUENCE or CHOICE.

Thanks for the explanation. I was just talking about the usefulness of
the words `DEFINITIONS AUTOMATIC TAGS BEGIN ::=' just from the SMI
point of view. I have no doubt, that in ASN.1 context it is meaningful.


>> IMPORTS Integer32, SMICharacterString,
>> MODULE-INFO, ENTITY-CLASS, EVENT,
>> ENTITY-INSTANCE, NOTIFICATION,
>> NODE, NODE-GROUP, COMPLIANCE-STATEMENT
>> FROM ASN1-SMIng;
>> 
>> -- We don't want to require SMIng core language keywords to be imported.
>> -- Requirement 4.1.41.

Alessandro> Not a real problem. The IMPORTS clause is included here
Alessandro> for completeness, however there is only one ASN.1 module
Alessandro> from which the definitions are imported. As a convention,
Alessandro> this clause may be eliminated.

But then this would be a convention that would vioalate against ASN.1
rules, right? One consequence would be, that (at least some) ASN.1 would
not work for this application. In the end, we would loose many advantages
that we could have, if SMIng would be based truely on ASN.1. We already
have made this bad experience with SMIv1 and v2.

>> 
>> module-info MODULE-INFO ::= {
>> 
>> -- From the SMI application point of view, this is useless.

Alessandro> I don't understand this comment. 

As with `DEFINITIONS AUTOMATIC TAGS BEGIN ::=' here the tokens
`module-info MODULE-INFO ::= {' do not contain any useful information
from the SMI point of view.



>> 
>> ORGANIZATION "ACME MIB Writers Ltd"
>> 
>> CONTACT "Last Name First Name
>> My Street
>> My City
>> My State"
>> 
>> REVISIONS {
>> { DATE "200111301240Z"
>> 
>> -- We would like to have a more human friendly date format, e.g. based
>> -- on the ISO format, to make such comments unnecessary:  -- 30 Nov, 2001


Alessandro> We simply chose a format (GeneralizedTime) similar to the
Alessandro> old one. Nothing keeps us from changing it into a
Alessandro> more-readable format.

Again, a trade-off to use either the ASN.1 standard GeneralizedTime or
UniversalTime, which is not very human-friendly, or a non-standard
approach.


[...]


Alessandro, thanks for your good explanations of some ASN.1 details and
those details of your proposal. I see some value in your more consistent
approach of specific entity classes and table classes. But in the end,
IMHO the complexity does not do the user any favor. That's just my
impression.


 -frank