Re: opstat model questions

[Gerald Winters <[e-mail]>]

>Hello Jeff:
>
>> 1. The Model for Common Operational Statistics draft mentions the 
>> Internet Standard MIB several times.  Does this term refer to 
>> MIB-II or the collection of all standard MIBs?
>
>All the standard MIBs.  These form a huge tree of MIB objects, any
>of which can be read (at least in principle, in practice many of them
>aren't useful for operational statistics).  The important thing here
>is that each MIB object has a unique name.
>

Alot of this confusion could be avoided if the documents (RFC1404 and
i-d Opstat Client-Server Model) would be more careful in the examples.
For example, on pg. 15 of RFC1404 it says, "Variable names are the fully
qualified Internet MIB names."  Yet in Appendix B this rule is abandoned
with examples like...

BEGIN_DEVICE
 ....
  UNI-1,total,ifInOctet,...
  BRD-1,total,ifInNUcastPkts,...

The Opstat model i-d perpetuates the confusion.  On pg. 8 we have...

SELECT net rtr1 eth-0 ifInOctets ...

My suggestion is to use fully qualified MIB names in the i-d.  On
the other hand, if it is correct in referring to MIB variables as
"ifInOctets", then I wish someone would set me straight.  Depending
on the answer to this issue, the Opstat wg might consider defining
VARNAME (e.g, pg 8).  A MIB object and a MIB variable are two
different entities (i.e., can I use both MIB objects and MIB variables
in the VARNAME field?)..
  The other suggestion I have is to add a brief explanation on
the relationship between DEVICE <--> routername and INTERFACE <-->
linkname.  It looks as though the current Opstat wg has adopted
more general terms for these fields (which is a good idea).
Personally, I have doubts concerning the use of an INTERFACE/linkname
field.

>> 3. The storage format described again seems to show a bias towards
>> routers.  Is there any reason that the "router-name" field couldn't
>> be something more abstract like host or device since other hosts 
>> on the network may supply network metrics?
>
>RFC 1404 is intended to be an interchange format rather than a storage 
>format.  You could certainly use it for storage, but there will usually
>be more efficient formats available.  The idea of the 'client-server' 
>draft (draft-ietf-opstat-client-server- ..) is to provide a statistics
>server delivering 1404-format files.
>

Thank you for clearing this up.  If you think about it you 
realize that the interchange format needn't be the same as
the the storage format.  However, when I read Section 6 of RFC1404
it is still not clear, even with your explanation...

6. Storing of Statistical Data

    This section describes a format for storing of statistical
    data.


Wouldn't it have been better to have titled this section something
like "Interchange Format of Statistical Data" or "Transfer Format..."?

--Jerry Winters