Subject: I-D ACTION:draft-ietf-syslog-device-mib-04.txt
From: [email-masked]
Date: Wed, 02 Jul 2003 06:56:58 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF.

	Title		: Syslog MIB
	Author(s)	: G. Keeni, B. Pape
	Filename	: draft-ietf-syslog-device-mib-04.txt
	Pages		: 54
	Date		: 2003-7-1

This memo provides a MIB module that can be used to monitor and manage
syslog processes. It defines objects that allow the collection of
information related to syslog processes, it also defines objects that
can be used to monitor and/or control syslog processes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-04.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-syslog-device-mib-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-syslog-device-mib-04.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------------------------------

Date: Wed, 9 Jul 2003 12:55:00 -0700 (PDT)
From: Chris Lonvick <[email-masked]>
Subject: Where we're at - 9 July

Hi Folks,

Summer Vacation Time is upon us again and I know what you're thinking.  You've
got to spend some quality time with your family on that long vacation trip and
you'd really like to get something meaningful accomplished when you're not
putting in that "quality time".  So why not take along a copy of our current
IDs?  You can thoughtfully review them while your "significant other" and/or
kids are out shopping at the Disney store.  What could be more restful and
relaxing - the true value of a vacation?   :-)

At your liesure you could send us comments on the syslog-sign ID:

  http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-11.txt

This is the latest version from Jon and John.  Albert Meitus has offered
these comments (available in the maillist archive):
  http://www.mail-archive.com/syslog-sec%40employees.org/msg01141.html
and
  http://www.mail-archive.com/syslog-sec%40employees.org/msg01138.html
(I believe that the Fragment Length integer should be expressed as that
integer as well but wasn't converted over from the base64 with other
fields in an earlier draft.)

You could also think about sending in comments on the syslog-mib ID:

  http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-04.txt

Glenn got this in just before the Vienna meeting ID cutoff date.

I'd also like to start some discussions about "internationalization" of
syslog messages.  Right now the syslog-sign ID continues the
recommendation that almost everything be kept in US-ASCII.  I'd like to
leave that as it is, but have a subsequent ID which standardizes the
fields that may be changed to different character sets and how that may be
identified.  For example, I think that the PRI and TIMESTAMP fields should
be left as they are defined in syslog-sign.  The HOSTNAME, TAG and MSG
fields should probably be fair-game for international characters.  'Now'
is a good time to get this started so that we can let Darren New and
Marshall Rose consider this while they are updating RFC 3195.  Your
thoughts and opinions are solicited.

Thanks and have a safe and happy summer vacation,
Chris

------------------------------

Date: Fri, 11 Jul 2003 12:43:56 +0200
From: Rainer Gerhards <[email-masked]>
Subject: Syslog Internationalization - Message size

Hi all,

I am taking up on Chris' call for syslog internationalization.

If we look into languages with a huge character set (e.g. Japanese,
Chineese and Korean), we obviously need to encode this characters with
more than a single byte (octet, to be precise). Depending on the
encoding, between 2 and 5 bytes are needed for a single character.
Obviously, we have some issues with the encoding as this is not
printable in an US ANSI sense. But let's postpone this discussion. I
would just like to look at the message *size*.

It is fair to say that we need at least twice as much bytes as with US
ANSI. Thus, the usable message size drops dramatically to around 500
characters. If we look at the actual encoding, it can get even worse:
one approach (though probably not a clever one, not really thought this
out yet) could be to use base64 encoding on 8bit character streams. That
would fit nicely in "traditional" and current RFC interop. BUT with
bass64, we have even lengthier messages and as such the usable
"character message size" (payload) would probably be reduced to a point
where it is simply unsuable (read: too short to do something useful).

Thus it would make sense to allow for larger syslog message, BUT

- - we run into interop issues with existing syslog implementations / RFCs
- - this raises UDP fragmentation concerns which can mess up the whole
syslog message

I have no good answer on how this could be solved.

The only thing I have on my mind is that we introduce a new larger max
size that the message MUST NOT exceed and recommend that the size SHOULD
be less than the current limit. Then, we could suggest that an
implementor SHOULD add a user-configurable option to allow large syslog
packets - and probably also an option NOT to disregard "oversize"
packets (according to the existing RFCs/IDs).

In this scenario, a syslog client SHOULD also be configurable to emit
messages with the current max length - this would most probably mean
message truncation. An alternative to truncation would be to introduce
some fragmentation at the syslog level, but I do not "feel" really good
about this.

I think the length restriction on syslog messages - and how to slove it
- - severely impacts the possible message encoding and other parts of
"international syslog". As such, I think it makes sense to sort out
these things before proceeding into any payload issues.

Comments are highly appreciated. Hopefully I am overlooking something
obvious.

Rainer Gerhards

------------------------------

Date: Fri, 11 Jul 2003 08:31:25 -0700
From: Darren New <[email-masked]>
Subject: Re: Syslog Internationalization - Message size

Rainer Gerhards wrote:
> Comments are highly appreciated. Hopefully I am overlooking something
> obvious.

It's not obvious that a character set like Chinese taking (say) 3 bytes
per character is going to lead to messages three times as long. If one
character represents "email" and one character represents "message" and
one character represents "failure", that's just 9 bytes.

Just a passing thought...

- -- 
Darren New, San Diego CA USA (PST)
Things to be thankful for, #187:
  There is no Chinese tradition of changing from
  shoes to slippers to get off an escalator.

------------------------------

Date: Fri, 11 Jul 2003 17:51:52 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog Internationalization - Message size

Darren,

Good point. I may actually be overlooking the obvious ;) Let me check my
logs, I have seen that the message size grow much when using with
Japanese. But maybe this is due to the fact that we mostly deal with MS
Windows messages and they may be even phonier on Japanese Win32 ;)

Rainer

> -----Original Message-----
> From: Darren New [mailto:[email-masked]]
> Sent: Friday, July 11, 2003 5:31 PM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: Re: Syslog Internationalization - Message size
>
>
> Rainer Gerhards wrote:
> > Comments are highly appreciated. Hopefully I am overlooking
> something
> > obvious.
>
> It's not obvious that a character set like Chinese taking
> (say) 3 bytes
> per character is going to lead to messages three times as
> long. If one
> character represents "email" and one character represents
> "message" and
> one character represents "failure", that's just 9 bytes.
>
> Just a passing thought...
>
> --
> Darren New, San Diego CA USA (PST)
> Things to be thankful for, #187:
>   There is no Chinese tradition of changing from
>   shoes to slippers to get off an escalator.
>
>
>

------------------------------

Date: Fri, 11 Jul 2003 11:56:13 -0700
From: Tom Perrine <[email-masked]>
Subject: Re: Syslog Internationalization - Message size

I think that the internationlization is yet another last nail in the
coffin of UDP syslog.

Its just Really Time To Move On.

SDSC Syslog, syslog-ng and so many others have proven that TCP syslog
is workable, practical and effective.  There is just no more room on
the tired old cardboard box of UDP syslog for any more duct tape.

That's about $0.04 worth.

- --tep

- -- 
Tom E. Perrine <[email-masked]> |
http://www.sdsc.edu/~tep/     |

------------------------------

Date: Fri, 11 Jul 2003 15:56:17 -0400
From: Marshall Glen <[email-masked]>
Subject: RE: Syslog Internationalization - Message size

From the perspective of the healthcare IT industry, a reliable transport for
syslog is not only a Good Thing, it will also improve patient safety and
perhaps save a few lives.  The next time you or someone you care about is
attached to a medical instrumentation device, wouldn't you feel a bit better
if it was being monitored via a reliable protocol?

  _____

SIEMENS Medical Solutions - Health Services
Glen F. Marshall
Advisory System Designer, Technology & Innovation
51 Valley Stream Parkway, A08, Malvern, PA, 19355-1406
Phone: 	+01 610 219 3938
Fax: 	+01 610 219 3124
E-Mail: 	[email-masked]
  _____

- -----Original Message-----
From: Tom Perrine [mailto:[email-masked]]
Sent: Friday, July 11, 2003 2:56 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Syslog Internationalization - Message size

I think that the internationlization is yet another last nail in the
coffin of UDP syslog.

Its just Really Time To Move On.

SDSC Syslog, syslog-ng and so many others have proven that TCP syslog
is workable, practical and effective.  There is just no more room on
the tired old cardboard box of UDP syslog for any more duct tape.

That's about $0.04 worth.

- --tep

- -- 
Tom E. Perrine <[email-masked]> |
http://www.sdsc.edu/~tep/     |

- -------------------------------------------------------------------------------
This message and any included attachments are from Siemens Medical Solutions
USA, Inc. and are intended only for the addressee(s).
The information contained herein may include trade secrets or privileged or
otherwise confidential information.  Unauthorized review, forwarding, printing,
copying, distributing, or using such information is strictly prohibited and may
be unlawful.  If you received this message in error, or have reason to believe
you are not authorized to receive it, please promptly delete this message and
notify the sender by e-mail with a copy to [email-masked].  Thank you

------------------------------

Date: Fri, 11 Jul 2003 22:48:25 +0200
From: "ALbert Mietus (thuis)" <[email-masked]>
Subject: Re: Syslog Internationalization /UDP

> I think that the internationlization is yet another last nail in the
> coffin of UDP syslog.

> Its just Really Time To Move On.

> [...] TCP syslog is workable, practical and effective.
> There is just no more room [..] UDP syslog

I don't agree!

