Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog)

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 7 Feb 2005 15:50:47 -0500

hi

Well, obviously I support the idea of having this section. I think the
relationship to BSD version is the most frequently asked question this work
gets. I can't imagine it getting far along the review process without it.

You can choose how long or short to make this section, but it really needs
to be there. Some of this discussion is already scattered throughout the ID.
First step, gather it in one place.

Sharon 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Rainer
Gerhards
Sent: Monday, February 07, 2005 12:14 PM
To: [email-masked]
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
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 7 Feb 2005 21:14:17 -0500

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Anton
Okmianski
Sent: Monday, February 07, 2005 4:59 PM
To: 'Rainer Gerhards'; [email-masked]
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.  

> [mailto:[email-masked]] On Behalf 
> Of Rainer Gerhards
> 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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 14 Feb 2005 18:38:49 +0100

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Sharon Chisholm
> Sent: Tuesday, February 08, 2005 3:14 AM

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 15 Feb 2005 05:42:20 -0500

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:[email-masked]] 
Sent: Monday, February 14, 2005 12:39 PM
To: Chisholm, Sharon [CAR:5K50:EXCH]; [email-masked]
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:

###

Rainer

> > 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.
> >

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 15 Feb 2005 11:53:27 +0100

Sharon, 

> between the two specifications to me. 

I thought this was at least one of the most important things of the
relation. Actually, this compatibility issue was what drove the header
format.

> I was thinking more 
> along the lines of

I agree, I can add this similarities. I'll see that I compile a list,
which will probably be very short.

> normative and informative discussion within the IETF.

Actually... I don't like this approach either. HOWEVER, there was a
really looooooong discussion on the WG and it was the concensus that we
should keep the normative body very short. I didn't like it but I
accepted that concensus. I restructured the whole document so that only
the bare essentials are left in the "core document". Of course, we can
undo that change, but I think we would just go through the same cycle
again. So for the sake of getting this ready, I would prefer to stick
with the current approach, even though some of us might think it is
sub-optimal.

Rainer

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 15 Feb 2005 12:34:43 +0100

Sharon,

this is the new proposed text:

###

   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:

   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

> Sent: Tuesday, February 15, 2005 11:42 AM
> > agreeing with me or Rainer, so perhaps that was what you 
> were saying 
> > ...
> > 
> > Sharon
> > 
> Of Anton