I share similar sentiment as Anton. First of all, I agree that it may be a good idea reflecting current best practices to let MIB focus on monitoring aspects, not configuration aspects. Second, I am not sure how much standardization of configuration aspects is really needed to facilitate interoperability. In general, there are many aspects that _could_ be configurable, but whether they are indeed made configurable may be a matter of implementation differentiation - some products may offer some extra "bells and whistles" in making certain aspects configurable that others do not, then again some vendors may decide to not offer those bells and whistles but do things in a certain way in order to make the corresponding product simpler to use and not overwhelm users. In any event, those are local decisions with little impact of how different syslog implementations would interoperate.
I think it is fine in some cases to indicate what aspects would constitute valid knobs, as has for example been done with syslog-sign. If the intent of specifying a .conf file is to provide a menu of such knobs, that's fine. However, I would stop short of mandating that all those knobs actually have to be implemented, and implemented in a certain fashion. If we wanted to go that route, then I would assume going down the route of defining this as a data model for Netconf is the right way, but as mentioned this leads to some issue regarding scope of the working group, in addition to the fact that we'd be getting ahead of ourselves as Netconf isn't quite there yet as it is my understanding that work on Netconf data models is still far from a conclusion. --- Alex -----Original Message----- From: Anton Okmyanskiy (aokmians) Sent: Wednesday, January 16, 2008 12:24 PM To: [EMAIL PROTECTED] Subject: RE: [Syslog] Documenting the configuration of syslog 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