UDP syslog is fine in a lot of cases.

The question is where internationlization is always a good case. I don't thinks so
Yes, it is needed for "user applications, no we don't need it in technical
complex systems!

E.g. a Unix-kernel, of the RT core of a router is will be written in
"englisch-C"  there is no need for i18n. Often, there will be no room for ir either.
However, it's need logging. UPD-syslog will do fine!

My idea is to think about "syslog" as a concept, without (hard) limit's.  It is
a header with a prio, a timestamp etc and "a short line of message".

With UDP syslog, the line is upto 1K (Biut face it, I hardly see line abouve 80
chars. So with i18n, 3 thime 80 will fit.

TCP syslog, syslog-"whatever" doesn;'t need to inherite that limit. Just the
concept. But that doesn't mean UDP-syslog can't bee used any more!

ALbert Mietus
	Send prive mail to:      [email-masked]
	Send business mail to:   [email-masked]
	Don't send spam mail!

- -------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

------------------------------

Date: Fri, 11 Jul 2003 16:56:31 -0700
From: Eric Fitzgerald <[email-masked]>
Subject: RE: Syslog Internationalization - Message size

> one approach (though probably not a clever one, not really thought
this out yet)
> could be to use base64 encoding on 8bit character streams. That would
fit nicely
> in "traditional" and current RFC interop. BUT with bass64, we have
even lengthier

Why not use Unicode UCS-2 with UTF-8 encoding?
http://www.unicode.org/faq/utf_bom.html
ftp://ftp.rfc-editor.org/in-notes/rfc2279.txt

UTF-8 encoding would be backwards-compatible with ASCII in many (most?)
cases for syslog.

Eric Fitzgerald
Program Manager, Windows Auditing
Microsoft Corporation

------------------------------

Date: Sat, 12 Jul 2003 17:55:58 -0700
From: "Richard E. Perlotto II" <[email-masked]>
Subject: RE: Syslog Internationalization /UDP

I have to agree with the TCP argument for syslog.  If we are really
talking
about the next generation of logging why limit ourselves to a protocol
that
has proved to be limited in many ways.  We are now monitoring and
logging
devices that are much more pervasive than just on our edges.  In fact
many
times we are attempting to receive logs that in network spaces that we
may
only have limited access and control over.  UDP as its nature has proved
to
be unreliable.

TCP offers a lot of advantages and a certain amount of overhead.  But I
believe that it is time to move to a more robust logging protocol.

Richard

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of ALbert
> Mietus (thuis)
> Sent: Friday, July 11, 2003 1:48 PM
> To: [email-masked]
> Subject: Re: Syslog Internationalization /UDP
>
>
>
> > I think that the internationlization is yet another last
> nail in the
> > coffin of UDP syslog.
>
> > Its just Really Time To Move On.
>
> > [...] TCP syslog is workable, practical and effective.
> > There is just no more room [..] UDP syslog
>
> I don't agree!
>
> UDP syslog is fine in a lot of cases.
>
> The question is where internationlization is always a good
> case. I don't thinks so Yes, it is needed for "user
> applications, no we don't need it in technical complex systems!
>
> E.g. a Unix-kernel, of the RT core of a router is will be
> written in "englisch-C"  there is no need for i18n. Often,
> there will be no room for ir either. However, it's need
> logging. UPD-syslog will do fine!
>
> My idea is to think about "syslog" as a concept, without
> (hard) limit's.  It is a header with a prio, a timestamp etc
> and "a short line of message".
>
> With UDP syslog, the line is upto 1K (Biut face it, I hardly
> see line abouve 80 chars. So with i18n, 3 thime 80 will fit.
>
> TCP syslog, syslog-"whatever" doesn;'t need to inherite that
> limit. Just the concept. But that doesn't mean UDP-syslog
> can't bee used any more!
>
>
>
>
>
> ALbert Mietus
> 	Send prive mail to:      [email-masked]
> 	Send business mail to:   [email-masked]
> 	Don't send spam mail!
>
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
>
>
>

------------------------------

Date: Mon, 14 Jul 2003 12:57:07 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog Internationalization - Message size

Eric,

Thanks for the good pointer.

> Why not use Unicode UCS-2 with UTF-8 encoding?
> http://www.unicode.org/faq/utf_bom.html
> ftp://ftp.rfc-editor.org/in-notes/rfc2279.txt
>
> UTF-8 encoding would be backwards-compatible with ASCII in
> many (most?)
> cases for syslog.

I think there is one issue with UTF-8, that is it requires 8-BIT bytes.
Syslog allows only 7 bit transport. Fortunately, there is UTF-7
available (ftp://ftp.rfc-editor.org/in-notes/rfc2152.txt) which encodes
in plain 7 bit.

I was thinking base64 because it would not only allow unicode data to
travel. E.g. in Japan, a lot of data is encoded not in Unicode but in
traditional encodings, like JIS and EUC. If we use a Unicode-only
encoding, that would not be possible.

On the other hand, UTF-7 has the beauty that almost all plain US ANSI
characters can be transmitted without any encoding. In contrast to base
64 this means the message is human readable even on the wire.

I will note both choices down for now ;)

Rainer

------------------------------

Date: Wed, 16 Jul 2003 00:19:48 +1200
From: Andrew Ross <[email-masked]>
Subject: RE: Syslog Internationalization - Message size

Can anyone come up with a way that the initial message header can be
read in any character set and still make sense?

If the header contained the message encoding method then we could choose
to encode it in any method we wanted. UUE, Base64, UTF-8 etc. Final
syslog server that writes the data to file or displays messages would
simply decode data into users desired character set. Relays could just
pass the data unaltered.

Bearing in mind that the syslog messages were originally intended to be
read by an operator at some stage. It is no use if they remain encoded
at the end point. :)

Maybe after the <PRI> code, we use a couple of bytes to indicate the
message encoding type. Better still, make it the first two bytes that
determine the whole message encoding system. FF 01 = uue, FF 02=UTF-8
etc. Avoid using any 00 bytes so as not to confuse C strings.

My 2c worth on TCP vs UDP.

UDP is great for a last minute "I am dying" type message from a device.
TCP would require ACK back and a connection setup if not already
connected. If we go for something like BEEP with the extra handshaking
we are in for a longer wait before sending the message.

Question is, how many "I am dying" type messages do we get vs normal
"user logged in" type messages? Probably not enough to warrant staying
with UDP.

Regards

Andrew

- -----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Rainer Gerhards
Sent: Monday, 14 July 2003 10:57 p.m.
To: Eric Fitzgerald
Cc: [email-masked]
Subject: RE: Syslog Internationalization - Message size

Eric,

Thanks for the good pointer.

> Why not use Unicode UCS-2 with UTF-8 encoding?
> http://www.unicode.org/faq/utf_bom.html
> ftp://ftp.rfc-editor.org/in-notes/rfc2279.txt
>
> UTF-8 encoding would be backwards-compatible with ASCII in
> many (most?)
> cases for syslog.

I think there is one issue with UTF-8, that is it requires 8-BIT bytes.
Syslog allows only 7 bit transport. Fortunately, there is UTF-7
available (ftp://ftp.rfc-editor.org/in-notes/rfc2152.txt) which encodes
in plain 7 bit.

I was thinking base64 because it would not only allow unicode data to
travel. E.g. in Japan, a lot of data is encoded not in Unicode but in
traditional encodings, like JIS and EUC. If we use a Unicode-only
encoding, that would not be possible.

On the other hand, UTF-7 has the beauty that almost all plain US ANSI
characters can be transmitted without any encoding. In contrast to base
64 this means the message is human readable even on the wire.

I will note both choices down for now ;)

Rainer

------------------------------

Date: Wed, 16 Jul 2003 17:50:30 +0900
From: Glenn Mansfield Keeni <[email-masked]>
Subject: SyslogMIB: draft-ietf-syslog-device-mib-04.txt

Hi,
   The revised syslog-mib ID is posted to the archives. The URL is

  http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-04.txt

The changes are (From the Revision History in the APPENDIX of the I-D):

    REVISION "200306250000Z"  -- Wed June      25 00:00 GMT 2003
    DESCRIPTION
        "Changed the type of
             syslogProcLastError            SnmpAdminString,
             from Integer32.

         DEFVAL { 0 ] is added to syslogAllowedHostsMaskLen

         MO name changed from
         syslogCtlSelectionHostname to syslogCtlSelectionHostName

         Updated the description clauses.

         Fixed nits pointed out in Bert's mails of YYYYMMDD and
         revised the document wrt the guidelines in
         draft-ietf-ops-mib-review-guidelines-01.txt

         Editorial nits fixed.
        "

Cheers

Glenn

------------------------------

Date: Wed, 16 Jul 2003 20:50:42 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog Internationalization - Message size

Hi Andrew,

> Can anyone come up with a way that the initial message header
> can be read in any character set and still make sense?

I strongly think the header should NOT be changed. In my view, i18n
should apply to the payload, only. Besides that, US ANSI is always
present in foreign character sets. I know this for sure for European
languages as well as Japanese, Korean and Chineese. With European
alphabets, some characters may be reassigned. But these are seldomly
used ones like "~" and "^". This should be no problem at all as far as
the header is concerned.

>
> If the header contained the message encoding method then we
> could choose to encode it in any method we wanted. UUE,
> Base64, UTF-8 etc. Final syslog server that writes the data
> to file or displays messages would simply decode data into
> users desired character set. Relays could just pass the data
> unaltered.

Yes, I agree that this is a solution to solve the problem of the
potential need (?) for differnt encodings. However, I would stay away
from the header and tend to define a payload format that introduces a
"payload header" which then

A) designates this as an i18n enabled message
B) specifies the charset
C) has another payload section which then includes the actual message

