[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog)
Sharon,
this is the new proposed text:
###
A.1 Relationship with BSD Syslog
While BSD syslog is in widespread use, its format has never been
formally standardized. In RFC 3164 [12] observed formats were
specified. However, RFC 3164 is an informal document and practice
shows that there are many different implementations.
Consequently, RFC 3164 mandates no specific elements inside a syslog
message. It defines that any message format destined to the syslog
UDP port must be treated as a syslog message - no matter what its
content is. However, in almost all cases observed in practice, a BSD
syslog message starts with a priority value, which is a number
between brackets. An example is "<133>". This document uses that
known convention to provide some minimal version detection. It has
deliberately changed the syslog message header so that it will never
contain a less-than sign as the first character of the message. This
has two advantages:
If an older receiver receives a message that does not start with a
less-than sign, it still assumes this is a valid syslog message.
However, it does not try to parse any header fields, at least if it
obeys to the rule outlined in RFC 3164. This prevents the receiver
from parsing the message invalidly. It should be noted, however,
that at least some of the older implementations will experience
problems if the message received is larger than 1024 octets. Most of
the implementations will truncate a message after the first 1024
octets. So it is wise to not send messages larger than 1024 octets
to receivers which are known to be older.
If a receiver compliant to this document receives a message generated
by a non-compliant, older, sender, it notices that the message does
not have a proper header and thus is not formatted according to this
document. This enables the receiver to take appropriate action.
Please also see the description on header parsing in Appendix A.3 for
more information on this scenario.
RFC 3164 mandates UDP as transport protocol for syslog. This
document places no restrictions on the transport.
RFC 3164 specifies relay behaviour. This document does not specify
relay behaviour. This might be done in a separate document.
The PRI part in RFC 3164 is split into two fields - FACILITY and
SEVERITY - in this document. These new fields support the RFC 3164
values but also allow additional values.
The TIMESTAMP in RFC 3164 offers less precision and lacks the year
and timezone information. If a message formatted according to this
document needs to be reformatted to be RFC 3164 compliant, it is
suggested that the senders local time zone is used, and the time zone
information and the year being dropped. If a RFC 3164 formatted
message is received and must be transformed to be compliant to this
document, the current year should be added and the receivers time
zone be assumed.
The HOSTNAME in RFC 3164 is less specific, but this format is still
supported in this document as one of the alternate HOSTNAME
representations.
The MSG part of the message is defined as TAG and CONTENT in RFC
3164. In this document, MSG is what was called CONTENT in RFC 3164.
The TAG is now part of the header, but not as a single field. The
TAG has been split into SENDER-NAME, SENDER-INST and MSGID. This
does not totally resemble the usage of TAG, but provides the same
functionality for most of the cases.
In RFC 3164, STRUCTURED-DATA was not defined. If a message compliant
to this document contains STRUCTURED-DATA and must be reformatted
compliant to RFC 3164, the STRUCTURED-DATA simply becomes part of the
RFC 3164 CONTENT freeform text.
In general, this document tries to provide an easily parsable header
with clear field separations whereas traditional BSD syslog suffers
from some historically developed, hard to parse field seperation
rules.
###
Hopefully we get closer ;)
Rainer
> -----Original Message-----
> From: syslog-sec-bounces@www.employees.org
> [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of
> Sharon Chisholm
> Sent: Tuesday, February 15, 2005 11:42 AM
> To: syslog-sec@employees.org
> Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog)
>
> hi
>
> This seems more of a rehash of RFC3164 than explaining the
> relationship
> between the two specifications to me. I was thinking more
> along the lines of
> text currently buried in A7.
>
> " Implementors of earlier syslog implementations may note that
> SENDER-NAME, together with SENDER-INST is similar to the TAG field
> described in [12]. The SENDER-NAME is without the instance
> description that often could be found in TAG while SENDER-INST is
> just that instance description."
>
> In addition, I don't think keeping the main body of the
> document short by
> moving content to the appendix a generally useful strategy. I think it
> detracts from the readability of the specification. I know
> other standards
> bodies like moving non-normative content to the appendix, but
> I believe
> using RFC2119 type language is a more typical method of
> delineating between
> normative and informative discussion within the IETF.
>
> Sharon
>
>
> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> Sent: Monday, February 14, 2005 12:39 PM
> To: Chisholm, Sharon [CAR:5K50:EXCH]; syslog-sec@employees.org
> Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog)
>
>
> Sharon,
>
> I am still working through your comments (but almost finished
> now). I've
> come back to the relationship to BSD syslog. I agree to your
> reasoning. In
> order to keep the normative text small, I think that should
> be discussed in
> the non-normative implementors notes appendix. Here is the
> text that I have
> just written:
>
> ###
> A.1 Relationship with BSD Syslog
>
> While BSD syslog is in widespread use, its format has never been
> formally standardized. In RFC 3164 [12] observed formats were
> specified. However, RFC 3164 is an informal document and practice
> shows that there are many different implementations.
>
> Consequently, RFC 3164 mandates no specific elements
> inside a syslog
> message. It defines that any message format destined to the syslog
> UDP port must be treated as a syslog message - no matter what its
> content is. However, in almost all cases observed in
> practice, a BSD
> syslog message starts with a priority value, which is a number
> between brackets. An example is "<133>". This document uses that
> convention to provide some minimal version detection. It
> deliberately has changed the syslog message header so that it does
> never contain a less-than sign on the first position of
> the message.
> This has two advantages:
>
> If an older receiver receives a message that does not start with a
> less-than sign, it still assumes this is a valid syslog message.
> However, it does not try to parse any header fields, at least if it
> obeys to the rule outlined in RFC 3164. This prevents the receiver
> from parsing the message invalidly. It should be noted, however,
> that at least some of the older implementations will experience
> problems if the message received is larger than 1024
> octets. Most of
> the implementations will truncate a message after the first 1024
> octets. So it is wise to not send messages larger than 1024 octets
> to receivers which are known to be older.
>
> If a receiver compliant to this document receives a
> message generated
> by a non-compliant, older, sender, it notices that the message does
> not have a proper header and thus is not formatted
> according to this
> document. This enables the receiver to take appropriate action.
> Please also see the description on header parsing in
> Appendix A.3 for
> more information on this scenario.
> ###
>
> Note: Appendix A.3 is now what formerly was A.2, the information on
> version-specific header parsing.
>
> I would appreciate comments on the suggested text.
>
> Rainer
>
> > -----Original Message-----
> > From: syslog-sec-bounces@www.employees.org
> > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of
> > Sharon Chisholm
> > Sent: Tuesday, February 08, 2005 3:14 AM
> > To: syslog-sec@employees.org
> > Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog)
> >
> > hi
> >
> > All the more reason to create the section. I couldn't tell
> if you were
> > agreeing with me or Rainer, so perhaps that was what you
> were saying
> > ...
> >
> > Sharon
> >
> > -----Original Message-----
> > From: syslog-sec-bounces@willers.employees.org
> > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf
> Of Anton
> > Okmianski
> > Sent: Monday, February 07, 2005 4:59 PM
> > To: 'Rainer Gerhards'; syslog-sec@employees.org
> > Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog)
> >
> >
> > Rainer:
> >
> > I agree. Many people don't realize RFC 3164 is informational.
> > So, it make
> > sense to spell out that "-protocol" is the first standards
> > track RFC for
> > syslog if we did not do so already. Hence, the RFC 3164
> > pretty much does not
> > matter and is being obsoleted. It contained only
> > observations about how
> > different the existing implementations worked. And they do
> > vary. So, any
> > backwards compatibility that syslog servers may choose to
> > provide is really
> > best-effort and vendor-specific, right?
> >
> > Anton.
> >
> > > -----Original Message-----
> > > From: syslog-sec-bounces@willers.employees.org
> > > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf
> > > Of Rainer Gerhards
> > > Sent: Monday, February 07, 2005 12:14 PM
> > > To: syslog-sec@employees.org
> > > Subject: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog)
> > >
> > > Hi WG,
> > >
> > > Sharon made the following comment:
> > >
> > > ####
> > > G.3 Suggest adding a 'Relationship with BSD Syslog' section to
> > > answer comment questions. Some text already in A7. ####
> > >
> > > It was the concensus of the group that the draft should
> be as short
> > > as possible. I cut of some of these things that were present in
> > > previous versions. However, there has never been a
> specific section
> > > on that.
> > >
> > > Question: should we add it? If so, I would suggest adding
> it to the
> > > non-normative appendix - should we?
> > >
> > > Comments appreciated.
> > >
> > > Rainer
> > > _______________________________________________
> > > Syslog-sec mailing list
> > > Syslog-sec@www.employees.org
> > > http://www.employees.org/mailman/listinfo/syslog-sec
> > >
> > _______________________________________________
> > Syslog-sec mailing list
> > Syslog-sec@www.employees.org
> > http://www.employees.org/mailman/listinfo/syslog-sec
> >
> > _______________________________________________
> > Syslog-sec mailing list
> > Syslog-sec@www.employees.org
> > http://www.employees.org/mailman/listinfo/syslog-sec
> >
>
> _______________________________________________
> Syslog-sec mailing list
> Syslog-sec@www.employees.org
> http://www.employees.org/mailman/listinfo/syslog-sec
>
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec