Re: Process for SMIng Syntax Proposal Submissions:

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

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.


- 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.

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

- `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'.

- `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).

- 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.

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

- 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.

- 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).

- 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?

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.

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.

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.

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.

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? ;-)

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?



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