Of course, all of this needs to be backwards compatible. We can't risk
to break existing implementations...
>
> Bearing in mind that the syslog messages were originally
> intended to be read by an operator at some stage. It is no
> use if they remain encoded at the end point. :)

That is a beauty of UTF-7: it remains at least partly readable. The
actual storage is not part of the protocol, I think it should be left to
the syslogd implementation.

>
> Maybe after the <PRI> code, we use a couple of bytes to
> indicate the message encoding type. Better still, make it the
> first two bytes that determine the whole message encoding
> system. FF 01 = uue, FF 02=UTF-8 etc. Avoid using any 00
> bytes so as not to confuse C strings.

I strongly object this - it would break all current RFCs/Ids ;)

>
> My 2c worth on TCP vs UDP.
>
> UDP is great for a last minute "I am dying" type message from
> a device. TCP would require ACK back and a connection setup
> if not already connected. If we go for something like BEEP
> with the extra handshaking we are in for a longer wait before
> sending the message.
>
> Question is, how many "I am dying" type messages do we get vs
> normal "user logged in" type messages? Probably not enough to
> warrant staying with UDP.
>

I posted a syslog-like protocol draft that details TCP transport. It
also nicely shows a number of shortcomings this approach has. I'll dig
out the URL and post it here for those interested.

In general, I (now;)) think that RFC3195 is the right way ... We just
need to get the small libs up and running (I have to admit that my
ambitions in this regard have been severely hit by other work). It is
the right long term solution. If you really think about a reliable
protocol, you'll end up with mtr's point that if you do it up you end up
at a protocol very similar to BEEP ;)

Aynhow, I wouldn't object to participate if there is some support for an
interim solution or at least a documentation of the current state. As
Andrew and others pointed out, there *are* a good number of existing
syslog/tcp applications out there, and at least 4 of them (Pix, Kiwi,
syslog-ng and WinSyslog) are interoperable.

Looking forward to comments!

Rainer

------------------------------

Date: Thu, 17 Jul 2003 12:07:30 +0200
From: Rainer Gerhards <[email-masked]>
Subject: Syslog over TCP

Hi all,

This is a follow-up posting raised by my i18n question on syslog. The
udp vs. tcp syslog issue was raised (again ;) - have a look at the list
archive
http://www.mail-archive.com/syslog-sec%40employees.org/msg01005.html).

As I started it, I would like to take up the ball. First of all, please
keep in mind that RFC3195 IS TCP BASED SYSLOG. So there is already a RFC
for this. The current hesitance to implement it stems back - in my
opinion - to the lack of a suitable, small and easy to integrate BEEP
library. I guess if we put half of the effort of discussing the tcp vs.
udp  war, we could already have written one ;) ... But I have to admit
that I, too, was dragged away from writing it.

For some other group, I had also created a small & incomplete spec on
how syslog over tcp could look like. You may want to have a look at it
just to find out why a "simple" solution can't be totally reliable... I
think the spec provides some very good arguments for RFC3195
(specifically 2.4 and 4 intro).

http://www.moniware.com/en/workinprogress/selp.txt

And yes, this paper looks IDish, but this is just because I used Jon
Postel's nroff macros... (because that format is well known).

Rainer

------------------------------

Date: Thu, 17 Jul 2003 14:08:19 +1200
From: Andrew Ross <[email-masked]>
Subject: RE: Syslog Internationalization - Message size

Hi Rainer,

Great to hear that ASCII is present in all the character sets. I am
happy to use a standard ASCII header followed by a payload descriptor
and then the payload in the specified encoding as you suggest. We don't
want to break any existing standards if we can avoid it. As long as
ASCII is standard then we will have no problems.

Any one have any thoughts on the syntax to specify the encoding?

Encoding=USASCII
Encoding=Base64

Regards

Andrew

------------------------------

Date: Thu, 17 Jul 2003 12:11:34 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog Internationalization - Message size

Hi Tom,

I disagree in the regard that internationalization is not related to
transport. In my point of view, the internationalization goes into the
payload (read MSG part) and is *not* depending on any specific
transport. Maybe I really need to draft some spec to clarify this, but
so far I have only limited information. I'll probably post some text
once I have enough together to do so relatively intelligently...

Rainer

> -----Original Message-----
> From: Tom Perrine [mailto:[email-masked]]
> Sent: Friday, July 11, 2003 8:56 PM
> To: [email-masked]
> Cc: Rainer Gerhards;
> Subject: Re: Syslog Internationalization - Message size
>
>
> I think that the internationlization is yet another last nail in the
> coffin of UDP syslog.
>
> Its just Really Time To Move On.
>
> SDSC Syslog, syslog-ng and so many others have proven that TCP syslog
> is workable, practical and effective.  There is just no more room on
> the tired old cardboard box of UDP syslog for any more duct tape.
>
> That's about $0.04 worth.
>
> --tep
>
> --
> Tom E. Perrine <[email-masked]> |
> http://www.sdsc.edu/~tep/     |
>
>

------------------------------

Date: Thu, 17 Jul 2003 13:02:58 +0200
From: Rainer Gerhards <[email-masked]>
Subject: Re: Syslog Internationalization /UDP

Albert,

>> I think that the internationlization is yet another last nail in the
>> coffin of UDP syslog.
>
>> Its just Really Time To Move On.
>
>> [...] TCP syslog is workable, practical and effective.
>> There is just no more room [..] UDP syslog
>
>I don't agree!
>
>UDP syslog is fine in a lot of cases.
>
>The question is where internationlization is always a good case. I don't thinks so
>Yes, it is needed for "user applications, no we don't need it in technical
>complex systems!

I disagree with it. My real-world experience shows me that many administrators acutally prefer to have system messages in their native language. Some even tend to use local characters in system objects they create (where permitted, e.g. Windows computer names). I don't intend to argue if the later is a very smart way of doing things, I just say that this is the way the world is ;)

Look at French, Spanish or German systems for example (sorry, not sure about Dutch...). There are things like öäüáéî and the like. You probably don't get them right on this email because they are 8 bit chars. Those chars very often make it into syslog messages, which then violate the RFCs. It is not a big issue, as almost all syslog implementations simply allow 8 bit characters but if you look at this from a strict point of view, it is a violation.

The same goes with Japanese installations. I pick Japanese, because we have some first-hand experience with our products. Japanese customers really love to be able to read what their system is telling them, and this in native language.

So, yes, I think there is need for i18n in syslog ;)

>
>E.g. a Unix-kernel, of the RT core of a router is will be written in
>"englisch-C"  there is no need for i18n. Often, there will be no room for ir either.
>However, it's need logging. UPD-syslog will do fine!

Even in this case, beware of at least the local language names - they often turn out to have 8 bit chars.

>
>My idea is to think about "syslog" as a concept, without (hard) limit's.  It is
>a header with a prio, a timestamp etc and "a short line of message".
>
>With UDP syslog, the line is upto 1K (Biut face it, I hardly see line abouve 80
>chars. So with i18n, 3 thime 80 will fit.

If I look at e.g. the WELF format (webtrends), you can quickly have more than 80 chars. The same definitely is the case of Windows logs.

>TCP syslog, syslog-"whatever" doesn;'t need to inherite that limit. Just the
>concept. But that doesn't mean UDP-syslog can't bee used any more!

Here I totally agree. Everyone pls face it: I don't expect UDP syslog to disappear any time soon. Especially with low-end devices, you can consider yourself lucky if they at least support it. I can envison they will change to a tcp based approach any time soon. So there is need for it.

Rainer

------------------------------

Date: Thu, 17 Jul 2003 15:10:20 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog Internationalization - Message size

> Any one have any thoughts on the syntax to specify the encoding?
>
> Encoding=USASCII
> Encoding=Base64

How about borrowing somthing from mime?

Anyhow, I think the sequence must start with some "unusual sequence" so
that it most probably can not mistakenly occur within a non-i18n
message. For example something like (wihtout quotes) "@@$$##". This at
the very beginning (byte 0) of the MSG part means that it is an
i18n-enabled payload.

Does this make sense?

Rainer

------------------------------

Date: Fri, 18 Jul 2003 10:38:30 +1200
From: Andrew Ross <[email-masked]>
Subject: RE: Syslog Internationalization - Message size

Hi Rainer,

Having an unusual header in the MSG part of the syslog message would be
fine, but also adding some readable code to determine the encoding type
would be good.

@@$$##USASCII or @@$$##Base64 etc.

Syslog message are meant to be read by humans after all :)

Even if we can't decode the text that follows, we will know that it is
encoded and in what form.

Cheers

Andrew

- -----Original Message-----
From: Rainer Gerhards [mailto:[email-masked]]
Sent: Friday, 18 July 2003 1:10 a.m.
To: Andrew Ross
Cc: [email-masked]
Subject: RE: Syslog Internationalization - Message size

> Any one have any thoughts on the syntax to specify the encoding?
>
> Encoding=USASCII
> Encoding=Base64

How about borrowing somthing from mime?

Anyhow, I think the sequence must start with some "unusual sequence" so
that it most probably can not mistakenly occur within a non-i18n
message. For example something like (wihtout quotes) "@@$$##". This at
the very beginning (byte 0) of the MSG part means that it is an
i18n-enabled payload.

