Syslog RFC feedback

I am really late to the game here. I know. I just wanted to share some  
feedback that I had about the current state of the syslog document:

- Let me say this first: I really like some of the changes that have  
been incorporated.
- Syslog message facility: Why do we still keep this? The only reason  
that I see people using the facility is to filter messages. There are  
better ways to do that. Some of the pre-assigned groups are fairly  
arbitrary and not even really implemented in most OSs. UUCP subsystem?  
Who is still using that? I guess the reason for keeping it is  
backwards compatibility? If possible, I would really like this to be  
gone.
- Priority calculation. The whole priority field is funky. The  
priority does not really have any meaning. The order does not imply  
importance. Why having this at all?
- Timestamps: What's the reason for having the "T" in the timestamp?  
Having looked at hundreds of different log formats, I have never seen  
anything like that. Why doing this?
- Hostname: I am not comfortable with the whole hostname spec. I like  
that there is an ordering and people are supposed to use FQDN, but  
there are many questions about this. To start with, in a lot of UNIX  
configurations, /etc/hosts contains an entry like:
127.0.0.1   localhost.localdomain  localhost
The second column is the FQDN (technically). Is that one that can be  
used? Can you make it clear that this is not what should be used? Same  
for 127.0.0.1 or the loopback address in general. How does a machine  
know whether an IP address is static or dynamic? How does a logging  
application know? I don't think you will ever know that. Did you mean  
a private versus a public address? That might be interesting.  
Furthermore, it should specify which interface's IP address to use.  
The one the message is sent out on?
- Under the section of PROCID: The text is imprecise. This number is  
not the process ID of the syslog process, it's the ID of the writing  
process. The third paragraph talks about detecting restarted  
applications and somehow mixes in the syslog process. ("might be  
assigned the same process ID as the previous syslog process".) This is  
not clear at all and very very confusing
- MSGID: Make clear that this ID is local to the application. It's not  
a global ID at all.

The biggest issue I have around the SD-ID field:

- I like that the user can extend these.
- Why is this structure so complicated? Why not going with a simple  
set of key-value pairs? This whole structure thing is so complicated.  
Parsing it, you need to keep state! You need to remember the SD-ID for  
each SD-PARAM. Why introducing this? Just stick with simple key-value  
pairs. That makes parsing easier. Much easier. And it makes the events  
easier to produce as well.
- By keeping an explicit message field (the unstructured part), you  
encourage people to still log in that way. I recommend using an  
explicit field (or parameter) that can be used to include human  
readable text. Instead of this:

<165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1 myproc 8710 - - %%  
It's time to make the do-nuts.

use:

<165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1 myproc 8710 -  
message="%% It's time to make the do-nuts."

or really:

1 2003-08-24 05:14:15.000003-07:00 host=192.0.2.1 process=myproc  
procid=8710 message="%% It's time to make the do-nuts."

- I definitely like the consideration of some of the special fields  
(structured data IDs). However, they should be used as simple keys (or  
parameters) that have special meaning.
- Parameter - origin: What does it mean to have multiple origins IPs?  
Is that a syslog forwarding chain? The document does not say anything  
about that. Also, we already have the host field in the beginning of  
the syslog messages. What's the relationship to that? Or is origin  
something completely different?
- Parameters - I would really like to see some use-cases for all of  
the IDs. Especially the sequenceId. I am assuming this is something  
that the syslog daemon assigns, not the logging application. Right? I  
think that needs to be clearer. For the sequenceId, what happens for  
forwarded messages? Are these IDs local? Are they forwarded along with  
a message?  Also, how does the logging application know about the  
timeQuality? Or if that something that the syslog daemon assigns, how  
does it know?
- I would really like to see the parameters to go away and have a  
generic key-value extension. In addition, IANA should have a set of  
allowed/defined keys. The parameters should be part of those. Each key  
has a special meaning (semantics). There should be a whole lot of  
them: src_ip, user_name, etc. Each producer should be free to add  
additional keys, realizing that not all consumers would understand  
their semantics. However, the consumers could still read them.

That's it for now.

Thanks a lot

   -raffy

--
   Raffael Marty
   Chief Security Strategist                           @ Splunk>
   Security Visualization: http://secviz.org       raffy.ch/blog



_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog