Hi Anton,
Perhaps I wasn't so verbose in my original posting. Documenting the SNMP
MIBs will give us counters and a way to configure syslog via SNMP. We've
had many discussions of what we want to count, and how it _should_ add up.
We've also had discussions on how to tell a syslog device how it should
enable the transmission of messages and what Facilities and Severities it
should send to where. From those discussions, however, David and I are
not sure that anyone will ever use those counters, or will ever use SNMP
to configure syslog. If that's the case, then we don't feel that we
should go through the effort to produce such a document.
On the other hand, we know that many people edit syslog.conf. Perhaps we
should document how to enable the sending of syslog messages as it has
historically been done, and forget about counters if no one here objects.
If we go this route then we do not see the need in the syslog WG to fully
document how to filter received messages nor how to select messages for
transmission. We think that we can provide the Operator community a good
service by describing how lpr.* messages can be transmitted to
"[EMAIL PROTECTED]" via udp, and how to transmit kern.* messages to a
different machine via tls.
The interoperability we hope to achieve by documenting syslog.conf (in
it's most generic form) will be to demonstrate the configuration aspects
that an operator will have to address to make it work. For simple udp
transport, it is to just assign an address. For tls, someone will need to
think through the aspects of how to designate the certificate that will be
presented by the server, and what policy decisions will need to be made on
the sender. Similar thoughts will need to be done for 3195
configurations.
I agree that documenting all of the potential features of the syslog
appliation is out of scope for this WG. We're merely asking if the WG
feels that a simpler document on how to configure and use syslog would be
more beneficial than documenting a MIB.
Thanks,
Chris
On Wed, 16 Jan 2008, Anton Okmyanskiy (aokmians) wrote:
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
