Does defining configuration concepts require that you define the functional aspects of syslog application?
I can see many different uses of syslog, each requiring different configuration. It all depends on the context it is used in. It can be stand-along, it can be embedded, it can be part of a logging library. It can be a forwarder, a receiver or both. A receiver can write to file or database. It can be configured to ignore some messages based message names or whatever patterns. Forwarder can buffer things in various ways, throttle them, etc. A receiver can do de-duplication, correlation, etc. There is not end of features an syslog application may have. The UNIX syslog daemon is just one example application using syslog protocol. The original one is pretty trivial one and mostly geared towards local logging by OS sub-systems. Even Solaris and Linux syslog daemons have slightly different features. Another question is what kind of interop do we accomplish with standard configuration of syslog? Is it important? My gut feel is that defining standard configuration for syslog application is a dead-end because it requires us to define the specific application. IMO, we should let the specific application designers do that. Regards, Anton. > -----Original Message----- > From: Chris Lonvick (clonvick) > Sent: Wednesday, January 16, 2008 5:32 AM > To: [EMAIL PROTECTED] > Subject: [Syslog] Documenting the configuration of syslog > > Hi WG, > > Things are changing in the IETF around documenting the > management and operations of protocols. The OPS Area WG has > been documenting a change of approach, in which SNMP and MIBs > are not the only way to configure, manage and operate a > protocol, and existing practices are taken into greater > consideration when choosing the right tool for a task. > > We'd like to open that discussion to the WG to get some > opinions on this. > If we can get a sense of direction on this from the WG, then > we'll discuss this with our Advisor (Sam) and our ADs. > > Documenting the current operational practices for configuring > syslog (i.e. > syslog.conf) might be much more useful to the operator > community than developing a MIB module to do syslog > configuration. Is standardizing aspects of the common > syslog.conf configuration file the best way to show how to > configure a device to send syslog messages securely across the wire? > > Another approach would be to define some standard Netconf > data models for configuring secure syslog, but that is likely > to get into serious scope discussions that would bog down > such an approach. > > Our chartered focus is to resolve security issues in logging, > so we need to stay focused on defining management to support > the work we have done here. It is not in scope to define a > comnplete syslog.conf file format, nor to standardize aspects > of the file not related to configuring secure logging. > > Common syslog.conf files already address udp transport but we > would need to define how to also utilize tls and RFC3195 > transports in this work, and possibly how to configure > syslog.conf to support syslog signing. > > The OpSec WG is discussing whether to document best current > practices for syslog operations. If they do so, we may need > to coordinate with the OpSec WG about configuring security > for syslog. If syslog.conf is covered in the standards of > other standards development organizations, such as POSIX, we > also may need to liaison with those SDOs to get support for > our modifications to syslog.conf. > > If we do propose standard content for a configuration file > for syslog, we will still need to make the WG designs > manageable for purposes of monitoring. A MIB module is the > current IETF best practice for providing information for > fault and performance monitoring and for notifications. > > Please respond to this and let us know if you think that > documenting some standardized content for syslog.conf is > going to be a better way to clarify the configuration of > syslog rather than writing a MIB module that includes > configuration functionality. > > Thanks, > Chris & David > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
