[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Examples of ASN.1 for SMIng.txt
Frank Strauss wrote:
>
> 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.
You are right on the fact that, syntactically speaking, external
references only use the module name, but when a module header is used,
the namespace is available by way of the IMPORTS statement in which
both the module name and its OID are used. The advantage of this is
that the module body is kept simple by using the module name only.
> >> 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.
I've just given a reason to have a module header.
However I could understand that some people might like to only have a
module body with assignments and no header. But is it really a big
problem?
> >> 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.
I don't think so. People who have "pure SMIng" tools could only use the
module body (i.e., the assignments), making the assumption that their
tool has the knowledge of these imported pre-defined types.
People (like me) who would like to check their SMIng definitions with
the ASN.1 tools that they already have without having to implement/buy/
download a SMIng tool would need that IMPORTS statement plus the ASN.1
module where the pre-defined types are defined.
Am I clear?
For example, that would allow SMIng designers to use OSS Nokalva's
syntax checker that can be freely downloaded from their website, that
is, use
the full power of ASN.1 (or be able to use it at any time if needed in
the future) and benefit of the tools that are in place.
> >> 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.
Well... I wish that all the people who think that all tokens are
useful in XML are listening to you ;-)
More seriously, I understand your point, but having the 2 above tokens
or a keyword that indicates that you are giving the module-info doesn't
make a big difference IMHO.
> >> 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,
I guess you mean UTCTime.
> which is not very human-friendly, or a non-standard
> approach.
Not at all. As you mentioned, there are 2 standardized time types in
ASN.1 but I know of a lot of standards that have choosen to design their
own time types. Same story with the REAL type.
> 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.
Which complexity?
--
Olivier DUBUISSON
France Telecom R&D
_ DTL/MSV - 22307 Lannion Cedex - France
( ) tel: +33 2 96 05 38 50 - fax: +33 2 96 05 39 45
/ \/ --------------------------------------
\_/\ Site ASN.1 : http://asn1.elibel.tm.fr/