Re: draft-bierman-sming-ds-03.txt

[Andy Bierman <abierman@cisco.com>]

At 04:14 AM 5/17/2002, Harrie Hazewinkel wrote:
>HI,
>
>Some comments on the draft.
>>... (copied from draft and potentially shorted).
>
>1) Section 5.2:
>>   - Compatibility with any version of ASN.1.
>
>What kind of compatibilit is ment?? BER??

This is a non-goal.
I don't think it's important that we define the SMI syntax in ASN.1.
The intent is to provide an ABNF when the syntax is stable.
Do not confuse the BER encoding of SNMP PDUs with the 
definition of management information in MIB modules, or the
definition of the structure of management information in the SMI.


>2) Section 5.3:
>>ARRAY
>>     This construct provides a multi-dimensional array structure,
>>     similar to the SEQUENCE construct in SMIv2.
>
>
>Why would you not keep the name SEQUENCE?? If I understand the
>statement of compatibility with ASN.1 I would say use SEQUENCE.

I think it's better to describe the data structures as they really are,
instead of abstracting them with ASN.1 terminology.  Developers and
operators understand the concepts of arrays, structures, and unions.
For 15 years we've been trying to hide the nature of data structures
by abstracting everything to be either a scalar or a simple table.


>3) Section 5.4:
>>The ASN.1 tabular data model is
>>replaced with a 'hierarchical containment' data model, which is more
>>similar to the 'native' data representation used by the managed device.
>
>
>What is considered the be the "'native' data representation"??
>I would expect this is not the same for every one/device.
>Maybe a small description for the term is appropriate.

It is different depending on the implementation. In my experience
the data structures used in routers to facilitate NM are not
limited to a set of arrays, each 1 level deep and containing
only base data types (e.g. SMIv2 SEQUENCEs). Native data structures
tend to utilize more complex containment.


>4) Section 5.4:
>>
>>          SMIv2                     SMI-DS
>>   ---------------------     ---------------------
>>   TEXTUAL-CONVENTION        TYPEDEF LEAF
>>   scalar OBJECT-TYPE        VAR LEAF
>>   tabular OBJECT-TYPE       VAR ARRAY
>>   NOTIFICATION-TYPE         NOTIFICATION
>
>
>Where did the item 'scalar' and 'tabular' go resp. the 'VAR LEAF'
>and 'VAR ARRAY'. From some examples later I understand those
>should be 'VAR LEAF scalar' and 'VAR ARRAY tabular', am I correct?

scalar and tabular are not object descriptors. Sorry for the
confusion.  It should be
  
     foo OBJECT-TYPE     VAR LEAF foo
     bar OBJECT-TYPE     VAR ARRAY bar



>5) Section 5.5:
>The section title "LEAF Data Object Naming" can better be
>"SCALAR Data Object Naming". Since later in your struct
>definition for instance also has 'LEAF'.

I changed it from SCALAR to LEAF because some people thought
the word SCALAR was confusing because in SMIv2 a scalar never
appears in any level of containment.  I don't care what it's
called -- I care about the harder problems, as outlined in
the Open Issues section.



>6) Section 5.5:
>>Aggregate Data Object Naming
>>----------------------------
>>
>>   An Aggregated Data Object variable declaration is named
>>   as follows:
>>
>>      <oidBase>.<compatNode>.<childNode>
>>           [.<childNode> ...] [.<indexNode> ...]
>>
>>    where:
>>
>>
>>      <childNode> is the data object child node identifier, which
>>          must be an INTEGER between 1 and 4294967295. (Similar
>>          to a column identifier in an SMIv2 table.)
>>
>>      <indexNode> is present only if the variable declaration
>>          resolves to a type that contains any ARRAY constructs,
>>          and MUST be an INTEGER between 0 and 4294967295.
>>          (Similar to an instance identifier in an SMIv2 table.)
>
>Do I understand it correctly that for other constructs only
>the schema <oidBase>.<compatNode>.<childNode> [.<childNode> ...]
>of which the <childNode>s are as you describe later by examples.
>It also looks to me that the index node is optional, I thought that
>there must be at least one, or am I wrong??
 
There are index nodes for constructs which contain 1 or more ARRAYs.
They are not needed for constructs containing only UNION, STRUCT,
and LEAF nodes.

>I would suggest for the child node a change (clarification) to
>" (Similar to a column identifier in an SMIv2 table where the child
>         node is only existing once.) "
>and maybe adding how many times the item may exist.
>
>7) Section 5.5:
>
>The text of this section "SMI-DS OID Construction"
>I would fold into the previous part in which you explain the Object
>Naming scheme. This looked duplicate to me and at first confusing
>due to the use of 'buffer'.
>
>8) Section 5.5:
>>
>>Note 3) The addrType field is not actually needed for simple variable
>>declarations, because UNION constructs are instantiated with at most one
>>accessible member.  In the example above, a GetNext Request for
>>'myAddress.addr' or 'newAddress' will return only one type of
>>InetAddress string from the InetAddressUnion.  The associated
>>InetAddressType variable is needed only when used together with the
>>InetAddress (generic string form) as INDEX components in an ARRAY.
>
>The idea of the UNION is to allow multiple types of variables under the
>same manegd object. You only make here a small note to the usage of a
>GetNext request with which you only get one of the variables.
>I would believe that it actually does not matter so much if even all would
>be instantiated. Secondly, who decied which of the members is returned??

I agree for the GenericCounter example it would be useful to allow
more than 1 of the nodes to be instantiated. One can probably create
examples where it wasn't okay to do that.  For read-only UNIONs,
the agent decides. For read-create UNIONs, the application decides.
For combo UNIONs -- that's another open issue to be solved.


>The only time it really matters if a SET is done to the variable
>instantiated. In you InetAddress example you have different format
>requirements for each of the 'union'-members. The problem I see is
>with an implementation did not implement all possible 'union'-members
>of the 'typedef'.
>How will this be handled??  Is a 'WrongValue', 'NoSuchName' or some other
>error code replied?? I would think that there is then also a need for
>an extra error code which specifies that the specific union member
>is not supported.

This needs to be resolved. Thanks for pointing out the problem.



>9) Section 5.5 augments example:
>>
>>
>>TYPEDEF ARRAY InetHostStats {
>>    DESCRIPTION
>>        "Example of a IP host stats table."
>>
>>    INDEX { ifIndex, inetAddrType, inetAddr }
>>
>>    LEAF inetAddrType { .. } ::= 1
>>
>>    LEAF inetAddr { .. } ::= 2
>>
>>    LEAF inPkts { .. } ::= 3
>>
>>    LEAF outPkts { .. } ::= 4
>>}
>>
>>VAR ARRAY ipStats {
>>    SYNTAX      InetHostStats
>>    STATUS      current
>>    DESCRIPTION
>>       "The IP host statistics for this network device."
>>} ::= { someBase 4 }
>
>Would the above not generate some 2 dimensional array??
>Is this intended?? I would think for clarity a typedef
>may not be an ARRAY, since the ARRAY relates to instantiation
>of objects. Maybe this is a personal view/opinion.

I think it's a 3d array, because there are 3 INDEX components.
Use of ARRAY in a TYPEDEF is a design choice, just like it
is in a programming language like C.

This example shows an ARRAY TYPEDEF and then a 'relative' VAR
declaration using that type.  It could also be accomplished (with
different OID naming of course) by using a TYPEDEF STRUCT, and
then using an 'inline' ARRAY VAR declaration that included a 'relative'
node declaration for the STRUCT.




