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

HI,

--On Friday, May 17, 2002 9:53 AM -0700 Andy Bierman <[email protected]> 
wrote:

> At 04:14 AM 5/17/2002, Harrie Hazewinkel wrote:
>> HI,
>>
>> Some comments on the draft.
>>> ... (copied from draft and potentially shorted).
>>
>
>> 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.

yeah, that is correct.
>
>
>> 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).

True, and the same counts for using SNMP in applications.
For instance, mod-snmp (implementing the WWW-MIB in Apache)
uses a lot of structures in structures.

> Native data structures
> tend to utilize more complex containment.

True as well maybe it is usefull to add something where it
says a wide range of data representations or so. Just to make
sure that no specific data structure was held in our mind
while doing this.

>
>
>
>> 9) Section 5.5 augments example:

>
>> I am not even thinking of have potentially different names.
>>
>> Rules need to be made for this, I guess.

OK, would repeat the same as above, but I can see the point. The only
thing that worries me a bit is that soon poeple will aks guidance of
which way to go, but as you say it is a design/resuseability choice.

Then as a side effect this could cause problems in standards documents,
since people maybe have different preferences. And they are all OK.
Perticular if an automated translation from SMiv2 is defined.

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

Yes, but 'HostStatsTimeData' is already a struct.
Maybe it is the same as you described earlier.

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

I don't think it is so much we disagree, maybe more my confusement
and attempt to understand it all. I will go over it again then.




Harrie