Subject: RE: [Syslog] plain tcp syslog

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Tue, 18 Oct 2005 14:30:44 -0400

Darren:

> > This has been a point of major confusion around syslog RFC 
> 3164, for 
> > example.  I have personally had to explain over and over to 
> a lot of 
> > engineers/managers that it is not a standard and "compliant"
> > implementation can send petty much anything yet claim 
> consistency with 
> > that RFC. That's what you end up with when you don't have strict 
> > requirements in the RFC.
> 
> Have you also mentioned to your engineers/managers that all 
> of the Cisco devices, for years and years, were RFC 3164 compliant ?
> 
> Or that this RFC documents an otherwise undocumented protocol 
> that they have been implementing for years ?
> 
> What you're describing are organisation problems and not the 
> domain of this working group to solve.

Well... You say all of Cisco devices "were RFC 3164 compliant". This illustrates my point.  What exactly does this compliance mean?  

My point is that any product can legitimately claim compliance with RFC 3164 and this claim has zero practical usefulness! I don't know what that compliance means, if RFC 3164 says in Sec 4.2:

"There are no set requirements on the contents of the syslog packet as it is originally sent from a device. It should be reiterated here that the payload of any IP packet destined to UDP port 514 MUST be considered to be a valid syslog message."

So, I can send any UDP message and legitimately claim I am complaint with RFC 3164. In fact, I can show you plenty of examples of very different formats of syslog messages found in the wild in pretty popular implementations. 

This was one of the reasons, I thought, we initiated the whole syslog-protocol work -- to make a real standard that could serve as authoritative reference for interop.  So, when I hear we want another document similar to RFC 3164 in nature, I am a bit concerned if we are repeating the same mistakes.  Documenting does not make a standard IMO. 

Now, one may argue that we could make a more strict informational RFC than RFC 3164.  But if we can do an RFC with strict requirements - then make it a standard.  I think it is a better investment of WG resources. But obviously consensus opinion rules. 

Thanks,
Anton. 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Darren Reed <[email-masked]>
Date: Sat, 22 Oct 2005 13:17:23 +1000 (EST)

> Darren:
> 
> Well... You say all of Cisco devices "were RFC 3164 compliant".
> This illustrates my point.  What exactly does this compliance mean?  

That the device delivers an ASCII text message that can be easily read
and understood, without any translation tools, by someone familiar with
the product.

> My point is that any product can legitimately claim compliance with
> RFC 3164 and this claim has zero practical usefulness! I don't know
> what that compliance means, if RFC 3164 says in Sec 4.2:
> 
> "There are no set requirements on the contents of the syslog packet as
> it is originally sent from a device. It should be reiterated here that
> the payload of any IP packet destined to UDP port 514 MUST be considered
> to be a valid syslog message."

Right, so that's way too loose, but is it like that because some devices
do not implement the header with the priority, etc ?

> Now, one may argue that we could make a more strict informational RFC
> than RFC 3164.  But if we can do an RFC with strict requirements - then
> make it a standard.  I think it is a better investment of WG resources.
> But obviously consensus opinion rules. 

Maybe we need to say "RFC 3164 documents the past but this new RFC is the
document that defines syslog/udp for the future" ?

If we did that, just rewrote section 4.2 so that it required the header,
rather than left it open, it would be minimal effort for establishing a
new RFC to define a proposed BSD syslog/UDp standard.  Is there any reason
why we wouldn't want to do that?

Darren