[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-bierman-sming-ds-03.txt
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??
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.
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.
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?
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'.
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??
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??
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.
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.
>
> -- 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 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??
> 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??
> 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.
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.
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.
regards,
Harrie
Internet Management Consulting
tel: +39-3474932300
mailto: harrie@lisanza.net http://www.lisanza.net/