Re: Process for SMIng Syntax Proposal Submissions:

[Andy Bierman <abierman@cisco.com>]

At 04:02 PM 11/6/2001 +0100, Frank Strauss wrote:
>Hi Andy!
>
>Andy, here are some thoughts that came to my mind, while I read your
>example a second and third time. I know, some of them are really
>nit-picking at this point in time, and we should not get lost discussing
>these details too much. However, I would like to mention them as well.
>
>I know, that you're already working on a revision and refinement of
>your grammar.  Hence, some of my comments may be pointless.


I made lots of changes to the proposal.
I wrote the proposal up as an I-D, which is now available:

       A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


         Title           : Structure of Management Information: Data Structures
         Author(s)       : A. Bierman
         Filename        : draft-bierman-sming-ds-00.txt
         Pages           : 46
         Date            : 05-Nov-01

     This memo defines a portion of the Structure of Management Information
     (SMI) for use with network management protocols in the Internet
     community.  In particular, it describes a new structure and naming
     scheme for network management information, allowing the specification of
     arbitrarily complex hierarchical data structures.

      A URL for this Internet-Draft is:
      http://www.ietf.org/internet-drafts/draft-bierman-sming-ds-00.txt



>- At some points, your grammar looks a bit inconsistent to me: Some
>   statements end with a semicolon. Others don't (the OBJECT IDENTIFIER
>   assignments within the new NODES container). Most statement start
>   with a keyword. Others don't, e.g. again the OBJECT IDENTIFIER
>   assignments.


I took out the semicolon completely.
After days of playing with the syntax, it looked just another thing
for authors to get wrong -- missing ; or extra ;


>- Some tokens of the grammar are redundant, e.g. in MODULE-INDENTITY {
>   ... } ::= { ... }, the `::=' token looks unnecessary to me.


Possibly, but the ::= is pretty well known in SMIv2 for assigning an
OID mapping to a construct


>- `TYPEDEF SCALAR' looks a bit confusing to me. The construct intends
>   to define a type (which can be used for scalar as well as columnar
>   objects). Hence I would just call it `TYPEDEF'.


Possibly -- but a base-type needed to be called something.
Maybe just BASETYPE.


>- `TYPEDEF CLASS' intends to define a class, not a type. The concept
>   of classes is well known to many people and the common keyword is
>   simply `CLASS' (at least in C++ and Java).


That's why I changed the name to STRUCT


>- The ARRAY's INDEX container contains SYNTAX and SIZE, which looks a
>   bit redundant to me: In case of integer indexed arrays, either
>   an appropriate SYNTAX clause with a certain range _or_ a SIZE clause
>   (which would imply that indexing starts at 0) would make sense. If
>   also associative arrays shall be supported, a SIZE clause would not
>   make sense, I guess.


The SIZE clause says how many instances can exist in the ARRAY
(for that INDEX. The SYNTAX clause says what the format of the
INDEX is. SIZE is the number of instances, regardless of type.


>- Within the ARRAY container you use the word SCALAR, although this
>   is not a scalar object (as we used the term before).


Just like C -- complex 'container' objects (struct, union) contain
data objects of some base type.  In the draft I distinguish between
scalar (SMIv2 non-tabular object) and a SCALAR (any data object
with a SYNTAX clause that resolves to a base-type).


>- I think the concept of defining a class and within that class an
>   array and within that array `scalars', does really not look
>   intuitive to me and to the joe random user, I guess. I think, the
>   usual terminology is to define a struct or class with a set of
>   variables or attributes.


It looks very intuitive to me, but I've been writing in C for over
20 years, and SMI for only 10.

Unfolding data structures into tables, which are glued together
with INDEX clauses and lots of extra text in DESCRIPTION clauses
does not seem intuitive to me.  If a list of attributes itself
includes a list or other structure, then a separate SMIv2 table
has to be defined.  All these related tables can make implementation
harder for agent and application developers.


>- I think it's absolutely vital to allow the new data model to
>   describe MIBs so that they are completely equivalent to existing
>   SMIv2 MIBs.  In your example, some pieces of information is
>   missing. Some of them are less important, e.g. the name of the
>   XXXEntry node of every table (which is also missing the NMRG based
>   proposal).


I am proposing that we toss ASN.1 SEQUENCE.
These flat arrays are tinker-toy data structures and we need
something more expressive (see the draft for details).


