Hi, Rather than reinventing wheels, let's try to review work that has already been done in the IETF for these purposes, and discuss any experience that has already been had with these approaches. Please look at the RFC3165 Script MIB (ftp://ftp.rfc-editor.org/in-notes/rfc3165.txt) and the NETCONF work (http://www.ietf.org/html.charters/netconf-charter.html).
The Script MIB is all about uploading/downloading scripts to execute on a managed device. It is language-independent, but recognizes the likelihood of Java, Perl, and CLI scripts. This MIB has an (optional) on-line editing capability, which experience has shown few operators want to use; they would rather get the script, modify it offline, and send it back to the device. The NETCONF work is trying to make it possible to download/upload script files for configuring devices, as a way to standardize CLI scripting. dbh > -----Original Message----- > From: Glenn Mansfield Keeni [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 08, 2004 1:21 AM > To: [EMAIL PROTECTED] > Subject: Re: SyslogMIB Issue-#4 // Issue-#2 > > Andrew Ross wrote: > > > Having a minimum set of configuration options would > probably be a waste > > of time in my view as all implementations are so different. > > > > Since all implementations use (or can be made to use) a > config file, my > > vote is for a free form string variable. The format of the > text depends > > on the vendor. All we need to agree on is a standard cookie > to identify > > the vendor and version. > > > This makes sense. > > If I have heard and understood correctly - we would love to > have configuration > options - BUT given the diversity of the syslog > implementations we do not have > one model for configuration that would allow us to develop a > one-size-fits-all > MIB. > However there is the trivial model - which uses the > configuration file to hide > all the implementation details. This model probably fits all > implementation. > > That would mean - > A. We remove the configuration details > B. We introduce a configuration file object. Here we > have two choices > B-1. Just leave it at the fileName level of detail- > The fileName is > writable > Manager will set the syslogConf file name and > expect that to > be used. We have 1 MO in this case. > Comment: This is simple. The manager aranges for > the syslogConf > to be present (by non-SNMP means) and just tells > the syslog process > to use the specific syslogConf file. > B-2. Treat the file as a text file with one or more lines. > Represent the file as a table: a row is a line. > The semantics or syntax of the file is opaque to > management process. > It can read the file and display it on the > console (using SNMP). > For update of the file: allow lines to be > modified (using SNMP-Set) > > Comment: This is much more complex. To do this > nicely we will effectively > need a text file editor to be implemented using SNMP. > > C. At a later date, if there is interest and demand, we > can have a > BSD-Syslog configuration MIB where the parts removed > from A can be > used. > I liked what it was doing- it is pretty good and > useful when I want > to remote-monitor (not control) the configuration of > the syslog process. > > Let me have your comments. > > Cheers > > Glenn > > > > > >