Does this make sense?

Rainer

------------------------------

Date: Fri, 18 Jul 2003 15:12:20 +0200
From: Rainer Gerhards <[email-masked]>
Subject: Syslog Internationalization - CONTENT

Hi all,

I have just noted down some specifics on how the message could be
encoded and flaged. I hope this more formal spec will raise some
additional comments and describe better what I am thinking along:

- ----
   The CONTENT part of a I18N syslog message has the following ABNF [12]
   definition  (I just filled in those details that I so far made my
   mind up on):

      CONTENT         = HDR-I18N SP CONTENT-I18N
      HDR-I18N        = COOKIE ENCODING
      COOKIE          = "@#" %d73 "18" %d110   ; that is: "@#I18n"
                            ; note the capital "I" and lower case "n"
      ENCODING        = ??? ; to be decided, e.g. USASCII, but prefer
                            ; "MIME-binding" NO SP allowed

      MSGN-I18N       = 1*%((%d33-126) / SP)
      SP              = %d32

   As can be seen, an I18N content message is embeded into a RFC3164
   [12] content field. The I18N content is distinguished from plain

   RFC3164 content by the presence of a HDR-I18N COOKIE. If the COOKIE
   is present, the ENCODING part of the HDR-I18N tells which encoding is
   used. After a space, the actual content appears.

   I have not yet put any real thoughts into what the actual encoding
   may look like. I have the weak opinion that we can borrow something
   by MIME. For example, we can support base64 and quoted-printable
   encodings and have different charsets. Also UTF-7 is a good choice. I
   need to do more homework reading the other specs to come up with a
   real suggestion. Comments in this regard are extermely welcome.

   The following examples are given.

    Example 1

         <34>Oct 11 22:14:15 mymachine su: @#I18n??USANSI?? 'su root'
failed for
         lonvick on /dev/pts/8

   In this example, as it was originally described in RFC 3164, the
   message CONTENT actually is in US ANSI so it could also be sent in a
   plain RFC3164 message. To remove uncertainty, it was specifically
   flagged as being US ANSI.

    Example 2

         <165>Aug 24 05:34:00 10.1.1.1 myproc[10]:
   	  @#I18n??QUOTED-PRINTABLE??Gr=FC=DF Gott

   In this example, we have non US ANSI characters. The CONTENT part
   contains "Gruess Gott" which is the Bavarian way of saying hello. I
   am using a replacement writing method to make this readable in US
   ANSI. The actual string in ABNF is %x47.72.fc.fd.20.47.6f.74.74. As
   the content encoding notation and specification is not yet decided, I
   used QUOTED-PRINTABLE encoding in this sample.
- ----
Please notet that I also changed where the i18n header occurs: it is no
longer at the start of the MSG part but rather at the start of the
CONTENT part itself. I think this is more natural, as the TAG value
should have no problem with being in US ANSI. At least, it would greatly
easy compatibility with existing systems and recordings. On the other
hand, it may introduce uncertainties if there is a good reason for non
US ANSI characters in the TAG. Maybe we already have them in some
environments...

I hope this clarifies what I am currently thinking. Especially the
samples should provide a good view of how I think i18n can be embeded in
existing syslog without any change in any existing components (relays
will not need to be touched at all).

I am looking forward to any comments.

Rainer

> Hi Rainer,
>
> Having an unusual header in the MSG part of the syslog
> message would be
> fine, but also adding some readable code to determine the
> encoding type
> would be good.
>
> @@$$##USASCII or @@$$##Base64 etc.
>
> Syslog message are meant to be read by humans after all :)
>
> Even if we can't decode the text that follows, we will know that it is
> encoded and in what form.
>
> Cheers
>
> Andrew
>
>
>
> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Friday, 18 July 2003 1:10 a.m.
> To: Andrew Ross
> Cc: [email-masked]
> Subject: RE: Syslog Internationalization - Message size
>
>
> > Any one have any thoughts on the syntax to specify the encoding?
> >
> > Encoding=USASCII
> > Encoding=Base64
>
> How about borrowing somthing from mime?
>
> Anyhow, I think the sequence must start with some "unusual
> sequence" so
> that it most probably can not mistakenly occur within a non-i18n
> message. For example something like (wihtout quotes) "@@$$##". This at
> the very beginning (byte 0) of the MSG part means that it is an
> i18n-enabled payload.
>
> Does this make sense?
>
> Rainer
>
>
>

------------------------------

Date: Fri, 18 Jul 2003 15:50:51 +0200
From: Rainer Gerhards <[email-masked]>
Subject: Syslog implementations dealing with DBCS

Hi all,

I wonder if there are any syslog implementations out that deal with DBCS
as found in Asian languages. Even if not specifically supported, are
there some implementors on this list that can share what happens if DBCS
characters are transported using their syslog implementation?

Any feedback deeply appreciated.

Rainer Gerhards

------------------------------

Date: Sun, 20 Jul 2003 13:18:16 -0700
From: "Richard E. Perlotto II" <[email-masked]>
Subject: RE: Syslog Internationalization /UDP

While I agree that some sort of internationalization would be good, we
lose the most important part of logging and that is a certain amount
of expected output.  Will German devices only start producing logs
in German?  Japanese devices in only Japanese?

Whatever we propose will need to be able to be useable to the majority
but extensible enough such that those with non-English character sets
can still gain more than what is currently available.  Do we require
these types of devices to be able to produce two types of logging output?
We need something in between the two solutions.

Richard

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rainer Gerhards
Sent: Thursday, July 17, 2003 4:03 AM
To: [email-masked]
Subject: Re: Syslog Internationalization /UDP

Albert,

>> I think that the internationlization is yet another last nail in the
>> coffin of UDP syslog.
>
>> Its just Really Time To Move On.
>
>> [...] TCP syslog is workable, practical and effective.
>> There is just no more room [..] UDP syslog
>
>I don't agree!
>
>UDP syslog is fine in a lot of cases.
>
>The question is where internationlization is always a good case. I
>don't thinks so Yes, it is needed for "user applications, no we don't
>need it in technical complex systems!

I disagree with it. My real-world experience shows me that many administrators acutally prefer to have system messages in their
native language. Some even tend to use local characters in system objects they create (where permitted, e.g. Windows computer
names). I don't intend to argue if the later is a very smart way of doing things, I just say that this is the way the world is ;)

Look at French, Spanish or German systems for example (sorry, not sure about Dutch...). There are things like öäüáéî and the like.
You probably don't get them right on this email because they are 8 bit chars. Those chars very often make it into syslog messages,
which then violate the RFCs. It is not a big issue, as almost all syslog implementations simply allow 8 bit characters but if you
look at this from a strict point of view, it is a violation.

The same goes with Japanese installations. I pick Japanese, because we have some first-hand experience with our products. Japanese
customers really love to be able to read what their system is telling them, and this in native language.

So, yes, I think there is need for i18n in syslog ;)

>
>E.g. a Unix-kernel, of the RT core of a router is will be written in
>"englisch-C"  there is no need for i18n. Often, there will be no room
>for ir either. However, it's need logging. UPD-syslog will do fine!

Even in this case, beware of at least the local language names - they often turn out to have 8 bit chars.

>
>My idea is to think about "syslog" as a concept, without (hard)
>limit's.  It is a header with a prio, a timestamp etc and "a short line
>of message".
>
>With UDP syslog, the line is upto 1K (Biut face it, I hardly see line
>abouve 80 chars. So with i18n, 3 thime 80 will fit.

If I look at e.g. the WELF format (webtrends), you can quickly have more than 80 chars. The same definitely is the case of Windows
logs.

>TCP syslog, syslog-"whatever" doesn;'t need to inherite that limit.
>Just the concept. But that doesn't mean UDP-syslog can't bee used any
>more!

Here I totally agree. Everyone pls face it: I don't expect UDP syslog to disappear any time soon. Especially with low-end devices,
you can consider yourself lucky if they at least support it. I can envison they will change to a tcp based approach any time soon.
So there is need for it.

Rainer

------------------------------

Date: Mon, 21 Jul 2003 11:19:55 +1200
From: Andrew Ross <[email-masked]>
Subject: RE: Syslog Internationalization /UDP

Maybe a mention should be made in the spec that systems intended for the
global market SHOULD include a US ASCII English sending option.
Firewalls, routers, switches etc that generate system logs for machine
parsing, SHOULD speak English.

Other devices and software that send messages to local operators or net
admins, could speak the local tongue.

If a product is to be made available outside of the country, then
allowances should be made to speak English.

Parsers have a hard enough time making sense of our current mixture of
syslog message formats, let's try to be sensible out there :)

Cheers

Andrew

- -----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Richard E. Perlotto
II
Sent: Monday, 21 July 2003 8:18 a.m.
To: 'Rainer Gerhards'; [email-masked]
Subject: RE: Syslog Internationalization /UDP

While I agree that some sort of internationalization would be good, we
lose the most important part of logging and that is a certain amount
of expected output.  Will German devices only start producing logs
in German?  Japanese devices in only Japanese?

Whatever we propose will need to be able to be useable to the majority
but extensible enough such that those with non-English character sets
can still gain more than what is currently available.  Do we require
these types of devices to be able to produce two types of logging
output?
We need something in between the two solutions.

Richard

- -----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Rainer Gerhards
Sent: Thursday, July 17, 2003 4:03 AM
To: [email-masked]
Subject: Re: Syslog Internationalization /UDP

Albert,

>> I think that the internationlization is yet another last nail in the
>> coffin of UDP syslog.
>
>> Its just Really Time To Move On.
>
>> [...] TCP syslog is workable, practical and effective.
>> There is just no more room [..] UDP syslog
>
>I don't agree!
>
>UDP syslog is fine in a lot of cases.
>
>The question is where internationlization is always a good case. I
>don't thinks so Yes, it is needed for "user applications, no we don't
>need it in technical complex systems!

I disagree with it. My real-world experience shows me that many
administrators acutally prefer to have system messages in their
native language. Some even tend to use local characters in system
objects they create (where permitted, e.g. Windows computer
names). I don't intend to argue if the later is a very smart way of
doing things, I just say that this is the way the world is ;)