>>-- OID declaration to keep AUGMENTS clause consistent
>>ipStatsEntry OBJECT IDENTIFIER ::= { ipStats 1 }
>>
>>-- a struct containing additional information for each
>>-- set of counters
>>
>>TYPEDEF STRUCT HostStatsTimeData {
>>    DESCRIPTION
>>        "Add some times related objects associated with
>>         each set of counters."
>>
>>    LEAF createTime { .. } ::= 1
>>
>>    LEAF updateInterval { .. } ::= 2
>>}
>>
>>
>>VAR ARRAY ipXStats {
>>    DESCRIPTION
>>        "Adds HC counters and additional information to
>>         the ipStats statistics."
>>
>>    AUGMENTS { ipStatsEntry }
>
>Somehow I think it would be wise to force the specification
>of ipStatsEntry into the 'VAR ARRAY' definition of ipStats.
>I believe that the ipStatsEntry will most likely not be defined
>in the original module that defines the ipStats and therefore
>the definition "ipStatsEntry = { ipStats 1 } will show up in many
>modules and potentially cause confusement in importing the
>ipStatsEntry.

I don't think we should force a single way of designing data structures.
THe choice depends on the reusability desired -- the same choices that
exist when a SW developer is designing code.

>I am not even thinking of have potentially different names.
>
>Rules need to be made for this, I guess.
>>
>>    LEAF inHCPkts { .. } ::= 1
>>
>>    LEAF outHCPkts { .. } ::= 2
>>
>>    -- Octet counters removed to make example shorter
>>
>>    STRUCT timeData {
>
>Do you not want here a LEAF timeData that gets expanded to
>a STRUCT HostStatsTimeData??

No -- the node here is not a LEAF -- it's a STRUCT.
LEAF nodes do not provide further containment (that's why they
are called LEAF nodes).


>>        SYNTAX      HostStatsTimeData
>>        MAX-ACCESS  read-only
>>        STATUS      current
>>        DESCRIPTION
>>            "Additional time-related information."
>>    } ::= 3
>>
>>    ARRAY portStats {
>
>Am I correct you here want to have an array (second dimension)
>within each element of the array ipXStats??

yes. Think of it as a table in a table if embedded array isn't
SMIv2-ish enough for you.


>>        DESCRIPTION
>>            "Extend the ARRAY with InetPort statistics."
>>
>>        INDEX { inetPort }
>>
>>        LEAF inetPort { .. } ::= 1
>>
>>        UNION uInPkts {
>>            SYNTAX      GenericCounter
>
>Here I would believe this is a LEAF of a type 'GenericCounter'.
>That a 'GenericCounter' is a UNION is besides the point from
>a uInPkts definition point of view.

I guess we disagree on the terminology.  I like the C-like syntax,
in which the first keyword gives a precise indication of the
type of data being declared or defined. If all the declarations start
with LEAF, then you have to track down the 'GenericCounter' definition
(in this example) to discover the basic construct is a UNION.



>10) Section 10 Appendix A:
>Although, I agree with your point 6, but somehow I also don't
>think it hurts to change the syntax more then you propose.
>
>For instance, you want to maintain the MODULE-IDENTITY which
>is used in a SMIv2 module as '<varName> MODULE-IDENTITY'.
>Changing this into 'MODULE-IDENTITY <varName>' is also an improvement
>and more in-line with your TEXTUAL-CONVENTIONS/OBJECT-TYPE changes.
>I also believe this could benefit compiler implemetations to perform
>grammar/syntax recovery after errors have been found.

I think I agree, but syntax preference is very subjective.
I agree it was a mistake in SMIv2 to make the descriptor the
first keyword, and use lots of rules to divide those descriptors
into different namespaces, which the MIB compiler uses to figure
out what the rest of the construct is supposed to look like.



>This kind of change also implies that compatibility with ASN.1 is
>even more reduced, practically zero. And as for having as much maintained
>from the old SMIv2 it will be problematic/confusing to all anyway.
>SMI-DS is a bit of mixing in new things. So all those existing
>standards track documents need to be adopted/converted anyway.

Agreed.
Compatibility with ASN.1 for the SMI and MIB documents is not a goal.
SMIv2 MIBs aren't even compatible with any specific version of ASN.1.





>regards,
>
>
>Harrie

Andy