[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SMIng Access + Syntax ==> Syntax + Method
Per my earlier message regarding changes to range notation, I would like
to go a step further and propose merging the ACCESS and SYNTAX clauses of
SMIv1/SMIv2 into a multi-part syntax + method notation. It seems a fairly
reasonable merge given that ACCESS is currently used to specify allowed
operations, while methods could be used to both specify allowed operations
AND extra information required for those operations (parameters, etc).
This is again a fairly informal proposal, but I can write a more formal
proposal if there is interest. However, it might be easier to write the
proposal as an extension to an existing full SMIng proposal: these
changes are not specific to any particular style (e.g. NMRG's or Andy's
or Jeff's ASN.1-style). Rather, they mainly represent an idea for
a currently non-existant feature to be worked into whatever basic format
is adopted by the WG.
The essential part of the proposed change is for the syntax clause (anywhere
it occurs - textual conventions, object types, compliance/capabilites
statements) to take (1) the data type and (2) an optional list of methods.
Rather than specifying refinements in association with the data type,
refinements are to be specified with the named method.
RowStatus is a very good example. In SMIv2, RowStatus is defined as:
RowStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"..."
SYNTAX INTEGER {
active(1),
notInService(2),
notReady(3),
createAndGo(4),
createAndWait(5),
destroy(6)
}
Missing from the "parseable" part of the definition are the rules regarding
which values can be read, written or both. This information is only
contained within the textual description. Instead, I would propose
the following (though it need not be in this ASN.1-style syntax -- I actually
prefer the NMRG proposal, but I'll get into that a little later):
RowStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"..."
SYNTAX INTEGER {
METHOD read-write {
active(1),
notInService(2)
}
METHOD read-only {
notReady(3)
}
METHOD write-only {
createAndGo(4),
createAndWait(5),
destroy(6)
}
}
Or, in NMRG-SMIng style:
typedef RowStatus {
type Enumeration {
method read-write {
active(1)
notInService(2)
};
method read-only {
notReady(3)
};
method write-only {
createAndGo(4),
createAndWait(5),
destroy(6)
};
};
description "...";
};
A couple of things are accomplished with this: most significantly, each
value has associated with it rules regarding the operations to which it
applies. It's now in a parseable format that you can never read the
values 4, 5 and 6 and you can never write the value notReady. Also,
because the typedef now has ACCESS type information in it, it should no
longer be necessary to define the MAX-ACCESS info for an object whose
syntax is RowStatus. Take usmUserStatus for a random example:
usmUserStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "..."
::= { usmUserEntry 13 }
MAX-ACCESS becomes basically redundant, other than the fact that it's
"read-create" instead of "read-write" (but proper method names could
take care of that problem). All RowStatus objects should pretty much
have the same MAX-ACCESS (what use would a read-only RowStatus object
be?), so the access/method rules can be inherited from the RowStatus
definition:
usmUserStatus OBJECT-TYPE
SYNTAX RowStatus
STATUS current
DESCRIPTION "..."
::= { usmUserEntry 13 }
If for some reason you DID want to define a read-only RowStatus object,
the same SMI syntax used in the textual convention could be used here:
usmUserStatus OBJECT-TYPE
SYNTAX RowStatus {
METHOD read-only
}
STATUS current
DESCRIPTION "..."
::= { usmUserEntry 13 }
Another place where this would be useful is USM's KeyChange textual
convention, which always returns a zero-length string when read, but
can only be written with a non-zero-length string. This could be
represented by the following example:
KeyChange ::= TEXTUAL-CONVENTION
STATUS CURRENT
SYNTAX OCTET STRING {
method write-only [0]
method read-write
}
(Note: I've used the bracketed size/range notation of my earlier message
here. In SMIv1/v2 terms it'd be (0) instead of [0].)
Unfortunately, this doesn't fit too well with the class/attribute syntax
of the NMRG proposal. But you could, I suppose, still replace attribute's
"access" statement with one-or-more "method" statements. e.g.
class className {
attribute typeName attribName {
method read-only {
...
};
method read-write {
...
};
};
};
As well, you could get away with breaking it the "METHOD" statement out
of "SYNTAX" in the ASN.1 style, and directly replacing MAX-ACCESS with it;
but it makes the association of the enumerations/refinements with the
data type a little less clear that way.
Something that the NMRG proposal does lend to this method syntax, however,
is using the semicolons to specify the end of the method definition.
Obviously if methods are going to be able to carry additional semantics,
such as parameters for creation, then additional fields will be needed.
Something else that the NMRG proposal lends to this method proposal is
the "extension" statement. I would say it would be very useful for
different SMIng-based extensions to be able to define their own
named methods. SNMP has read-only/read-write/read-create/etc., but
another SMIng-based extension may not. So, I would propose adding a
'syntax' statement to 'extension'. The format would be approximately the
same as that for everything else. However, the data type specified would
indicate the type of result provided by the protocol in response to each of
the named methods.
Example:
extension snmp {
description
"The snmp statement maps SMIng definitions to SNMP
conformant definitions.";
abnf " ... ";
syntax Enumeration {
method read-only;
method write-only;
method read-write ::= { read-only, read-write };
...
};
}
The above example indicates that operations in SNMP return an enumerated
type (which error-status can be considered), and defines a few of the
SNMP-specific ACCESS types as methods. I've also indicated a possible
example where one named-method represents the union of two other methods,
though that's probably not particularly necessary. Each method statement
could have other fields such as a description, return values (for
protocols that have values that apply to different operations, like
notWriteable only applies to SET operations in SNMP), and possibly an
abnf field for additional protocol-specific information.
FInally, besides operation-specific constraints on values, and return
values for operations, it would of course be useful to be able to
specify parameters associated with the method. This could be done with
an optional "parameters" field that follows, but is part of, the
"method" statement in an object definition. If, for example, you had
a table in which certain values must be set to create a row, you
could specify them in the RowStatus-based object. e.g.
rowStatusObj OBJECT-TYPE
...
SYNTAX RowStatus {
method read-only // no parameters for read-only values
method read-write // no parameters for read-write values
method write-only [4] // createAndGo with 3 required parameters
params { columnOne, columnTwo, columnThree }
method write-only [5] // no parameters for createAndWait
}
::= { ... }
At any rate, those are the essentials of what I'm proposing. I appologize
for the possibly scattered nature of this message. It is mainly intended
to introduce some ideas for discussion, and not be a formal proposal.
In order to put together a more formal proposal it really should focus on
being incoporated in a particular overall SMIng proposal.