Look at French, Spanish or German systems for example (sorry, not sure
about Dutch...). There are things like öäüáéî and the like.
You probably don't get them right on this email because they are 8 bit
chars. Those chars very often make it into syslog messages,
which then violate the RFCs. It is not a big issue, as almost all syslog
implementations simply allow 8 bit characters but if you
look at this from a strict point of view, it is a violation.

The same goes with Japanese installations. I pick Japanese, because we
have some first-hand experience with our products. Japanese
customers really love to be able to read what their system is telling
them, and this in native language.

So, yes, I think there is need for i18n in syslog ;)

>
>E.g. a Unix-kernel, of the RT core of a router is will be written in
>"englisch-C"  there is no need for i18n. Often, there will be no room
>for ir either. However, it's need logging. UPD-syslog will do fine!

Even in this case, beware of at least the local language names - they
often turn out to have 8 bit chars.

>
>My idea is to think about "syslog" as a concept, without (hard)
>limit's.  It is a header with a prio, a timestamp etc and "a short line
>of message".
>
>With UDP syslog, the line is upto 1K (Biut face it, I hardly see line
>abouve 80 chars. So with i18n, 3 thime 80 will fit.

If I look at e.g. the WELF format (webtrends), you can quickly have more
than 80 chars. The same definitely is the case of Windows
logs.

>TCP syslog, syslog-"whatever" doesn;'t need to inherite that limit.
>Just the concept. But that doesn't mean UDP-syslog can't bee used any
>more!

Here I totally agree. Everyone pls face it: I don't expect UDP syslog to
disappear any time soon. Especially with low-end devices,
you can consider yourself lucky if they at least support it. I can
envison they will change to a tcp based approach any time soon.
So there is need for it.

Rainer

------------------------------

Date: Sun, 20 Jul 2003 13:18:16 -0700
From: "Richard E. Perlotto II" <[email-masked]>
Subject: RE: Syslog Internationalization - Message size

I agree with this.  Content and transport are different things.  Although
I also agree that UDP is on its way out.

Richard

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rainer Gerhards
Sent: Thursday, July 17, 2003 3:12 AM
To: Tom Perrine
Cc: [email-masked]
Subject: RE: Syslog Internationalization - Message size

Hi Tom,

I disagree in the regard that internationalization is not related to transport. In my point of view, the internationalization goes
into the payload (read MSG part) and is *not* depending on any specific transport. Maybe I really need to draft some spec to clarify
this, but so far I have only limited information. I'll probably post some text once I have enough together to do so relatively
intelligently...

Rainer

> -----Original Message-----
> From: Tom Perrine [mailto:[email-masked]]
> Sent: Friday, July 11, 2003 8:56 PM
> To: [email-masked]
> Cc: Rainer Gerhards;
> Subject: Re: Syslog Internationalization - Message size
>
>
> I think that the internationlization is yet another last nail in the
> coffin of UDP syslog.
>
> Its just Really Time To Move On.
>
> SDSC Syslog, syslog-ng and so many others have proven that TCP syslog
> is workable, practical and effective.  There is just no more room on
> the tired old cardboard box of UDP syslog for any more duct tape.
>
> That's about $0.04 worth.
>
> --tep
>
> --
> Tom E. Perrine <[email-masked]> |
> http://www.sdsc.edu/~tep/     |
>
>

------------------------------

Date: Mon, 21 Jul 2003 20:07:58 +1200
From: Andrew Ross <[email-masked]>
Subject: RE: Syslog Internationalization /UDP

Agreed! I am all for a standard payload format too. WELF (Webtrends
Extended Log Format) is the closest thing we have so far. If it was
tagged correctly, it might even help me learn German :)

Mit freundlichen Gruessen

Andrew

- -----Original Message-----
From: Rainer Gerhards [mailto:[email-masked]]
Sent: Monday, 21 July 2003 7:58 p.m.
To: Andrew Ross; Richard E. Perlotto II; [email-masked]
Subject: RE: Syslog Internationalization /UDP

Andrew,

Just some additional spice to my message to Andrew. Be warned: I am
touching payload which some consider outside the scope of this WG ;)

> Maybe a mention should be made in the spec that systems
> intended for the
> global market SHOULD include a US ASCII English sending option.
> Firewalls, routers, switches etc that generate system logs for machine
> parsing, SHOULD speak English.
>
> Other devices and software that send messages to local
> operators or net
> admins, could speak the local tongue.
>
> If a product is to be made available outside of the country, then
> allowances should be made to speak English.

As I wrote - provide the standard and let the market work...

>
> Parsers have a hard enough time making sense of our current mixture of
> syslog message formats, let's try to be sensible out there :)

Let me pick this up from a different angle: in my point of view, parsing
is made hard not by different languages but by the lack of a syslog
payload (read: MSG/CONTENT) standard. If there would be a standard like:

TYPE=DataSend LOCALPORT=1933 REMOTEPORT=80 HOST=www.example.com
PROTO=TCP ... MSG="URL zugeriffen"
TYPE=AccessDenied LOCALPORT=14556 REMOTEPORT=25 HOST=www.example.com
PROTO=TCP ... MSG="Zugriff Verweigert"

Don't you think you could parse it without knowing German? In my point
of view, the missing payload format is the #1 issue when parsing logs.
If you had defined fields and a field for the human-redable message (in
local script;)) you would not have any issue at all.

OK, this is not an immediate task. But as long as we do not provide any
payload standard, it is not started and thus takes longer to complete...
;)

Rainer

------------------------------

Date: Mon, 21 Jul 2003 04:09:37 -0700 (PDT)
From: Lonvick <[email-masked]>
Subject: RE: Syslog Internationalization /UDP

- ---------- Forwarded message ----------
Date: Mon, 21 Jul 2003 09:51:02 +0200
From: Rainer Gerhards <[email-masked]>
To: Richard E. Perlotto II <[email-masked]>
Cc: [email-masked], Andrew Ross <[email-masked]>
Subject: RE: Syslog Internationalization /UDP

Richard,

> While I agree that some sort of internationalization would be good, we
> lose the most important part of logging and that is a certain amount
> of expected output.  Will German devices only start producing logs
> in German?  Japanese devices in only Japanese?
>
> Whatever we propose will need to be able to be useable to the majority
> but extensible enough such that those with non-English character sets
> can still gain more than what is currently available.  Do we require
> these types of devices to be able to produce two types of
> logging output?
> We need something in between the two solutions.

I would like to stress one motivation behind internationalization. I
think there are two motivations behind this:

#1 local names
Local computer and user names are not uncommon at least in the European
environment (I am not sure about Asia). What happens is we have an
otherwise English message, but it will pick up some local e.g. system
name with non US ANSI characters. Right now, this is simply not
supported in any of the standards. In reality, most syslog clients (I
know) don't care and send 8 bit data. With I18N, we can easily and
"cleanly" include these local characters into our language stream.

#2 localized messages
In my point of view, this is radically different from #1. Here, the
whole message is local text and English is potentially totally absent.
The motivation behind this is obviously to make the message
understandable to some non-English speaking folks. I agree that this
poses a big problem to log analysers - they must support different
languages in their parsing. However, it may not pose a problem to human
readers...

I think it is very dangerous to assume that everyone in IT speaks
English and does so fluently. Granted, if you are with an international
vendor OR with an international organization, chances are good you are
not hired if you don't speak English. But even then, I guess (no real
knowledge) that if you are with a French multinational, you may need to
speak French as the official first language.

However, as soon as you leave the multinationals, things change
dramatically. You may find it surprisingly how few admins - even in
large organizations - do not or only very weak speak English. I know
this for sure for Germany and have the strong feeling it is also the
case for Japan. My experience also tells me it is most probably the case
in China, France, Italy and Spain. I don't have any real-world backed
experience with other countries, but I assume you could easily extend
the list. So I think we must be *very careful* when saying that
non-English messages pose a problem. In fact, for those people, the
English messages are useless. And keep in mind this goup of people is by
far larger in size than the "mutlinational admins". So I would not jump
on the wagon to say "it must be English to be good" (sorry for
over-stressing the point a bit too much - my intension is to make the
point very clearly visible).

Given this philosophy, I honestly don't have any problem with Japanese
devices only emiting Japanese messages and German ones only German.
These message will make far more sense to those in the native language
environment. Even think about low-end home users strugling with the
routers...

I think we should provide the necessary standard enabling vendors to
create such devices. Then, let them (or better: the market) decide if it
actually makes sense to them. Right now, we have *no* standard and do
not leave the vendor any option to do this in a standards-compliant way.
What happens? Everybody emiting local messages does it in a
non-conformant way.

