[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on draft-bierman-sming-ds-02.txt
[DISCLAIMER]
We have read the document in detail from page 1 to page 31 and we have
written down comments/questions in that order. So the answers to some
of these questions became clear later on but we have left them
untouched since we are lazy.
[DISCLAIMER]
SMI-DS is used to refer to Andy's SMI-DS and SMIng is used to refer to
the SMIng which originated in the NMRG.
1. The document sometimes uses terminology without explanations so that
the reader has to guess what precisely the meaning is. For example,
page 4: multi-layer data structure
Is this a nested data structure such as a struct within a struct?
And if so, what kind of nested data structures are allowed? Note
that it is relatively straight-forward to "flatten" nested structs
in SMIv2 but it requires tables if there is a nested array.
2. The distinction between objects and types is unclear. Our understanding
is that an object is something which I can instantiate while a type is
something which just describes the structure (and perhaps just for the
purpose of reusing the type).
3. We prefer the following terms
o "constructed type/object" for something which contains other types/objects
o "base types" for primitive base types provided by the language (Integer32)
o "derived types" for types that are derived from other base types or
constructed types.
We suggest to avoid "complex types/objects" since this term can be
mis-leading.
4. We find the terms "MIB Object" and "Data Object" confusing, especially since
the meaning of "SMI Data Structure variable declaration" is not explained.
What is the difference to a "SMI Data Structure Definition"?
5. We find the difference between "Scalar" and "SCALAR" a bit
confusing. We believe that SMI-DS "SCALARS" are what SMIng calls
an attribute while "Scalars" are what SMIng calls scalars.
6. We are not sure whether the goal of 100% forward and backward
compatibility has been reached or to what extend. The SMI-DS
translation to SMIv2 is not really defined in Appendix A and thus
it is hard to judge how much is in fact translatable (and what the
compatibility implication on the wire will be).
7. It is unclear whether compatibility on the wire between engines
that use SMIv2 style definitions and engines that use SMIng style
definitions (and naming) is still a design objective.
8. The proposed new naming touches both the language and the protocol,
at least in the sense that no existing implementation we are aware
of will be able to handle hierarchically named variables in a
meaningful way. We would expect that 100% forward/backward
compatibility implies that I can use existing tools to look at data
implemented by an agent whose implementation is based on an SMI-DS
MIB module.
9. We believe that a syntax which looks close to SMIv2 but means
sometimes something different is worse than a syntax which looks
different to SMIv2 and means something different. People who do not
understand the differences will merge SMIv2/SMI-DS in arbitrary
ways. This has happened with SMIv1/SMIv2.
10. We believe it should be a design goal that accessible data objects
can be used with existing SNMP applications (which is more than
just existing versions of SNMP) - which probably implies no
changes in the naming. Note that SMIng does the naming in the
protocol specific mappings. Supporting SMI-DS naming in protocols
would from this viewpoint be another protocol mapping.
11. We believe that "SCALAR" is a confusing name, but we do not really
have a much better proposal (leaf object? leaf variable? leaf
member?). In SMIng, we would perhaps call them leaf attributes.
Having a name for this would help to make definitions easier to
understand.
12. We do not understand what "only SCALAR data objects are actually
accessible via a management protocol" actually means. Does it
imply that I can not manipulate a constructed type? Do I have to
get/set all the leaf attributes of a constructed type? Can I do
walks over constructed types or can I only do walks over the leaf
attributes that represent parts of a constructed types?
13. We believe that an array should be similar to an ASN.1 SEQUENCE OF,
that is the array feature should work with an arbitrary type. The
SMI-DS ARRAY mixes containment and multi-valuedness in one
construct. Programming languages such as C and even ASN.1 do not
do this. Arrays do not yet exist in SMIng (only in the form of
tables in the protocol mappings).
14. We expect that not only base types, but also derived types should
be allowed in index clauses (just constructed types are not
allowed).
15. We agree with the intention of the UNION, although the definition
can be improved. You do not need the discriminator since you
encode this information in the SMI-DS names. So in fact, you have
some sort of an "implicitly discriminated union." Unions do not
yet exist in SMIng.
16. We believe that SMIng achieves a much clearer and thus simpler
separation of potentially reusable type definitions and variable
declarations.
17. The relationships to SMIv2 are interesting. You change
NOTIFICATION-TYPE to NOTIFICATION for language consistency
reasons, which we have sympathy for. I am sure someone else will
see this as a gratitious change. You also claim that lots of other
constructs do not change as well, including MODULE-COMPLIANCE.
Even if this is true for the syntax (which I am not sure of), I am
sure that semantics will have to change.
18. Since there are not table/entry definitions anymore, how do you
create names for them when translating to SMIv2 and what happens
if there are name clashes with other definitions?
19. There is a need for a mechanism to disambiguate descriptors or
identifiers. For example, assume you have an ARRAY which contains
two members of the same STRUCT type and you want to refer to one
of the STRUCT members in a notification definition. SMIng provides
the necessary infrastructure for this and this alone affects
several statements/clauses/macros/constructs (whatever you name
it).
20. It is unclear how much savings the new naming scheme provides on
agents. With SMI-DS, you probably have fewer RowStatus objects
since you do not need them for "contained" multi-valued
attributes. You also can improve code stubs since the compiler now
knows that one table is really just used to hold multi-valued
attributes of some other object. We fail however to understand why
the hierarchical naming simplifies things such as (a) reducing the
degrees of ordering freedom we have in SNMP or (b) reducing the
need to have createAndWait/notInService states in the first place.
21. We agree with the idea to hold compliance information in the
agent. However, we do not understand the value in introducing
"pseudo OIDs". Why are conformance definitions not being kept in a
properly indexed conformance table? Conformance data is just data
and there should be no need for a special mechanism for this
purpose. The pseudo OIDs may give funny results when you do
getnext walks. (Also, the restriction that you can report
conformance to only a single compliance definition might hurt if
conformance statements are revised and you need to report multiple
compliance statement OIDs for continued interoperation.)
22. We do not understand what "Non-SCALAR Static Sub-Identifier
Naming" is and how it relates to "Non-SCALAR Data Object
Naming". We assume that the first refers to the portion of the OID
which depends on the data type without the instance information
while the second one extends this with instance identifier
encodings.
23. Example 5.7.1:
- There is no status associated with the TYPEDEF itself. Why not?
- More general: Should access clauses only be used when names are
assigned to reusable data types? Specifying that an attribute is
read-only in a type definition complicates reuse. This affects
both SMIng and SMI-DS.
- Hierarchical naming shows an advantage here because it
implicitly provides the discriminator in the name portion of a
union varbind element.
- It is unclear how unions map to SMIv2 if the SCALARs of the
union happen to use different base types.
24. Example 5.7.3:
- Would the example still work if an interface would first be
defined as a constructed type which is than assigned to a
variable or would this cause incompatible OIDs?
- We do not understand why there is a need for a new SIZE clause.
- We think that the introduction of INDEX clauses in parallel to
the SCALAR clause complicates things. This leads to several
special cases. How is the ordering of index components defined?
See for example the rules for MAX-ACCESS in INDEX clauses and
the optionality of subid assignments. We think it would be
simpler to keep the old notion of a separate index definition.
- Is it a bug or a feature that there are no STATUS clauses in
INDEX definitions?
25. Data structure augmentations:
- What is the expected value of introducing SPARSE-CONDITION and
SPARSE-EXPRESSION?
- SPARSE-CONDITIONS can also go into normal description clauses
since it is just free form text. How do we decide that some text
is so important that it justifies its own clause?
- Regarding SPARSE-EXPRESSION, what is the intended usage? Is it
just documentation clarity? Is the intention to support
automatic test tools? Do these machine readable expressions
significantly simplify/improve code generators? And what after
all does the expression language look like?
26. Augments Example:
- We guess that the SIZE clauses in the definition of inetAddrType
and inetAddr are just cut & paste errors.
- We are still undecided what the added value of arrays is. It
looks like SMI DS arrays are pretty close to tables except that
they can conceptually be embedded due to the hierarchical naming
scheme.
27. The VAR STRUCT format is unclear. It sometimes contains other
SCALAR/STRUCT/UNION/ARRAY clauses (see ipXStats example) and
sometimes it just contains flat SYNTAX etc. clauses (see myAddress
example). From reading the grammar, it looks like both are
allowed? What is the difference between both formats in case I
just have a single STRUCT, except that you safe a few lines in
some cases?
28. The ID says that pointers can be used to reference complex data
objects. It is unclear how this works. How do I reference
entSensorData[17]? Where does the instance identifying portion of
the OID value start?
29. Pointers may refer to derived types which is not yet allowed in
SMIng but seems to be a good addition.
30. What is the purpose of the UNIQUE-SCOPE clause and what are the
benefits of making this particular piece of information machine
readable?
/js
-frank
--
Juergen Schoenwaelder <http://www.informatik.uni-osnabrueck.de/schoenw/>
Frank Strauss <http://www.ibr.cs.tu-bs.de/~strauss/>