[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
DEFINITIONS AUTOMATIC TAGS BEGIN ::=
-- From the SMI application point of view: 5 useless tokens.
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.
module-info MODULE-INFO ::= {
-- From the SMI application point of view, this is useless.
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
-- 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.
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.
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.
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.
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.
-frank