I firmly believe: We can't and shouldn't tell vendors and customers
their choice of doing logging. If they like local logs in multiple
languages, let them do it. If they don't do that for good reasons,
that's fine. But if we do not provide a solution to do it, they'll do it
their own (and vendor-specific) way. Remeber: ultimately, it is not the
ISO or IETF or evel local government (and least in the free world ;))
that tells them what the have to do: they decide themselfs based on
market needs. The only thing we can do to get it in an interoperable way
is to help them with a standard. Fortunatley, really bad ideas are
sorted out quickly in the market ;)

Comments?

Rainer

------------------------------

Date: Mon, 21 Jul 2003 09:57:38 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog Internationalization /UDP

Andrew,

Just some additional spice to my message to Andrew. Be warned: I am
touching payload which some consider outside the scope of this WG ;)

> Maybe a mention should be made in the spec that systems
> intended for the
> global market SHOULD include a US ASCII English sending option.
> Firewalls, routers, switches etc that generate system logs for machine
> parsing, SHOULD speak English.
>
> Other devices and software that send messages to local
> operators or net
> admins, could speak the local tongue.
>
> If a product is to be made available outside of the country, then
> allowances should be made to speak English.

As I wrote - provide the standard and let the market work...

>
> Parsers have a hard enough time making sense of our current mixture of
> syslog message formats, let's try to be sensible out there :)

Let me pick this up from a different angle: in my point of view, parsing
is made hard not by different languages but by the lack of a syslog
payload (read: MSG/CONTENT) standard. If there would be a standard like:

TYPE=DataSend LOCALPORT=1933 REMOTEPORT=80 HOST=www.example.com
PROTO=TCP ... MSG="URL zugeriffen"
TYPE=AccessDenied LOCALPORT=14556 REMOTEPORT=25 HOST=www.example.com
PROTO=TCP ... MSG="Zugriff Verweigert"

Don't you think you could parse it without knowing German? In my point
of view, the missing payload format is the #1 issue when parsing logs.
If you had defined fields and a field for the human-redable message (in
local script;)) you would not have any issue at all.

OK, this is not an immediate task. But as long as we do not provide any
payload standard, it is not started and thus takes longer to complete...
;)

Rainer

------------------------------

Date: Mon, 21 Jul 2003 09:56:22 -0700
From: "Richard E. Perlotto II" <[email-masked]>
Subject: RE: Syslog Internationalization /UDP

I was not arguing in favor of locking the spec for English text only, but
that the spec that we write must have conditions on how the internationalization
is utilized so that it is all done consistently.  I wanted to bring up the
issue of having a multitude of character sets now available and to ensure
that we are not compounding the problem.

Because of the current market, you can assume that all devices will be used
all over the world.  This means that those in Argentina are very likely to
be using devices from China.  If the logs are set for Chinese, then they will
be useless for those attempting use the logs.

I just want to make sure that whatever we suggest it is actually useful and
will work across the board.  French just for the sake of French is not
sufficient.

Richard

- -----Original Message-----
From: Rainer Gerhards [mailto:[email-masked]]
Sent: Monday, July 21, 2003 12:51 AM
To: Richard E. Perlotto II
Cc: [email-masked]; Andrew Ross
Subject: RE: Syslog Internationalization /UDP

Richard,

> While I agree that some sort of internationalization would be good, we
> lose the most important part of logging and that is a certain amount
> of expected output.  Will German devices only start producing logs in
> German?  Japanese devices in only Japanese?
>
> Whatever we propose will need to be able to be useable to the majority
> but extensible enough such that those with non-English character sets
> can still gain more than what is currently available.  Do we require
> these types of devices to be able to produce two types of logging
> output? We need something in between the two solutions.

I would like to stress one motivation behind internationalization. I think there are two motivations behind this:

#1 local names
Local computer and user names are not uncommon at least in the European environment (I am not sure about Asia). What happens is we
have an otherwise English message, but it will pick up some local e.g. system name with non US ANSI characters. Right now, this is
simply not supported in any of the standards. In reality, most syslog clients (I
know) don't care and send 8 bit data. With I18N, we can easily and "cleanly" include these local characters into our language
stream.

#2 localized messages
In my point of view, this is radically different from #1. Here, the whole message is local text and English is potentially totally
absent. The motivation behind this is obviously to make the message understandable to some non-English speaking folks. I agree that
this poses a big problem to log analysers - they must support different languages in their parsing. However, it may not pose a
problem to human readers...

I think it is very dangerous to assume that everyone in IT speaks English and does so fluently. Granted, if you are with an
international vendor OR with an international organization, chances are good you are not hired if you don't speak English. But even
then, I guess (no real
knowledge) that if you are with a French multinational, you may need to speak French as the official first language.

However, as soon as you leave the multinationals, things change dramatically. You may find it surprisingly how few admins - even in
large organizations - do not or only very weak speak English. I know this for sure for Germany and have the strong feeling it is
also the case for Japan. My experience also tells me it is most probably the case in China, France, Italy and Spain. I don't have
any real-world backed experience with other countries, but I assume you could easily extend the list. So I think we must be *very
careful* when saying that non-English messages pose a problem. In fact, for those people, the English messages are useless. And keep
in mind this goup of people is by far larger in size than the "mutlinational admins". So I would not jump on the wagon to say "it
must be English to be good" (sorry for over-stressing the point a bit too much - my intension is to make the point very clearly
visible).

Given this philosophy, I honestly don't have any problem with Japanese devices only emiting Japanese messages and German ones only
German. These message will make far more sense to those in the native language environment. Even think about low-end home users
strugling with the routers...

I think we should provide the necessary standard enabling vendors to create such devices. Then, let them (or better: the market)
decide if it actually makes sense to them. Right now, we have *no* standard and do not leave the vendor any option to do this in a
standards-compliant way. What happens? Everybody emiting local messages does it in a non-conformant way.

I firmly believe: We can't and shouldn't tell vendors and customers their choice of doing logging. If they like local logs in
multiple languages, let them do it. If they don't do that for good reasons, that's fine. But if we do not provide a solution to do
it, they'll do it their own (and vendor-specific) way. Remeber: ultimately, it is not the ISO or IETF or evel local government (and
least in the free world ;)) that tells them what the have to do: they decide themselfs based on market needs. The only thing we can
do to get it in an interoperable way is to help them with a standard. Fortunatley, really bad ideas are sorted out quickly in the
market ;)

Comments?

Rainer

------------------------------

Date: Mon, 21 Jul 2003 20:37:32 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog Internationalization /UDP

Richard,

I see your point, but I still disagree.

The large multinationals will probably have an English language
requirement in their purchasing spec. But what does it hurt if a (local)
Japanese or French coproation uses local language exclusively?

Rainer

> -----Original Message-----
> From: Richard E. Perlotto II [mailto:[email-masked]]
> Sent: Monday, July 21, 2003 6:56 PM
> To: Rainer Gerhards
> Cc: [email-masked]; 'Andrew Ross'
> Subject: RE: Syslog Internationalization /UDP
>
>
> I was not arguing in favor of locking the spec for English
> text only, but that the spec that we write must have
> conditions on how the internationalization is utilized so
> that it is all done consistently.  I wanted to bring up the
> issue of having a multitude of character sets now available
> and to ensure that we are not compounding the problem.
>
> Because of the current market, you can assume that all
> devices will be used all over the world.  This means that
> those in Argentina are very likely to be using devices from
> China.  If the logs are set for Chinese, then they will be
> useless for those attempting use the logs.
>
> I just want to make sure that whatever we suggest it is
> actually useful and will work across the board.  French just
> for the sake of French is not sufficient.
>
>
> Richard
>
> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Monday, July 21, 2003 12:51 AM
> To: Richard E. Perlotto II
> Cc: [email-masked]; Andrew Ross
> Subject: RE: Syslog Internationalization /UDP
>
>
> Richard,
>
> > While I agree that some sort of internationalization would
> be good, we
> > lose the most important part of logging and that is a
> certain amount
> > of expected output.  Will German devices only start
> producing logs in
> > German?  Japanese devices in only Japanese?
> >
> > Whatever we propose will need to be able to be useable to
> the majority
> > but extensible enough such that those with non-English
> character sets
> > can still gain more than what is currently available.  Do
> we require
> > these types of devices to be able to produce two types of logging
> > output? We need something in between the two solutions.
>
> I would like to stress one motivation behind
> internationalization. I think there are two motivations behind this:
>
> #1 local names
> Local computer and user names are not uncommon at least in
> the European environment (I am not sure about Asia). What
> happens is we have an otherwise English message, but it will
> pick up some local e.g. system name with non US ANSI
> characters. Right now, this is simply not supported in any of
> the standards. In reality, most syslog clients (I
> know) don't care and send 8 bit data. With I18N, we can
> easily and "cleanly" include these local characters into our
> language stream.
>
> #2 localized messages
> In my point of view, this is radically different from #1.
> Here, the whole message is local text and English is
> potentially totally absent. The motivation behind this is
> obviously to make the message understandable to some
> non-English speaking folks. I agree that this poses a big
> problem to log analysers - they must support different
> languages in their parsing. However, it may not pose a
> problem to human readers...
>
> I think it is very dangerous to assume that everyone in IT
> speaks English and does so fluently. Granted, if you are with
> an international vendor OR with an international
> organization, chances are good you are not hired if you don't
> speak English. But even then, I guess (no real
> knowledge) that if you are with a French multinational, you
> may need to speak French as the official first language.
>
> However, as soon as you leave the multinationals, things
> change dramatically. You may find it surprisingly how few
> admins - even in large organizations - do not or only very
> weak speak English. I know this for sure for Germany and have
> the strong feeling it is also the case for Japan. My
> experience also tells me it is most probably the case in
> China, France, Italy and Spain. I don't have any real-world
> backed experience with other countries, but I assume you
> could easily extend the list. So I think we must be *very
> careful* when saying that non-English messages pose a
> problem. In fact, for those people, the English messages are
> useless. And keep in mind this goup of people is by far
> larger in size than the "mutlinational admins". So I would
> not jump on the wagon to say "it must be English to be good"
> (sorry for over-stressing the point a bit too much - my
> intension is to make the point very clearly visible).
>
> Given this philosophy, I honestly don't have any problem with
> Japanese devices only emiting Japanese messages and German
> ones only German. These message will make far more sense to
> those in the native language environment. Even think about
> low-end home users strugling with the routers...
>
> I think we should provide the necessary standard enabling
> vendors to create such devices. Then, let them (or better:
> the market) decide if it actually makes sense to them. Right
> now, we have *no* standard and do not leave the vendor any
> option to do this in a standards-compliant way. What happens?
> Everybody emiting local messages does it in a non-conformant way.
>
> I firmly believe: We can't and shouldn't tell vendors and
> customers their choice of doing logging. If they like local
> logs in multiple languages, let them do it. If they don't do
> that for good reasons, that's fine. But if we do not provide
> a solution to do it, they'll do it their own (and
> vendor-specific) way. Remeber: ultimately, it is not the ISO
> or IETF or evel local government (and least in the free world
> ;)) that tells them what the have to do: they decide
> themselfs based on market needs. The only thing we can do to
> get it in an interoperable way is to help them with a
> standard. Fortunatley, really bad ideas are sorted out
> quickly in the market ;)
>
> Comments?
>
> Rainer
>
>
>
>

