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
"loghost@exam..." 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: syslog@ietf...
>> 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@list...
>> https://www1.ietf.org/mailman/listinfo/syslog
>>
>
> _______________________________________________
> Syslog mailing list
> Syslog@list...
> https://www1.ietf.org/mailman/listinfo/syslog
>

_______________________________________________
Syslog mailing list
Syslog@list...
https://www1.ietf.org/mailman/listinfo/syslog