[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Examples of ASN.1 for SMIng.txt
Hi Frank,
I am working to produce a larger and richer example of using our proposed
notation. This example should show more clearly some of the benefits.
Meanwhile, I will respond to your comments. See below.
----- Original Message -----
From: "Frank Strauss" <strauss@ibr.cs.tu-bs.de>
To: <j.larmouth@salford.ac.uk>
Cc: <sming@ops.ietf.org>
Sent: Thursday, December 06, 2001 12:19 AM
Subject: Re: Examples of ASN.1 for SMIng.txt
> Hi!
>
> John> I subscribed to this list in the expectation of some discussion
> John> of the solution proposed by Alessandro Tiglia in this mail and
> John> his ealier mailing of an Internet Draft, but there seems to have
> John> been little comment.
>
> John> The solution appears to meet all requirements, and I understand
> John> that a decision will be taken on rival options next week.
>
> John> Does silence on the mailing list mean assent, or simply that
> John> people are too busy?
>
> I can state just a rough first-sight impression on
> draft-triglia-sming-asn1-sming-01, because I did not yet read it
> careful enough for more detailed pros and cons.
>
> However, I think it is good and hard piece of work and it gives us an
> impression how a new SMI could look like, if it's based on the current
> ASN.1. I see some of the requirements well fulfilled, while others seem
> to be unsolved, e.g.
> - the different requirements of SNMP and COPS-PR mapping (different
> OID registrations, different table indexing, ...) are not addressed.
> - Another issue has been stated by Andy: I regard the syntax to be
> too complex und uncommon with respect to what IETF people and NMS
> programmers are used to know. This is probably simply due to the
> ASN.1 compatibility.
> Here are some more comments based on a small part of the examples
> posted by Alessandro (please take into account, that I'm not familiar
> with the I-D):
>
> ----------------------------------------------------
> Example 1
> ----------------------------------------------------
>
> 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?
Yes, it is. However, if used, this addresses the objective "4.1.9 Namespace
Control Description: There must be a hierarchical, centrally-controlled
namespace for standard named items, and a distributed namespace must be
supported to allow vendor-specific naming and to assure unique module names
across vendors and organizations. Motivation: Need to unambiguously
identify definitions of various kinds. Some SMI implementations have
problems with different objects from multiple modules but with the same
name. Furthermore, the probability of module name clashes rises over time
(for example, different vendors defining their own SYSTEM-MIB)."
>
> DEFINITIONS AUTOMATIC TAGS BEGIN ::=
>
> -- From the SMI application point of view: 5 useless tokens.
"AUTOMATIC TAGS" is meaningful in ASN.1 and is especially useful when a
SEQUENCE or CHOICE is defined in the module. Basically, it simplifies the
ASN.1 syntax by eliminating the need to insert a tag (such as [1], [2], ...)
on each component of the SEQUENCE or CHOICE.
In our proposal, SEQUENCEs are used to define the structure of table rows or
other kinds of aggregations, and CHOICEs are used to define unions. Even
though today's protocols are oriented to transferring elementary values, the
use of the full ASN.1 type system makes it possible to build
arbitrarily-complex data structures, well beyond the flat tables of SMIv2.
Accordingly, two object naming schemes are provided. One naming scheme
models the traditional SMI naming scheme, in which the OID components that
identify a row of a table are appended to the OID that identifies a columnar
object. The other naming scheme serves to assign OIDs, in a hierarchical
fashion, to each component of any arbitrarily complex data type, that cannot
be reduced to a flat table. In the latter case, the OID that identifies the
"entity instance" (a complex MIB variable) serves as a root OID, and one or
more OID components are concatenated to this root OID for each nesting
level.
The proposed notation provides a means to specify these options and to
specify what OID components are to be added for each component of the
structure. These OID components are specified as values of type
RELATIVE-OID, a new datatype recently added to ASN.1.
>
> 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.
Not a real problem. The IMPORTS clause is included here for completeness,
however there is only one ASN.1 module from which the definitions are
imported. As a convention, this clause may be eliminated.
>
> module-info MODULE-INFO ::= {
>
> -- From the SMI application point of view, this is useless.
I don't understand this comment. From the Objectives: "4.1.10 Modules
Description: SMIng must provide a mechanism for uniquely identifying a
module, and specifying the status, contact person, revision information, and
the purpose of a module." If you mean that the "module-info" name itself is
useless... sorry, this is needed by the ASN.1 basic syntax.
>
> 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
We simply chose a format (GeneralizedTime) similar to the old one. Nothing
keeps us from changing it into a more-readable format.
> -- BTW: The above line would make an ASN.1 parser complain about junk
> -- right after the second pair of hyphens, right? See requirement 4.2.4.
Well, requirement 4.2.4 is actually "nice-to-have". Anyway, a new format for
multiple-line comments (/* */) has been recently introduced in ASN.1 and is
available.
>
> DESCRIPTION "Latest Revision - Aaa bb c ddddd" } |
>
> { DATE "200007030917Z"
> DESCRIPTION "First Version" } }
>
> STATUS current
> DESCRIPTION "This is an example MIB module" }
>
>
> fizbinChipSets NODE ::= {
> OID { someRoot 1 }
> STATUS current
> DESCRIPTION "Fizbin Chip Sets" }
>
> fizbinChipSetsOid OBJECT IDENTIFIER ::=
> { fizbinChipSets.&oid 1 }
>
> -- What does this `.&oid' mean? To me, this does not look intuitive.
It is ASN.1 again. If "fizbinChipSets" had been defined as an OBJECT
IDENTIFIER value (not as a NODE as it is), then we would not have the
".&oid" stuff. In this example, "fizbinChipSets" is an "information
object", a container for some kind of information expressed in ASN.1
notation. As such, it is not an OID in itself, but *contains* an OID in one
of its fields. The ".&oid" is there to designate the OID value contained in
"fizbinChipSets".
Note that "information" objects were introduced in ASN.1:1994 and replaced
(and obsoleted) the old ASN.1 macro notation. Information objects are
rigorously defined and can easily express relationships between values,
ASN.1 types and other kinds of information, including other information
objects and information object sets.
In general, information objects present a very readable syntax, as you can
see from most lines of these examples.
>
> fizbin69 NODE ::= {
> OID { fizbinChipSetsOid 1 }
> STATUS current
> DESCRIPTION "The authoritative identity
> of the Fizbin 69 chipset." }
>
> END
>
>
> ----------------------------------------------------
> Example 2
> ----------------------------------------------------
>
> evalSlotClass ENTITY-CLASS ::= {
> SYNTAX Integer32 (0..2147483647)
> STATUS current
> DESCRIPTION "The entity class of an index number
> for an entry in the evaluation table" }
>
>
> evalTableClass ENTITY-CLASS ::= {
> SYNTAX SEQUENCE OF evalEntry-class.&Syntax
>
> INDEXING-ATTRIBUTES {{1}}
> NAMING-SCHEME tabular
>
> STATUS current
> DESCRIPTION "The (conceptual) evaluation table." }
>
>
> evalEntryClass ENTITY-CLASS ::= {
> SYNTAX SEQUENCE {
> evalIndex Integer32,
> evalString DisplayString,
> evalValue Integer32 DEFAULT 0,
> evalStatus RowStatus DEFAULT active }
>
> -- Some attributes/characteristics are described in the SEQUENCE, others
> -- in the ATTRIBUTE-INFO block. This looks inconsistent to me.
In our model, an "entity class" has several properties, and one of them is
the ASN.1 type of the values. Other properties are the description, status,
etc. of the entity class. If an entity class is based on a complex ASN.1
type such as a SEQUENCE or a CHOICE, the components have properties of their
own, which are also listed. Among these is the RELATIVE-OID assigned to each
component of the SEQUENCE or CHOICE, which is used in forming the complete
OBJECT IDENTIFIER of SNMP-accessible objects.
This arrangement is optimal in that it allows the users to design
arbitrarily-complex data structures purely in terms of ASN.1 types
(SEQUENCEs, CHOICEs, "SEQUENCE OF"s).
(This has been carefully pondered. An alternative solution could have been
to express the structural relationships by using some specially defined
syntax, as opposed to using the basic ASN.1 syntax for defining structured
types. The result would probably be logically-limited and difficult to
implement.)
Summarizing, the users would design any arbitrarily-complex data structure
by using ordinary ASN.1 constructs, availing themselves of a powerful and
mature notation, which, among other things, allows re-use of type
definitions and inheritance of SEQUENCEs. All the designed data types would
then be wrapped into "entity classes" and assigned properties such as
accessibility, description, status and relative identifiers. Later
(conceptually), "entity instances" are defined from "entity classes".
Entity instances are the actual "variables" that exist in a MIB, are named
by OBJECT IDENTIFIERs, and can be either scalars (based on simple types or
on SEQUENCEs or CHOICEs of simple types), flat tables (based on "SEQUENCE
OF"s of SEQUENCE whose components are simple) or any arbitrarily-complex
data structures.
>
> ATTRIBUTE-INFO {
> { ATTRIBUTE {1}
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION "The auxiliary variable used
> for identifying instances of the columnar
> objects in the evaluation table." } |
>
> { ATTRIBUTE {2}
> MAX-ACCESS readCreate
> STATUS current
> DESCRIPTION "The string to evaluate." } |
>
> { ATTRIBUTE {3}
> MAX-ACCESS readOnly
> STATUS current
> DESCRIPTION "The value when evalString
> was last evaluated, or zero if no
> such value is available." } |
>
> { ATTRIBUTE {4}
>
> -- I guess these ATTRIBUTE numbers represent the column identifiers
> -- and all attributes are included in the protocol mapping. This is
> -- problematic, since e.g. RowStatus objects would not be mapped to
> -- SPPI compatible tables.
These numbers are "attribute identifiers", of type RELATIVE-OID (this is why
there are curly brackets around the numbers). In these examples, the
attribute identifiers have only one component, which is a simple progressive
integer, but they can have more components and don't need to be ordered,
thus allowing more-complex naming schemes.
The attribute identifiers are assigned by an optional "ATTRIBUTE-IDS" clause
that is not included in these examples (it defaults to "{{1}, {2}, {3},
etc.}" ). They are used in the ATTRIBUTE clauses to reference the
attributes whose properties are specified.
>
> MAX-ACCESS readCreate
> STATUS current
> DESCRIPTION "The status column used for
> creating, modifying, and
> deleting instances of the columnar objects
> in the evaluation table." } }
>
> STATUS current
> DESCRIPTION "An entry (conceptual row)
> in the evaluation table." }
>
>
> evalSlot ENTITY-INSTANCE ::= {
> OID { eval-base 1 0 }
> ENTITY-CLASS evalSlotClass
> MAX-ACCESS readOnly
> STATUS current
> DESCRIPTION "An entity instance that is the index
> number of the first unused entry in the
> evaluation table" }
>
>
> evalTable ENTITY-INSTANCE ::= {
> OID { eval-base 45 }
> ENTITY-CLASS evalTableClass
> MAX-OPERATION createDelete
> STATUS current
> DESCRIPTION "An instance of the evaluation table" }
>
> -- IMHO, this looks way too complicated to define just a simple table.
We have defined an entity class for a table and an entity class for a row,
then a table entity instance. Let me compare this with other SMIng
proposals.
In the syntax described in the NMRG proposal, a "class" would be defined,
then a "table" implementing the class would be instantiated. Instead, our
proposal has no means to instantiate a table from a row class: a table can
only be instantiated from a table class. This has been judged more
consistent, and gives the benefit of ease of re-use. The entity class of the
row can be re-used as a component of an outer SEQUENCE, CHOICE, or can be
re-used in a different table, possibly with a different naming scheme or
with a different set of indexing attributes. The type of the table can be
re-used as a component of an outer SEQUENCE, CHOICE, etc., to form a complex
aggregate containing other aggregates (tables, etc.). This is much like
building complex structures in C by using hierarchies of "typedef", and then
defining one single variable of that type. This "variable" is what goes into
the MIB.
In the syntax described in Bierman's proposal, an "array" can be
instantiated from a "typedef array", or can be defined completely in-line.
We believe that our arrangement is more aligned with some important
Objectives, specifically 4.1.27 "Attribute Groups", 4.1.30 "Reusable vs.
Final attribute groups" and 4.1.44 "Assign OIDs in the Protocol Mappings".
Specifically, we believe that an array type should be based on a re-usable
row type, rather than being a completely separate thing.
Alessandro
>
>
> -frank
>
>