------------------------------

Date: Tue, 22 Jul 2003 14:03:15 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog Internationalization /UDP

Richard,

I read and re-read your mail... I maybe have it mistaken. I was thinking
that you object the presence of strings inside the logs that you can't
read and thus assign no meaning to it. Here, my answer still applies.

If, however, you are concerned that international characters / charsets
will make your otherwise US ANSI logs unreadable, then I fully agree.
What I propose is that all internationalization is within the limits of
the current RFCs/Ids. This specifically means that all content must be 7
bit US ANSI only. To represent other charsets, a special encoding is
needed, as there may be UTF-7, base64 or quoted-printable. In any case,
a log file with sporadic Chineese message will still be readable even if
you don't have the charsets at hand. Obviously, you won't be able to
decipher the message, but the others ones will not be touched.

Please note that even a Chineese speaker can not read them - they are
encoded. So it is the (i18n capable) syslog collector's task to convert
them into something readable. For example, the collector could store
data in Unicode text log files.

I hope this clarifies. Did I get closer to what you meant? Do you still
disagree? Maybe I am overlooking something obvious...

Rainer

> -----Original Message-----
> From: Richard E. Perlotto II [mailto:[email-masked]]
> Sent: Monday, July 21, 2003 6:56 PM
> To: Rainer Gerhards
> Cc: [email-masked]; 'Andrew Ross'
> Subject: RE: Syslog Internationalization /UDP
>
>
> I was not arguing in favor of locking the spec for English
> text only, but
> that the spec that we write must have conditions on how the
> internationalization
> is utilized so that it is all done consistently.  I wanted to
> bring up the
> issue of having a multitude of character sets now available
> and to ensure
> that we are not compounding the problem.
>
> Because of the current market, you can assume that all
> devices will be used
> all over the world.  This means that those in Argentina are
> very likely to
> be using devices from China.  If the logs are set for
> Chinese, then they will
> be useless for those attempting use the logs.
>
> I just want to make sure that whatever we suggest it is
> actually useful and
> will work across the board.  French just for the sake of
> French is not
> sufficient.
>
>
> Richard
>
> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Monday, July 21, 2003 12:51 AM
> To: Richard E. Perlotto II
> Cc: [email-masked]; Andrew Ross
> Subject: RE: Syslog Internationalization /UDP
>
>
> Richard,
>
> > While I agree that some sort of internationalization would
> be good, we
> > lose the most important part of logging and that is a
> certain amount
> > of expected output.  Will German devices only start
> producing logs in
> > German?  Japanese devices in only Japanese?
> >
> > Whatever we propose will need to be able to be useable to
> the majority
> > but extensible enough such that those with non-English
> character sets
> > can still gain more than what is currently available.  Do
> we require
> > these types of devices to be able to produce two types of logging
> > output? We need something in between the two solutions.
>
> I would like to stress one motivation behind
> internationalization. I think there are two motivations behind this:
>
> #1 local names
> Local computer and user names are not uncommon at least in
> the European environment (I am not sure about Asia). What
> happens is we
> have an otherwise English message, but it will pick up some
> local e.g. system name with non US ANSI characters. Right now, this is
> simply not supported in any of the standards. In reality,
> most syslog clients (I
> know) don't care and send 8 bit data. With I18N, we can
> easily and "cleanly" include these local characters into our language
> stream.
>
> #2 localized messages
> In my point of view, this is radically different from #1.
> Here, the whole message is local text and English is
> potentially totally
> absent. The motivation behind this is obviously to make the
> message understandable to some non-English speaking folks. I
> agree that
> this poses a big problem to log analysers - they must support
> different languages in their parsing. However, it may not pose a
> problem to human readers...
>
> I think it is very dangerous to assume that everyone in IT
> speaks English and does so fluently. Granted, if you are with an
> international vendor OR with an international organization,
> chances are good you are not hired if you don't speak
> English. But even
> then, I guess (no real
> knowledge) that if you are with a French multinational, you
> may need to speak French as the official first language.
>
> However, as soon as you leave the multinationals, things
> change dramatically. You may find it surprisingly how few
> admins - even in
> large organizations - do not or only very weak speak English.
> I know this for sure for Germany and have the strong feeling it is
> also the case for Japan. My experience also tells me it is
> most probably the case in China, France, Italy and Spain. I don't have
> any real-world backed experience with other countries, but I
> assume you could easily extend the list. So I think we must be *very
> careful* when saying that non-English messages pose a
> problem. In fact, for those people, the English messages are
> useless. And keep
> in mind this goup of people is by far larger in size than the
> "mutlinational admins". So I would not jump on the wagon to say "it
> must be English to be good" (sorry for over-stressing the
> point a bit too much - my intension is to make the point very clearly
> visible).
>
> Given this philosophy, I honestly don't have any problem with
> Japanese devices only emiting Japanese messages and German ones only
> German. These message will make far more sense to those in
> the native language environment. Even think about low-end home users
> strugling with the routers...
>
> I think we should provide the necessary standard enabling
> vendors to create such devices. Then, let them (or better: the market)
> decide if it actually makes sense to them. Right now, we have
> *no* standard and do not leave the vendor any option to do this in a
> standards-compliant way. What happens? Everybody emiting
> local messages does it in a non-conformant way.
>
> I firmly believe: We can't and shouldn't tell vendors and
> customers their choice of doing logging. If they like local logs in
> multiple languages, let them do it. If they don't do that for
> good reasons, that's fine. But if we do not provide a solution to do
> it, they'll do it their own (and vendor-specific) way.
> Remeber: ultimately, it is not the ISO or IETF or evel local
> government (and
> least in the free world ;)) that tells them what the have to
> do: they decide themselfs based on market needs. The only thing we can
> do to get it in an interoperable way is to help them with a
> standard. Fortunatley, really bad ideas are sorted out quickly in the
> market ;)
>
> Comments?
>
> Rainer
>
>

------------------------------

Date: Thu, 24 Jul 2003 11:22:49 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RFC3195 RAW question

Hi,

I am currently implementing RFC 3195 RAW in an ultra-slim way (yes, I've
taken up the task of ending this "simple tcp syslog" discussion). I am
not sure yet if the project works out, but I was at least able to send
messages to SDSC with very view code on my side.

However, I came across a question which I can not find the answer to in
the RFC. In the RAW description (3.), it says:

- ---
   All BEEP
   messages in the RAW profile are specified as having a MIME Content-
   Type [6] of application/octet-stream.
- ---

In the first sample below, it specifies:

- ---

.
.
.
      I: ANS 1 0 . 0 61 0
      I:
      I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.END
- ---

If you look at this, it looks like the payload of this BEEP frame is

\r\n  [CRLF]
<29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.

To me, this initally looked like while there is no content-type
specified, the message still contains the (then empty) MIME header.
Which is then terminated by CRLF. While working with SDSC, I found that
it does NOT expect the CRLF to be present (in fact, it fails, if it is).
I then looked through 3195, 3080 and 2045 and nowhere found mentioned
that this CRLF must be present. RFC 3080 says in 2.2:

- ---
   A message is structured according to the rules of MIME.  Accordingly,
   each message may begin with "entity-headers" (c.f., MIME's Section 3
   [1]).  If none, or only some, of the "entity-headers" are present:

   o  the default "Content-Type" is "application/octet-stream"; and,

   o  the default "Content-Transfer-Encoding" is "binary".
- ---