>- In the bottom half of your example there are various mixtures of
>   ARRAY and CLASS contructs. Which of them is your favourite that we
>   should discuss more closely? ;-)
>
>
>
>Furthermore, here are some comments to your additonal notes:
>
>Andy>    Object Instance and Object Definition distinctions
>Andy>    are not made with the namespace, but rather with
>Andy>    different pointer types
>
>I did not recognize where these pointer types appear in your example.
>Can you explain?


They aren't in the example, but we already have this in SMIv2.
Just declare a TC that's an, OBJECT IDENTIFIER, RowPointer,
or VariablePointer.


>Andy>    Instance Identifiers are variable length, in that
>Andy>    not all the object instances (accessible via SNMP Get)
>Andy>    within a high-level object have the same number
>Andy>    of OID components.
>
>Hm. I think, it's essential to keep the semantics of OIDs unchanged.
>Otherwise the SNMP protocol would be affected, and many SNMP
>implementations would have to be modified to support the new scheme.


The SNMP protocol is not affected by my proposal.
OIDs are still OIDs in SMI-DS, except the order is a little different.
SNMP (thankfully) does not depend on the particular sequence
of integers in a varbind to work.


>Andy>    Scalar instances do not end in .0. This gets ugly
>Andy>    when arbitrary containment is introduced, so it's
>Andy>    better to leave off the last zero on scalars.
>
>Scalarsdo not appear in containment, anyway. Again: I think, we should
>not change the OID semantics.


What changes with OID semantics that affects SNMP?


>Andy>    INDEX components are encoded inline, after the object ID,
>Andy>    but fragmented, depending on the data structure definition.
>Andy>    This allows for arbitrarily complex nested containment,
>Andy>    but the instance components are not all grouped together
>Andy>    at the end.
>
>I don't understand this paragraph.


Look in the draft, section 5.5


>Andy>    For all TYPEDEFs:  TYPEDEF FOO fooName { ...  };
>Andy>    There is no OID assignment between the right brace
>Andy>    and the semi-colon;
>
>I agree. As before, types (TCs) are not registered.
>
>Andy>    For all objects within a typedef (except INDEX clauses):
>Andy>          FOO { ... } ::= N;
>Andy>    N is the number of the child sub-component,
>Andy>    simply relative to the parent object, not hard-assigned
>Andy>    from the root.
>
>Ok. I like the concept of specifying just single sub-identifiers as
>column-identifiers relative to an implicitly defined common parent
>node.


The extra text is cruft.
One rule of thumb I used in the design:
    If there is only one possible variant of some text in all scenarios
    then we don't need it. In this case, the "{ fooEntry N } is always
    the same, except for N.


>Andy>    For all FOO declarations (no TYPEDEF keyword:
>Andy>         FOO { ... } ::= { <any valid OID expression> }
>Andy>    This is an objectect instance declaration, and must have
>Andy>    a valid MIB root assignment.
>
>I don't understand this? We don't want to define object *instances* in
>MIB files, right? ;-)


I guess instance is an overloaded term.
In the draft I used "TYPEDEF definitions" and "variable declarations"


>Andy>    Just as with the C language, if the TYPEDEF keyword is
>Andy>    present, then the construct is a data structure definition,
>Andy>    and if it's missing, then the construct is a data structure
>Andy>    declaration.
>
>??? The C typedef construct is used for what the word says: to define
>a type, no matter whether it's a struct or not. When the typedef keyword
>is missing there can be many things. ;-) I don't know what you mean.
>
>However, I like to compare our language design to commonly known
>languages like C.
>
>Andy>  Object Instance Examples [...]
>Andy>  O=Old (SMIv2), N=New (SMIng)
>
>Looking at your examples, I don't see any benefit in the changes. None
>of the OID lengths shrinks, some even get longer. Could you please
>explain what benefits you would expect?


Look in the draft, section 5.5
I believe hierarchical naming works better with existing SNMP PDUs
than SIv2 naming.




> From a subsequent mail I noticed that you talk about layers of instances.
>I don't understand this concept and it looks not common to me. I know the
>concept of OO modeling of classes or data structures, which could be
>regarded as layers. But I don't know the concept of layered instances.
>
>
>
>Andy> I'm proposing revolution, not evolution.
>
>Yes, that's my impression, as well. ;-))
>
>
>
>  -frank


Andy