[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: A Data collection MIB

Niraj writes:

>I agree that we really need to have the discussion going
>on this list. As an interested developer, I had sent a few
>comments for draft-ietf-eos-snmp-bulkdata-00.txt on
>08/02/2001 but haven't seen any response or any updated
>draft. If there is a need for more volunteers, may be we
>should ask for help on the list.

I appologize for not putting more time on this list for
discussion of that mib.  let me take a belated try at your
comments from long ago:

>- When is the bulk data collected? Is it collected
>when the entry in slice table is made active or when
>the entry in xferTable made active?

I envision the bulk data being collected, conceptually
all at once (simulating an atomic data-gathering) 
when the 'xferEntryStatus' variable is set.  looking back
at the mib, I agree it wasn't clear that setting this var
would cause the data to be collected - just transmitted.

perhaps it makes more sense to have some action variables
that are separate; one for 'do the data collection NOW'
and one for 'do the file xfer NOW'.

>- If the NMS wants to get the same data again
>and again at regular intervals, it seems he has
>to create new entries in the xferTable. Instead
>there should be an object to start generation
>and transfer of the data specified by a particular
>sliceEntry again and again without having to create
>new xferTable entries.

it was my intention that the user would only have to define
the data [slice] once and then be able to use it again and
again.  perhaps the same notion should be applied to the xfer
table as well.  otoh, I am not sure I agree that periodic
uploads should be automatic.  its too easy for an NMS to
setup a recurring job and then forget about it, not ever deleting
that 'control record' in the agent.  I'd far prefer that even just
a single snmp var be set each time an xfer is to be done than have
the agent just assume 'keep uploading ad infinitum until I'm told

>- Currently the NMS can only specify and transfer
>either a MIB subtree or a single MIB table in one
>file. There should be a provision to transfer a bunch
>of data in one go e.g. NMS may need to transfer
>a lot of tables in several MIBs to fully populate
>its database. Instead of creating and parsing one
>file per MIB table, there should be provision to
>parse the whole list of tables and possibly scalars
>as well.

I am very seriously considering allowing multiple 'augments' style
tables to be scooped up at once and sent up to the remote fileserver
in one single file.  dperkins convinced me of this and I agree that
its useful.  otoh, I'm not sure of the utility of scooping up several
tables (possibly including scalars) and putting them all in ONE file
for remote upload.  this just makes things more complicated than they
have to be.  its much easier to have a single schema record at the beginning
of the data file than to have to delimit several tables and several schemas.
uploading a few files vs. one big one seems to have no real effect on the
efficiency of the data collection and transfer.

>- You need to include details in the draft about how
>to integrate this MIB with the Schedule MIB. In
>that case, the entries in the xferTable need to be
>active forever unless explicitly deleted.

I agree that more details need to be there.  hopefully, a lot of the missing
details will be explain by sample code (if I can ever get enough time to get
a 0.1 working demo that I can submit for general review).

>- There should be an object to start/stop the bulk
>file generation/transfer. Currently there is no knob
>to stop the bulk file generation/transfer other than
>deleting the row which is not good.

by separating out the definition of the remote file login info (currently bundled
as part of the xfer table) from the 'action request', we can avoid having to delete
the remote file login info just to abort the file transfer.  you have a good point

>- Notifications should be defined in this MIB to
>indicate both the error conditions and the successful
>transfer of the bulk file.

yes, I was a bad boy in not listing any traps as part of this mib.  I will correct
that mistake in the next rev ;-)

>- Is the bulk file stored in RAM/Flash or is it an
>ephemeral file? The status variable does has
>reference to ephemeral file. If its an ephemeral file,
>it should be mentioned clearly in the draft.

I didn't specify how the intermediate file would be saved.  I did assume that it would
be persistant across agent reboots, if for no other reason than to keep a local copy
until the agent is SURE that the file has been xferred AND accepted by the remote fileserver.
but your point is a good one in that it should be explicit and not just assumed.

>- The MIB in the draft uses IpAddress type. It should
>instead use InetAddressType and InetAddress to
>accommodate IPv6 addresses as well.


>- In description of xferFileEncoding object, the
>XML schema should be included so that the NMS
>knows how to parse it.

not being much of an XML person, I'll defer this to someone who knows XML.  I added
'xml' only to suggest that CSV files wouldn't be the only format that would be useful
to remote NMS's.  any xml fans out there care to beef up this section?

again, apologies for the extremely late reply.  I do want to keep the EOS group alive,
and yet, like most of us, actual work (day job) keeps getting in the way...