Other than that, 3080 specified payload just to be *OCTET. From the
description, however, I think that the CRLF in syslog raw payload is NOT
necessary.

Even 3195 does not say anything specifically about this CRLF, it is just
in the samples. Of couse, I may be overlooking the obvious ... So I
thought I simply ask. Could someone clarify? Mtr, do you have any
advise?

Thanks,
Rainer

------------------------------

Date: Thu, 24 Jul 2003 08:41:16 -0700
From: Marshall Rose <[email-masked]>
Subject: Re: RFC3195 RAW question

> ---
>    All BEEP
>    messages in the RAW profile are specified as having a MIME Content-
>    Type [6] of application/octet-stream.
> ---

> Even 3195 does not say anything specifically about this CRLF, it is just
> in the samples. Of couse, I may be overlooking the obvious ... So I
> thought I simply ask. Could someone clarify? Mtr, do you have any
> advise?

sure. the default content-type in beep is application/octet-stream.

so, when you send a message and the first two octets of that message are
\r\n, then there are no mime headers, so the default applies...

/mtr

------------------------------

Date: Thu, 24 Jul 2003 09:58:02 -0700
From: Darren New <[email-masked]>
Subject: Re: RFC3195 RAW question

Rainer Gerhards wrote:
> If you look at this, it looks like the payload of this BEEP frame is
>
> \r\n  [CRLF]
> <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.
>
> To me, this initally looked like while there is no content-type
> specified, the message still contains the (then empty) MIME header.

That is correct. Each message exchanged in BEEP is formatted with MIME.
MIME specifies that the headers and body are separated by CRLF. The fact
that there are no headers must be indicated by terminating the headers.

> Which is then terminated by CRLF. While working with SDSC, I found that
> it does NOT expect the CRLF to be present (in fact, it fails, if it is).

That's incorrect behavior.

> I then looked through 3195, 3080 and 2045 and nowhere found mentioned
> that this CRLF must be present. RFC 3080 says in 2.2:
>
> ---
>    A message is structured according to the rules of MIME.  Accordingly,
>    each message may begin with "entity-headers" (c.f., MIME's Section 3
>    [1]).  If none, or only some, of the "entity-headers" are present:
>
>    o  the default "Content-Type" is "application/octet-stream"; and,
>
>    o  the default "Content-Transfer-Encoding" is "binary".
> ---
>
> Other than that, 3080 specified payload just to be *OCTET.

Note that the second thru last frame of a complete message does not need
to have MIME headers, so indeed the payload of a frame is just *OCTET.

That the message is structured according to the rules of MIME implies
that headers are separated from body by CRLF, even if there are no headers.

  From the
> description, however, I think that the CRLF in syslog raw payload is NOT
> necessary.

That's incorrect.

> Even 3195 does not say anything specifically about this CRLF, it is just
> in the samples. Of couse, I may be overlooking the obvious ... So I
> thought I simply ask. Could someone clarify? Mtr, do you have any
> advise?

What you seem to be overlooking is that it's not BEEP that requires the
CRLF, but rather MIME.

Hope this helps.

- -- 
Darren New, San Diego CA USA (PST)
Things to be thankful for, #187:
  There is no Chinese tradition of changing from
  shoes to slippers to get off an escalator.

------------------------------

Date: Thu, 24 Jul 2003 20:32:09 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: RFC3195 RAW question

Thanks all who commented. I am very clear now on how things should
proceed. I initially expected the issue to be in my code, not SDSC
Syslog. I'll change my code back to include the CRLF tomorrow.

Rainer

> -----Original Message-----
> From: Devin Kowatch [mailto:[email-masked]]
> Sent: Thursday, July 24, 2003 8:18 PM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: Re: RFC3195 RAW question
>
>
> On Thu, Jul 24, 2003 at 11:22:49AM +0200, Rainer Gerhards wrote:
> [ snip ]
> > To me, this initally looked like while there is no content-type
> > specified, the message still contains the (then empty) MIME header.
> > Which is then terminated by CRLF. While working with SDSC,
> I found that
> > it does NOT expect the CRLF to be present (in fact, it
> fails, if it is).
> > I then looked through 3195, 3080 and 2045 and nowhere found
> mentioned
> > that this CRLF must be present. RFC 3080 says in 2.2:
> [ snip ]
>
> As others have said, I believe this to be a bug in SDSC
> Syslog.  In fact
> I think that handling of MIME headers got forgotten about, see bug
> #777108 for tracking this issue.
>
> --
> Devin Kowatch
> [email-masked]
>

------------------------------

Date: Thu, 24 Jul 2003 11:17:46 -0700
From: Devin Kowatch <[email-masked]>
Subject: Re: RFC3195 RAW question

On Thu, Jul 24, 2003 at 11:22:49AM +0200, Rainer Gerhards wrote:
[ snip ]
> To me, this initally looked like while there is no content-type
> specified, the message still contains the (then empty) MIME header.
> Which is then terminated by CRLF. While working with SDSC, I found that
> it does NOT expect the CRLF to be present (in fact, it fails, if it is).
> I then looked through 3195, 3080 and 2045 and nowhere found mentioned
> that this CRLF must be present. RFC 3080 says in 2.2:
[ snip ]

As others have said, I believe this to be a bug in SDSC Syslog.  In fact
I think that handling of MIME headers got forgotten about, see bug
#777108 for tracking this issue.

- -- 
Devin Kowatch
[email-masked]

------------------------------

Date: Wed, 30 Jul 2003 21:34:31 +0200
From: Rainer Gerhards <[email-masked]>
Subject: Syslog-sign and TCP

Hi all,

The syslog-sign ID refers to UDP in several places. I wonder if this is
by intension. I don't see any reason why we should limit it to UDP
tranport and outrule TCP. Shouldn't it be better transport-independent?

As actual example, I do not see any reason why syslog-sign should NOT
travel over RFC 3195/RAW. Of course, with COOKED, there are some issues,
but RAW would be a big advantage. As of now, I think we could not do a
standard-compliant sign via RAW implementation.

Comments?

Many thanks,
Rainer Gerhards

------------------------------
From: [email-masked] (syslog-sec-digest)
To: [email-masked]
Subject: syslog-sec-digest V1 #228
Reply-To: 
Sender: [email-masked]
Errors-To: [email-masked]
Precedence: bulk

syslog-sec-digest        Friday, August 1 2003        Volume 01 : Number 228

In this issue:

    Re: Syslog-sign and TCP
    Re: Syslog-sign and TCP
    Syslog-sign and BCP 18/ RFC2277

----------------------------------------------------------------------

Date: Wed, 30 Jul 2003 13:46:56 -0700 (PDT)
From: Chris Lonvick <[email-masked]>
Subject: Re: Syslog-sign and TCP

Hi Rainer,

On Wed, 30 Jul 2003, Rainer Gerhards wrote:

> Hi all,
>
> The syslog-sign ID refers to UDP in several places. I wonder if this is
> by intension. I don't see any reason why we should limit it to UDP
> tranport and outrule TCP. Shouldn't it be better transport-independent?

I know that Jon answered that some time ago.  It is transport-independent.
syslog-sign describes a replacement of syslog/UDP but it is expected to
ride atop syslog-reliable as well.  In that case, it is expected to
provide all of the benefits of both reliable transport and authenticated
delivery and storage.

>
> As actual example, I do not see any reason why syslog-sign should NOT
> travel over RFC 3195/RAW. Of course, with COOKED, there are some issues,
> but RAW would be a big advantage. As of now, I think we could not do a
> standard-compliant sign via RAW implementation.

It _should_.  :-)  The way it was supposed to have worked was that the
"authenticated syslog" work was to be finished first, and then the
"reliable transport" work was to be completed.  However, when Marshall and
Darren were ready to do syslog-reliable, only RFC 3164 was available.
When syslog-sign is submitted to become an RFC, Marshall and Darren will
be able to revise 3195 to incorporate the better fields (TIMESTAMP and
HOSTNAME) that are defined there.  It was also suggested that 3195 be
revised to accomodate work going on in the NetConf WG but I havn't seen
much activity there yet dealing with 3195.

>
> Comments?

Yup.  If we get far enough in our discussions of the internationalization
of syslog, that may be factored into the revision of 3195.  :-)

>
> Many thanks,
> Rainer Gerhards

Thanks,
Chris

------------------------------

Date: Wed, 30 Jul 2003 23:25:29 +0200
From: Rainer Gerhards <[email-masked]>
Subject: Re: Syslog-sign and TCP

Chris,

Where has been my brain... ;)

  >advantage. As of now, I think we could not do a
   >> standard-compliant sign via RAW implementation.

I meant COOKED!

Rainer

   >"authenticated syslog" work was to be finished first, and then the
   >"reliable transport" work was to be completed.  However, when Marshall and
   >Darren were ready to do syslog-reliable, only RFC 3164 was available.
   >When syslog-sign is submitted to become an RFC, Marshall and Darren will
   >be able to revise 3195 to incorporate the better fields (TIMESTAMP and
   >HOSTNAME) that are defined there.  It was also suggested that 3195 be
   >revised to accomodate work going on in the NetConf WG but I havn't seen
   >much activity there yet dealing with 3195.
   >
   >>
   >> Comments?
   >
   >Yup.  If we get far enough in our discussions of the internationalization
   >of syslog, that may be factored into the revision of 3195.  :-)
   >
   >>
   >> Many thanks,
   >> Rainer Gerhards
   >
   >Thanks,
   >Chris
   >

------------------------------