Remeika, James C. | 10 Jun 23:48 2013

Request for clarification of RTF 5424 Section 6.2.5 (APP-NAME)

The APP-NAME field definition in RCF 5424 header says that "[i]t is a string without further semantics", and the ABNF definition of the field is 1*48PRINTUSASCII, which to my reading indicates that the space character is allowed. The same is true for the field PROCID, which follows APP-NAME: space characters seem to be allowed. How can this be allowed, if the values within the header are delimited by spaces. It seems like the two value sets for APP-NAME and PROCID would be indistinguishable:
APP-NAME: "cat dog"
PROCID: "rabbit"

APP-NAME: "cat"
PROCID: "dog rabbit"
Thanks for your consideration,
James Remeika
Syslog mailing list
Syslog <at>
Aditya Dogra (addogra | 21 Feb 17:25 2013

Syslog message to Remote Rerver

Hi All ,


Currently syslog messages collected locally on the network device are transmitted to the remote syslog servers as per RFC 5424 (UDP protocol used for transmission) and RFC 3195 (TCP protocol used for transmission)


However, we have observed that increasingly, customers are using syslog messages archived in the remote server for business logic .


In some networks, it is possible that some of the syslog messages may be dropped due to link failure or other network conditions.

However, the customers are expecting much higher resiliency for the syslog messages.



The questions we seek clarification are:


a)         What are the expectations from the external syslog delivery?


b)         Should we rely on syslog's alone ? Please note that SNMP traps functionality for network management is also there.?



Your thoughts and suggestions much appreciated.




Aditya dogra



Syslog mailing list
Syslog <at>
Chris Lonvick | 16 Mar 14:37 2011

I-D Action:draft-cloud-log-01.txt (fwd)

Hi Folks,

Just passing this along.


---------- Forwarded message ----------
Date: Mon, 14 Mar 2011 14:45:09 -0700
From: Internet-Drafts <at>
To: i-d-announce <at>
Subject: I-D Action:draft-cloud-log-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

 	Title           : Syslog Extension for Cloud Using Syslog Structured Data
 	Author(s)       : G. Golovinsky, et al.
 	Filename        : draft-cloud-log-01.txt
 	Pages           : 11
 	Date            : 2011-03-14

This document provides an open and extensible log format to be used
by any cloud entity or cloud application to log and trace activities
that occur in the cloud.  It is equally applicable for cloud
infrastructure (IaaS), platform (PaaS), and application (SaaS)
services.  CloudLog is defferent in content, but not in nature from
the traditional logging as it takes in account transient nature of
identities and resources in the cloud.

A URL for this Internet-Draft is:

Internet-Drafts are also available by anonymous FTP at:

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Attachment (draft-cloud-log-01.txt): message/external-body, 1 bytes

I-D-Announce mailing list

I-D-Announce <at>

Internet-Draft directories:


Syslog mailing list
Syslog <at>
Jeroen Massar | 16 Feb 11:35 2011

Re: draft-cloud-log-00 / CEE - why not IPFIX?

On 2011-02-16 06:21, Heinbockel, Bill wrote:
> From what I understand, IPFIX is for expression of IP flows from network sensing
> devices.

For a short bit forget about the history of IPFIX, it indeed comes from
NetFlow, and thus is used quite in a network centric way, but
effectively it is a structured streaming data format.

> Could you please explain how IPFIX is relevant to event and cloud logging data?
> I understand how CEE and IPFIX may overlap for describing networking events, but
> it is unclear to me how IPFIX could handle things like Windows Event Logs and
> RHEL audit logs.

There are two parts to IPFIX: Templates + Data

The template describes how the data looks like, for instance, lets take
an Apache CLF log entry: - - [16/Feb/2011:10:48:11 +0100] "GET /robots.txt
HTTP/1.1" 200 2629 "-" "Googlebot-Image/0"

We can make an IPFIX template for that

	{4, IPv4_SRC },
	{v, URL},
	{8, OCTETS},

The 'v' markers indicate variable fieldlengths, the others indicates the
number of bytes such a field takes. The data is then just encoded in the
above format, presto.

The above is a simple example, one can also have repeating lists and of
course you could make a variable template which just includes the fields
that you actually want to look at or you could already do some
aggregation and add other fields. Templates are only sent every now and
then, as they should not change. The data is the important bit.

The fieldnames are actually numbers in the data, thus very compact, and
are mapped to descriptions, data types etc, per a nice XML file (or .xhtml or .txt for
a more human readable version ;) for the official IANA list and with the
help of Enterprise IDs any others can easily be added.

The big advantage is that you can more or less do static templates if
you want and you only need one single parser on the collector side, thus
one does not have to create another parser and collector again for
decoding other protocols, just one, the IPFIX one, and you can optimize
that really well for all kinds of scenarios.

