Hi all,
I came across this discussion:
http://groups.google.com/group/linux.debian.devel/msg/a35cfe80eeac3c3d
There seems to be a valid point/demand in standardizing rsyslog.conf
format, even though it has limited power. I thought I share the link.
Rainer
-Original Message-
From:
Hi Miao,
a few comments, rest snipped...
Section 1.1: shouldn't it simply refer to -protocol for terms
defined there? I think it makes it more consistent.
Agree, so we should only leave TLS client and TLS server to be
define in
Syslog/TLS darft, right?
That is my suggestion...
Hi all,
I reviewed tls-11 today. Some notes:
Section 1.1: shouldn't it simply refer to -protocol for terms defined
there? I think it makes it more consistent.
Section 4.2:
===
Authentication in
this specification means that the recipient of a certificate must
actually validate the
Sam,
your proposed text is fine with me. So from my side, please go ahead.
Thanks for your help,
Rainer
-Original Message-
From: Sam Hartman [mailto:[EMAIL PROTECTED]
Sent: Monday, September 10, 2007 7:36 PM
To: Chris Lonvick
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL
Hi folks,
I am sorry for the long silence. I was extremely busy with projects and
have to admit will be more or less unavailable for the next 3 weeks.
Beginning of September things will finally clear up and I hope to be
able to publish a new, hopefully final, version of -protocol.
Even though I
[Strictly speaking as an implementor, not as a draft editor]
I second Juergen's point of view.
I go even further. When receiving, I take great care not to loose any
message. Under stress conditions (e.g. low system memory), I accept lage
deformations of the message. Checksums are my least
I have been a bit brief. MSG is passed in via the POSIX API. So the
actual generator of MSG is not syslogd. However, and you are right on
this, from the on the wire IETF point of view, both are generated by
the same entity, that being syslogd.
Rainer
-Original Message-
From: Rainer
I agree that it is a point of view. I do not see the necessity of
the two layers for MSG and SYSLOG-MSG as a part of operations and
management.
The reason being that it will generally be the same entity
(application, module call it whatever) that will generate MSG and
SYSLOG-MSG.
Unix *nix,
- firewalls
- scp daemon
- ssh daemon
- SIP gateways
- network cache servers
- routers
- switches
Thanks,
Rainer
-Original Message-
From: Glenn M. Keeni [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 24, 2007 1:21 AM
To: Rainer Gerhards
Cc: tom.petch; [EMAIL PROTECTED]
Subject: Re: [Syslog
sense
to bother doing much with a field that is mostly useless anyhow.
Rainer
-Original Message-
From: Glenn M. Keeni [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 23, 2007 7:36 AM
To: Rainer Gerhards
Cc: Chris Lonvick; [EMAIL PROTECTED]
Subject: Re: [Syslog] -syslog-tc-mib Facilities
Glenn,
-Original Message-
From: Glenn M. Keeni [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 23, 2007 2:45 AM
To: tom.petch
Cc: [EMAIL PROTECTED]
Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3
containsnewtext to address ietf last call comments (fwd)
Tom,
The discussion came up about the use of the Facilities in the
-syslog-tc-mib document; are they normative or non-normative. David
and
I discussed this and have concluded that they are normative to the
version of the protocol that we are now discussing. That may be
changed
in the
Tom,
I have documented the generic design of almost (all?) syslog
implementations I know. Of course, there are some slight differences if
you look at the code, but the logical functions are present. Find it
here:
http://www.rsyslog.com/module-Static_Docs-view-f-/generic_design.html.ph
tml
David,
let me start with the relays: given the recent discussion, I think it
would be much more advisible to add a few sentences to -protocol (I
already made a proposal) that clarifies the situation. It is not much
that needs to be added. It would resolve all those other issues.
Regarding
Mark == Mark Andrews [EMAIL PROTECTED] writes:
[snip]
Similarly if syslogd is using a reliable transport
to talk to another syslogd. That too can block which
will eventualy lead to blockages to applications /
memory exhaustion.
*That* is a different beast, not
Sam,
I need to check the mailing list archives and my notes, but I think
there was no technical reason to use ISO instead of BCP 47. If I do not
find anything, I'll simply change the reference. In any case, I'll post
what I find out.
Rainer
-Original Message-
From: Sam Hartman
-Original Message-
From: Eliot Lear [mailto:[EMAIL PROTECTED]
Sent: Friday, January 26, 2007 11:46 AM
To: Chris Lonvick
Cc: [EMAIL PROTECTED]
Subject: Re: [Syslog] 3195bis before syslog-sign
Chris all,
As you mentioned, Darren, Marshall, and I will produce an internet-
Hi John,
-Original Message-
From: Moehrke, John (GE Healthcare) [mailto:[EMAIL PROTECTED]
Sent: Friday, January 26, 2007 1:45 PM
To: Eliot Lear; Chris Lonvick
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] 3195bis before syslog-sign
The Healthcare industry has tried to use COOKED...
David,
-Original Message-
From: David Harrington [mailto:[EMAIL PROTECTED]
Sent: Friday, January 26, 2007 4:15 PM
To: [EMAIL PROTECTED]
Subject: [Syslog] RFC3195bis
[.. big snip ..]
Chris and I did not agree that RAW mode should be obsoleted and
replaced with a new mode. That
David,
I will happily do that. But before I can, I need to go back to the
discussion on architecture in syslog-protocol. Is this issue solved? Do
we need a new section or are the proposed definition updates enough?
I am asking these questions because I think we need to be clear on the
Being not MIB-literate, I tend to agree that it does not add much
complexity if there is a table which most often includes just a single
element.
What is used in practice. It depends on your point of view. If you look
at deployments, a single engine is the vast majority. If you look at
number of
Hi Juergen,
The only thing that is special with syslog is that under one
operating
system (*nix), there is a different architecture with syslogd. It's
not
Windows that is different. It is the *nix implementation (at least
in
my
point of view). The problem is that *nix is obviously the
I agree for the reasons outlined in mails before.
Rainer
-Original Message-
From: David Harrington [mailto:[EMAIL PROTECTED]
Sent: Friday, January 12, 2007 7:31 PM
To: [EMAIL PROTECTED]
Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
Hi,
[speaking as
Hi Glen,
thanks for the message. Let me start on an overview level: if you look
at the evolution of the draft, you will see that earlier versions were
quite specific on what to do if the message was malformed. However,
based on dicussion, one after another of these rules were deleted. The
reason
...
Rainer
-Original Message-
From: tom.petch [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 6:47 PM
To: Rainer Gerhards; Glenn M. Keeni; [EMAIL PROTECTED]
Subject: Re: [Syslog] Syslog Protocol doubts
inline
Tom Petch
- Original Message -
From: Rainer
Hi all,
now that we obsolete RFC 3164 by -syslog-protocol, the only remaining
RFC that is not compatible to the new syslog series is RFC 3195. The
questions is now how to proceed here? I am raising this issue because it
has some effect on syslog-sign. I would love to see 2k as limit for
suggest we all have a look at this slide from 2004:
http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img5.html
Rainer
Thanks,
Chris
On Fri, 22 Dec 2006, Rainer Gerhards wrote:
Hi all,
now that we obsolete RFC 3164 by -syslog-protocol, the only
remaining
RFC
-Original Message-
From: Chris Lonvick [mailto:[EMAIL PROTECTED]
Sent: Friday, December 22, 2006 5:23 PM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] RFC 3195bis?
Hi,
I'm OK removing references to RFC 3195 from syslog-sign for the points
you
mention. I'd welcome
Hi all,
finally, I have managed to do a thourough review. I have not excessively
commented on issues that are already being discussed on list.
All in all, the document is fine work and in good shape. My issues are
mostly small nits and many of them connected to support for 3164 and
3195 (oh yes,
Andrew, Anton,
I am using Andrew's message to reply to both. I concur with Andrew,
please see below...
-Original Message-
From: Andrew Ross [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 21, 2006 10:53 PM
To: Rainer Gerhards
Subject: RE: [Syslog] RFC 3164
Hi Rainer
Chris,
-Original Message-
From: Chris Lonvick [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 20, 2006 3:37 PM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog]
clonvick WGLC Review of draft-ietf-syslog-sign-20.txt
appendix
Thanks,
Chris
-- Forwarded message --
Date: Wed, 20 Dec 2006 15:51:25 +0100
From: Rainer Gerhards [EMAIL PROTECTED]
To: Chris Lonvick [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: APP-NAME,
PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick
Hi all,
I just realized that the future of RFC 3164 is not yet publically
discussed.
RFC 3164 is a well-done work, but we have made much progress in the past
5 years since it was written. Most importantly, we discovered that
actual syslog software uses a much different set of formats than
Chris,
-Original Message-
From: Chris Lonvick [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 10:18 PM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] clonvick WGLC Review of
draft-ietf-syslog-sign-20.txt
Hi Rainer,
On Mon, 18 Dec 2006, Rainer
Just one comment...
In general the default values will be used ( IPv4, UDP,
port 512 etc.) by syslog entities.
514 is the IANA assigned port for UPD syslog.
Rainer
___
Syslog mailing list
Syslog@lists.ietf.org
Hi,
So far, I have not been able to do a full review. But this triggers my
attention immediately...
Perhaps restructure that as:
A Signature Block message that is compliant with RFC
[14] MUST
contain valid APP-NAME, PROCID, and MSGID fields.
Specifically, the
value
So far, just one comment...
1.6 11) in SyslogSeverity, I recommend removing the
second sentnece
in the
description The syslog protocol uses the values 0
(emergency)
to 7 (debug). since this is already spelled out in
the SYNTAX
clause,andshows that 99
David,
Sorry for the late reply.
In my experience: it depends...
Under Linux/Unix, it is most common to have a single instance of the
syslog process running. All other processes communicate with that
process via local IPC, but the ultimate sender is the single instance of
syslogd running. I
the IESG.
This is what I'd recommend. A simple sentence like severities MUST be
in the range of 0 to 7 should do the job.
Rainer
David Harrington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL
Miao, WG,
I have partially implemented syslog-transport-tls in two different
programs (MonitorWare Agent and rsyslog). My focus was the framing, not
tls itself (I needed the new framing for some other functionality, but
that is a separate story). I would like to share my experience during
that
Just for the records: I am also statisfied with this wording.
Rainer
-Original Message-
From: David Harrington [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 28, 2006 6:46 AM
To: 'Miao Fuyou'; Rainer Gerhards; [EMAIL PROTECTED]
Subject: RE: [Syslog] Updated Syslog-tls Document
-Original Message-
From: David Harrington [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 28, 2006 2:08 AM
To: Rainer Gerhards; [EMAIL PROTECTED]
Subject: RE: [Syslog] Shepherding document for udp-08
Hi,
Yes, I/we should correct this.
Do we have any information about
Tom,
-Original Message-
From: tom.petch [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 28, 2006 12:18 PM
To: Chris Lonvick; Miao Fuyou
Cc: [EMAIL PROTECTED]
Subject: TLS RFC was Re: [Syslog] Towards closure of syslog-tls issues
The latest TLS RFC is RFC4346 which is amended by
Hi Miao,
thanks for the update. I have gone through the draft again and found
some, mostly minor, issue. I have listed them below:
-
3.0
==
The security service is also applicable to BSD Syslog defined in
RFC3164 [7]. But, it is not ensured that the
-Original Message-
From: Miao Fuyou [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 22, 2006 10:40 AM
To: Rainer Gerhards; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] Updated Syslog-tls Document
I questioned the need for a version number for the TLS
Hello all,
I have yesterday posted the latest revision of syslog-protocol to the
draft editor. I expect it to come up on the I-D announcement list today.
For those interested in a preview, I have made it available at
http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-protocol-18.txt
David,
there is one minor thing in the shepherding document I do not concur
with:
--
This document describes the traditional udp transport for syslog.
draft-ietf-syslog-protocol makes changes to the syntax of the syslog
fields but this is just the udp transport. It could be said that
all
Tom,
tp
Ports may or may not be scarce but they are expensive.
Introduce a new one and
- anyone with firewall
- anyone with an application level gateway
- anyone with a packet filtering router
has to go out and change each and every box to reflect the
new assignment, a
slow and
Chris,
I mostly agree (but keep my posting on -04 in mind). Some issue below...
Rainer
-Original Message-
From: Chris Lonvick [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 22, 2006 3:03 PM
To: [EMAIL PROTECTED]
Subject: [Syslog] Draft Shepherding document
Chris,
This protocol has very similar characteristics to implementations of
syslog over ssl that are available at this time. Members of
the Working
Group have noted that it should be a very small change to bring those
implementations in line with this specification.
from my
Chris,
Document Quality
Are there existing implementations of the
protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any
reviewers that
merit special mention as
Miao,
-Original Message-
From: Miao Fuyou [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 23, 2006 2:24 AM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] Updated Syslog-tls Document
The public messege can be found at:
http://www1.ietf.org/mail-archive
Hi Miao,
inline
Rainer
-Original Message-
From: Miao Fuyou [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 23, 2006 3:38 AM
To: Rainer Gerhards; [EMAIL PROTECTED]
Subject: RE: [Syslog] Updated Syslog-tls Document
Hi, Rainer,
Thanks for your thorough review!
Some
Hi David,
I'd got no connectivity the past days. Further, I am now on vacation. I
will try to work on -protocol, but I can not promise to do so before I
am back to office (Sept, 18th). Honestly, my top priority currently is
to keep my family happy. I hope you understand. For the very same
reason,
David,
I have just now be able to poll my mail. I trust you as a co-chair that
this time the documents will not be torn apart because of the missing
backwards compatibility. Thus, I agree we should move to octet-couting,
as there is more consensus to use that (and it is technically superior).
I
inline
-Original Message-
From: David Harrington [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 15, 2006 11:25 AM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: byte-counting vs special character
Hi Rainer,
[speaking as co-chair]
Can we change the subject line to byte
Carson,
Legacy code does not contain LF in messages. It is advised that
new-style syslog also does not contain control characters (though it now
is allowed).
Thus the argument is valid. Again, I do not object octet-couting (I
actually introduced the idea ;)) but find it the second best-solution.
-Original Message-
From: Miao Fuyou [mailto:[EMAIL PROTECTED]
Sent: Monday, August 14, 2006 7:07 PM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] timeline
Hi, Rainer,
A new implementation could rely on byte-counting only and
then delete LF
from the frame
-Original Message-
From: Chris Lonvick [mailto:[EMAIL PROTECTED]
Sent: Monday, August 14, 2006 8:33 AM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: Re: [Syslog] Syslog-sign -protocol
Hi All,
On Sun, 13 Aug 2006, Rainer Gerhards wrote:
Hi,
A general comment: syslog-sign
Hi,
A general comment: syslog-sign is still based on rfc 3164 and has ist own
format definitions. It needs to be edited to utilize the new work in
syslog-protocol. It should now use structured data for ist signature blocks.
rainer
___
Syslog mailing
to drastically change their
underlying syslog implementations
Regards,
Nagaraj
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 10, 2006 9:22 PM
To: Balazs Scheidler
Cc: [EMAIL PROTECTED]; Tom Petch
Subject: RE: [Syslog] delineated
The schedule sounds fine to me, but I can offer only limited
availability (both for comments and editing) in the next weeks (chairs
are notified about the specifics, I do not like to post absence
information publically).
Thanks,
Rainer
-Original Message-
From: Chris Lonvick
-Original Message-
From: David Harrington [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 10, 2006 11:33 AM
To: [EMAIL PROTECTED]
Subject: [Syslog] timeline
Hi,
Chris and I are working on a schedule to help the WG meet its
deliverables. We have not yet agreed on all the
Bazsi, all,
I am not really able to follow the thread, but let me put in an
important thought.
We *must* allow LF inside the message. If we do not do that, it would
cause problems with -protocol. This issue has been discussed at length,
and there are good reasons for allowing it. So while I vote
Andrew,
-Original Message-
From: Andrew Ross [mailto:[EMAIL PROTECTED]
Sent: Friday, July 21, 2006 12:52 AM
To: Rainer Gerhards; 'Tom Petch'; [EMAIL PROTECTED]
Subject: RE: [Syslog] delineated datagrams
Rainer,
I'm in favour of using the LF delimiter as a starting point
Miao,
I agree with your comments. However, using the LF as a record delimited
would still allow us to interop with existing syslog/tls
implementations. This is my major point. I think it is worth it.
Rainer
-Original Message-
From: Miao Fuyou [mailto:[EMAIL PROTECTED]
Sent: Friday,
Hi WG,
I just wanted to let you know that I have posted the individual
submission on syslog over ssh:
http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg11360.html
I have done this idependendly of the transport-tls issue. It is, at
best, loosely connected (in that the work was
Tom,
I do not know if rewriting really helps. I suspect Huawei's patent
lawyers, like patent lawyers everywhere, did a good job in wording the
patent application so generally that probably evertyhing we do in
respect to syslog/tls would fall under their claim. Eventually, that
would even apply to
I wonder if all the references to RFC3164 should be revisited in the
light of Rainer's work on syslog-protocol, or is this an environment
which is accurately described by RFC3164?
The current DOCSIS and PacketCable syslog agent/server
environments are
accurately described by RFC 3164.
to
publish at all. IMHO, we have already received our third chance and
there will be no fourth...
Rainer
-Original Message-
From: David Harrington [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 29, 2006 8:32 PM
To: Rainer Gerhards; 'Chris Lonvick'; [EMAIL PROTECTED]
Subject: RE: [Syslog
://www.syslog.cc/ietf/drafts/draft-ietf-syslog-transport-ssh-00pre.t
xt
Thanks,
Rainer
-Original Message-
From: David Harrington [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 22, 2006 6:22 PM
To: Rainer Gerhards; 'Chris Lonvick'
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] IESG
To: 'David Harrington'; Rainer Gerhards; [EMAIL PROTECTED]
Subject: RE: [Syslog] Secure transport alternatives
Hi,
IMO, most current security protocols(TLS, DTLS, SSH, IPsec)
provide similiar
security service for application, such as confidentiality, integrity,
anti-replay and peer identity
Hi all,
I think I have some good news. Huawei has updated its IPR disclosure.
Please see
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=724
The license has dramatically been changed:
**
If technology in this document is included in a standard adopted by IETF
and
signing
and ordering
mechanism to the IESG for consideration as a PROPOSED STANDARD
which is why I see TLS as embedded in the charter (as well
as, more obscurely,
in the discussions that led up to the charter change).
Tom Petch
- Original Message -
From: Rainer Gerhards
]
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 20, 2006 9:44 AM
To: [EMAIL PROTECTED]
Subject: [Syslog] IESG secure transport requirement can be
quickly solved...
Hi all,
I propose to update RFC 3195 in the spirit of syslog
Hi all,
This posting from the netconf WG seems highly relevant. The page itself
uses some crumbersome challenge system, so I could not look at the
actual content. I will do so when the draft is posted on the IETF site
and recommend that other WG members do so, too.
Rainer
-Original
I agree with Tom that a TCP document would be useful and probably
needed. Before someone from Huawei comes along and tries to patent this,
too, I volunteer to write this document...
Rainer
-Original Message-
From: Tom Petch [mailto:[EMAIL PROTECTED]
Sent: Friday, June 16, 2006 10:13
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Sent: Friday, June 16, 2006 11:28 AM
To: Tom Petch; [EMAIL PROTECTED]
Subject: RE: [Syslog] stream
transportwasdraft-ietf-syslog-transport-tls-01.txt
I agree with Tom that a TCP document would be useful and probably
needed
not mandotory.
Rainer
-Original Message-
From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED]
Sent: Friday, June 16, 2006 5:50 PM
To: Rainer Gerhards; Tom Petch; [EMAIL PROTECTED]
Subject: RE: [Syslog] stream
transportwasdraft-ietf-syslog-transport-tls-01.txt
App-layer ACK
Hi all,
I have just submitted this draft. It is a minor update over the previous
version. Most important points for publishing:
- -16 expires soon
- truncation rules releax - no handling of Unicode etc required (as
discussed on list)
- langauge brush-up by Chris Lonvik (thanks again, Chris!)
Chris,
ok, you have pointed to the IPR IETF list, anyhow, one comment on this
list is due:
I do want to be clear on this subject. Hauwei is well within
their rights
to discover something while writing a Working Group document,
and then to
claim IPR on that discovery. This has happened
Hi all,
I agree with Anton on all important issues. I've read the IPR claim and
what disturbs me the most is unpublished pending patent application.
This sounds like someone took what we have been discussing (and is
widely deployed), brought it to a lawyer and is now trying to make some
patent
, Balazs Scheidler wrote:
On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote:
Rainer
I think using a patented technology inside a standard will
definitely
hinder the acceptance of that standard. Especially if it
is something as
trivial as syslog over tls. So my vote is to put
Bazsi,
Agreed, let's go for octet-counting. How would that look like? Two
octets before every message? That would limit message size to 64k, is
that sufficient? (I personally say it is, messages larger
than 64k would
potentially mean that they cannot be held in memory)
there is the good,
Baszi,
I see the following possible upsides of using some kind of framing:
* byte-counted messages, effectively allowing the use of the full
character set
* application layer acknowledgements, avoid losing messages sitting in
the TCP socket buffers without knowing that they were not really
and/or optionally in a revision once
we got some experience with actual implementations.
Rainer
Thanks,
Anton.
-Original Message-
From: Chris Lonvick (clonvick)
Sent: Wednesday, March 15, 2006 5:26 PM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: Framing in syslog
Miao,
thanks for the great (and quick) work. I can not review it fully right
now, but I have seen one issue that I would like to comment immediately
on. More comments follow later.
[Issue 3] The problem of CR LF is it can not process binary data
well. How to process Syslog
-Original Message-
From: David B Harrington [mailto:[EMAIL PROTECTED]
Sent: Monday, February 13, 2006 2:12 PM
To: Rainer Gerhards; [EMAIL PROTECTED]
Subject: RE: [Syslog] implementing -protocol and -transport-udp
Hi,
Just a point. -transport-udp and -transport-tls should be independent
FWIW: I agree with Baszi in all points.
Rainer
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Balazs Scheidler
Sent: Tuesday, January 31, 2006 2:35 PM
To: Tom Petch
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Syslog] Threat model
Chris,
I have not heard back from anyone about how SSL is currently being
implemented for syslog. From that, I might conclude that message
confidentiality is not a priority for the community.
(Responses to that
would be welcome.)
I thought that these postings pointed out what is
choose which one he
needs (that means that nobody is forced to distribute certs or PKI if
only message observation shall be mitigated).
Rainer
Thanks,
Chris
On Wed, 18 Jan 2006, Rainer Gerhards wrote:
Chris,
I have not heard back from anyone about how SSL is currently being
implemented
this to be fairly easy (AFIK our products interoperate via the
stunnel hack over SSL).
Rainer
-Original Message-
From: Balazs Scheidler [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 11, 2006 3:40 PM
To: Chris Lonvick
Cc: Rainer Gerhards; [EMAIL PROTECTED]
Subject: Re: SSH - RE
I'm concerned that your analysis seems to be based on what is easy to
implement.
Well, I have to admit that in the world of syslog people vote with their
feet. If it is not easy to implement (better said: deploy), the majority
will not deploy it. Maybe I have a false impression, but I think I
I agree with Balazs suggestion and his reasoning.
Rainer
-Original Message-
From: Balazs Scheidler [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 10:52 AM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] Charter comments from IESG Review
On Mon, 2006
Hi Sam WG,
I understand the reasoning behind requiring a security mechanism. I just
want to remind everyone that a major drawback in Vancouver was that we
had lost some backwards-compatibility to existing syslog
implementations.
The weeks after Vancouver we worked hard to find a minimum
Tom,
If so, yes, both S/MIME and OpenPGP support this model.
However I'll
point oun that it is not a requirement that syslog work
that way; for
example RFC 3195 certainly has connections.
I'll look at those, thanks. I agree syslog could be, perhaps
should be for
meaningful
-Original Message-
From: Sam Hartman [mailto:[EMAIL PROTECTED]
Sent: Monday, January 09, 2006 1:08 PM
To: Rainer Gerhards
Cc: Tom Petch; [EMAIL PROTECTED]
Subject: Re: [Syslog] Charter comments from IESG Review
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes:
Rainer
Sam,
Rainer Why? Simply
Rainer because any transport-layer requirement (DTSL, SSL, SSH,
Rainer whatever) would NOT be compatible with currently existing
Rainer syslog implementations. So due to this requirement, we can
Rainer not create a backwards-compatible spec (not
. To specify what you recommend, this is not necessary, so this
is not really a discussion topic here.
Rainer
Thanks,
Anton.
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Sent: Monday, January 09, 2006 3:21 AM
To: Anton Okmianski (aokmians)
Subject: RE: [Syslog
To: Rainer Gerhards; [EMAIL PROTECTED]
Subject: Re: [Syslog] #7, field order
Not sure I have grasped the problem yet but the cases you
cite would appear to
be covered by rules of the form, using pseudo-English as a shortcut,
FIELD = ONECHAR / MORECHAR
ONECHAR = anyprintable character except
1 - 100 of 130 matches
Mail list logo