Syslog mailing list
Syslog <at>

Jeroen Massar | 15 Feb 12:17 2011

draft-cloud-log-00 / CEE - why not IPFIX?


As the subject states, for both this cloud[1] and CEE[2] proposals, why
not use IPFIX instead for structured logging data!?


Syslog mailing list
Syslog <at>

Chris Lonvick | 2 Feb 15:39 2011

I-D Action:draft-gerhards-syslog-plain-tcp-08.txt (fwd)

Hi Folks,

I've updated the document to include the reference from Steve Bellovin.

We'd appreciate reviews and feedback.


---------- Forwarded message ----------
Date: Tue, 01 Feb 2011 18:15:01 -0800
From: Internet-Drafts <at>
To: i-d-announce <at>
Subject: I-D Action:draft-gerhards-syslog-plain-tcp-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

 	Title           : Transmission of Syslog Messages over TCP
 	Author(s)       : R. Gerhards, C. Lonvick
 	Filename        : draft-gerhards-syslog-plain-tcp-08.txt
 	Pages           : 13
 	Date            : 2011-02-01

There have been many implementations and deployments of legacy syslog
over TCP for many years.  That protocol has evolved without being
standardized and has proven to be quite interoperable in practice.

The aim of this specification is to document three things: how to
transmit standardized syslog over TCP, how TCP has been used as a
transport for legacy syslog, and how to correlate these usages to
ensure interoperability.

A URL for this Internet-Draft is:

Internet-Drafts are also available by anonymous FTP at:

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Syslog mailing list
Syslog <at>

Chris Lonvick | 30 Jan 18:01 2011

New syslog/tcp draft available

Hi Folks,

We've finally gotten around to revising draft-gerhards-syslog-plain-tcp. 

This addresses the issues that Tom raised about
- the intro specifically stating what to expect in the body of the text
- a note on the transport security.

For the first, we just sort'a straightened things out with a few edits. 
For the latter, I looked in many places for a list of TCP vulnerabilities 
but couldn't find anything substantial.  The US-CERT had a few 
implementation things and there were a scattering of other things.  In the 
end, I just added a subsection to warn impelemters to look closely before 
writing code.  If anyone has any other suggestions, please let us know.

Syslog mailing list
Syslog <at>

RFC Errata System | 8 Jan 08:58 2011

[Editorial Errata Reported] RFC5424 (2682)

The following errata report has been submitted for RFC5424,
"The Syslog Protocol".

You may review the report below and at:

Type: Editorial
Reported by: VicTor Smirnoff <iamvic <at>>

Section: 6.2.1.

Original Text
 15             clock daemon (note 2)
 Table 1.  Syslog Message Facilities

Corrected Text
 15             clock daemon
 Table 1.  Syslog Message Facilities

Note 2 isn't present in this document. It's an artefact from RFC 3164.

This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

RFC5424 (draft-ietf-syslog-protocol-23)
Title               : The Syslog Protocol
Publication Date    : March 2009
Author(s)           : R. Gerhards
Category            : PROPOSED STANDARD
Source              : Security Issues in Network Event Logging
Area                : Security
Stream              : IETF
Verifying Party     : IESG
Syslog mailing list
Syslog <at>

Rainer Gerhards | 10 Nov 07:24 2010

Small draft for Syslog File Storage?

Hi all,

In what we did, we specified the on-the-wire format. However, we did not
specify any format to use when persisting syslog data to a file.

Note that we were very generous when specifying the on-the-wire format, for
example we permit LF, CR, NUL and many other characters considered dangerous
in file formats.

There are many tools available which interpret syslog data stored in text
files. However, different syslog implementations may use slightly different
file formats.

Together with the control character issue, the file format question both has
interoperability AND security issues. I think these would be very easy to fix
if we write a small RFC that specifies how text is to be encoded. It would be
similar, but much smaller to RFC4627 (JSON). Actually, I think we would need
to carry over primarily its section 2.5.

I would volunteer to write an initial draft, but would first like to get some
feedback if this effort has any chance of getting through.

Syslog mailing list
Syslog <at>

Jon Callas | 27 Oct 18:34 2010

Congrats to everyone

on a job well done!


Chris Lonvick | 27 Oct 15:12 2010

Publication of RFC 6012

Hi Folks,

I've also not received notification of the publication of syslog/dtls. 
Nonetheless, here it is:

I'd like to thank Joe for his editorial skills and perseverence, as well 
as Tom, Rainer, and Hongyan for merging their original proposals into a 
workable document.  Also, thanks to the people on the list who reviewed 
the document and sent in their comments - that's what makes the IETF work.

Syslog mailing list
Syslog <at>