> Maybe this already has been said ;)
>
> This makes sense. What about other control characters?
>
We need to differentiate between on-the-wire format and storage format.
On-the-wire, I would escape only LF and the escape character. In
storage, I would escape any control character (which can be
> -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 a
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
o Fuyou
> Cc: Rainer Gerhards; 'Tom Petch'; [EMAIL PROTECTED]
> Subject: RE: [Syslog] delineated datagrams
>
> Hi,
>
> I'd like to get this resolved and put into the next version
> of the draft.
>
> Many protocols use byte-counting for framing.
> Many p
Hi WG,
Quickly from the plane. Tom Patch and me have put some thoughts into
dtls encypted syslog. This is not realted to the IPR discussion. We just
find that would be an intresting concept. I've talked to Chris before
starting this work, he has permitted to post it to the WG mailing list.
However
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: Frida
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 f
Anton,
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Anton Chuvakin
> Sent: Thursday, July 20, 2006 6:13 PM
> To: Rainer Gerhards
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Syslog] syslog over ssh
>
> Rainer and all,
>
ginal Message-
> From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 06, 2006 4:17 PM
> To: Tom Petch; [EMAIL PROTECTED]
> Subject: RE: [Syslog] delineated datagrams
>
> Tom,
>
> I think your and Anton's commetn below so far is the most important
&g
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 spawned
Quick review:
Section 2.3:
It looks like the syslog-ng option is vendor specific. In practice,
there are many implementations that interoperate with "plain tcp
syslog". At least these I know: Cisco PIX, Kiwi Syslog Daemon, rsyslog,
Adiscon MonitorWare, EventReporter & WinSyslog and probably SDSC
> >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 3
Tom,
I think your and Anton's commetn below so far is the most important
comment on -transport-tls technical issues (assuming that the
certificate issue can relatively easy be fixed by specifying a cipher
suite).
IMHO the comment applies to any shim layer for stream protocols, not
just TLS. I thi
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
Darren,
I think this is a good proposal, though most importantly Balazs needs to
like it ;)
I just see one problem. We need to deliver a secure transport by
November. Implementing, documenting and discussing a new approach is
probably beyond that time frame (especially given the summer holidays).
not publish soon, we will never be able 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 Gerhar
Besides the somewhat political issue, I think there is also technical
issue that affects the question. I think we should consider that
question in parallel to the IPR question.
This question is if this WG intends to do a revision of 3195. And, if
so, I think the very close next question is if we "
create 3195bis, satisfy the IETF secure transport criteria
with that, PUBLISH and then carry on with all the well thought-out ideas
we have.
Rainer
> -Original Message-
> From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 26, 2006 11:50 PM
> T
://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 PROTECTE
David Harrington
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> co-chair, Syslog WG
>
>
> > -Original Message-----
> > From: Chris Lonvick [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 20, 2006 10:05 AM
> > To: Rainer Gerhards
>
e
coordination between the syslog and netconf WG, which I hope is not a
big problem.
Rainer
>
> My $.02 as a contributor,
>
> David Harrington
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
>
> > -Original Message-
> > From:
Tom:
[big snip]
> You may recall we have had discussions of length v end of
> record marker before
> (and yes, I do like end of record markers:-)
I see your concerns and think they are valid. I have argued for using a
length in the header instead of an end of record marker. But this is
differe
sions that led up to the charter change).
>
> Tom Petch
>
>
> - Original Message -
> From: "Rainer Gerhards" <[EMAIL PROTECTED]>
> To: "Tom Petch" <[EMAIL PROTECTED]>; "David Harrington"
> <[EMAIL PROTECTED]>; <[E
also have to admit that these were the guys that acutally found the
update IPR disclosure. I had not indicated this in my previous mail
because I asked them for permission to use their name and had not yet
received it at the time of my posting.
Rainer
> -Original Message-
> From:
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 anyc
"David Harrington" <[EMAIL PROTECTED]>
> To: "'Rainer Gerhards'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Wednesday, June 21, 2006 7:58 PM
> Subject: [Syslog] Secure transport alternatives
>
>
> > Hi,
> >
> > [
ursday, June 22, 2006 7:49 AM
> 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
ust my 2cts, but I hope I find support for it.
Rainer
> -Original Message-
> From: Darren Reed [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 22, 2006 4:48 AM
> To: David Harrington
> Cc: 'Chris Lonvick'; Rainer Gerhards; [EMAIL PROTECTED]
> Subject: Re: [Syslog]
Phil,
> >RFC 3164 and syslog-protocol both list names (e.g.
> "authorization" and
> >"emergency") as well as integer numbers for PRI contents.
> However, only
> >the integers are normative (see ABNF in syslog-protocol, PRI
> description
> >in RFC 3164). It has also been observed in practice tha
Hi all,
I propose to update RFC 3195 in the spirit of syslog-protocol to satisfy
the IESG secure transport requirement (I will call this derivative work
RFC3195bis below). I sincerely believe that this option would enable us
to submit syslog-protocol, -transport-UDP and RFC3195bis within a few
wee
as some implementations of it. I suggest a reference is made to
3195 to clarify on that issue (and so that a casual reader will become
aware that there is more to look at then 3164 and syslog-protocol).
I hope these comments are useful.
Best regards,
Rainer Gerhards
> -Original Message---
http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt
I would appreciate comments on the I-D as we are working towards
submitting it.
Thanks,
Rainer
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/sy
Miao,
the idea of describing syslog over tcp is not to use this as an actual
transport, but to provide this as an interim for other stream transport,
e.g. for use by ssh. The more I think about it, the more logical it
sounds to define how syslog framing works over a stream (not necessarily
tcp). T
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 Message
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
Anton,
> -Original Message-
> From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 16, 2006 5:25 PM
> To: Tom Petch; [EMAIL PROTECTED]
> Subject: RE: [Syslog] stream
> transportwasdraft-ietf-syslog-transport-tls-01.txt
>
> I was just talking to Rainer about s
> -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 woul
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:
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!)
Con
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 happ
Darren,
I think you have mis-read the IPR disclosure. The section numbers in roman
numbers refer to the IPR claim and not the I-D sections.
I would also like to voice that I am very happy that David is co-charing this
group. The current discussion has shown how professional and ethical his
lea
ED]
> Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt
>
> Hi,
>
> On Thu, 8 Jun 2006, Balazs Scheidler wrote:
> > On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote:
>
>
> >> I think using a patented technology inside a standard will
> d
port-tls-01.txt
>
> Hi,
>
> On Thu, 8 Jun 2006, Balazs Scheidler wrote:
> > On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote:
>
>
> >> I think using a patented technology inside a standard will
> definitely
> >> hinder the acceptance of that s
Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 08, 2006 4:19 PM
> To: Balazs Scheidler; Rainer Gerhards
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt
>
> I don't agree with putting all work on hold. Syslog-pro
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 o
Hi all,
Chris helped me brush up the ID, which I really appreciate. I am about
to publish a new version soon. There is one thing that Chris
recommended:
---
I'd like to suggest that Section 6.2.1.1 (Relation to Alarm
MIB) be dropped from this document. We discussed the request for this
relatio
Hi David,
I volunteer to
> 1) a person to check the grammar?
> 2) a person to check the syslog technical parts?
> 3) a person to check compatibility with the other WG documents?
>
> We also need general reviews of the document by multiple people.
>
I can not do
> 4) a person to check the TLS
WG,
this is another posting from the NETCONF WG which I also consider quite
important for the syslog WG.
Rainer
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Harrington
> Sent: Tuesday, March 28, 2006 8:26 PM
> To: 'Netconf (E-mail)'
> Su
Hi all,
I have been silent so far on this topic, because I have not made my mind
up yet. However, let me point you to some important fact:
APP-NAME would be e.g. "postfix", "kernel", "syslogd", ... So you have a
potentially very large number of APP-NAMES all sent from the same
syslogd. I think th
My opinion is that this should not be a MUST, maybe not even a SHOULD. I
think this decision needs to be left to the operator. While it is
advisable to authenticate peers, operators might decide against it. This
is especially the case in SOHO environments, where the user is typically
not knowledgea
Miao,
> Section 1 of RFC2817(Upgrading to TLS Within HTTP/1.1) says
> that special
> port is not preferable for security. Now the situation is
> that there is not
> an IANA allocated TCP port for Syslog. So I think it is reasonable to
> request a special port for syslog-tls. The disavantage is
Miao, all,
I've already sent a message on similar discussion in the netconf wg.
Please read this too. In this mail, I try to provide argument why (and
how) we should use a dedicated port and that port should be in the range
< 1024. I try to word my arguments so that they can also be used in
negoti
Hi all,
the exact same issue (dedicated port or not and if so in which port
range) has been discussed on the netconf mailing list. I encourage
everyone to have a look at their archive. For details on netconf
(including mailing list archive link), please see:
http://www.ops.ietf.org/netconf/
B
am in strong favour of a dedicated tls-transport only
header for the octet count.
Rainer
> -Original Message-
> From: Chris Lonvick [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 17, 2006 5:38 PM
> To: Rainer Gerhards
> Cc: Balazs Scheidler; [EMAIL PROTECTED]
> Subje
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 goo
bably done in another transport 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:
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 rea
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 signature/ce
IESG:
we (Adiscon) will implement the upcoming new drafts in our softwares
WinSyslog, EventReporter, Monitorware Agent and rsyslog (already has a
proof-of-concept implementation of -protocol and -transport-tls).
Best regards,
Rainer Gerhards
Adiscon
> -Original Message-
> From
I agree with Anton. I would *expect*, however, that on the same client
the same cert is used. I would expect that multiple clients also use the
same cert (with less likelyhood). I would not outrule any of the
"unexpected" cases.
If you look at the current deployments using stunnel, you can find th
> -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 a
Hi all,
it is nice to see us making progress. However, as we need to finish (and
start) a secure transport before we can submit -protocol and
-transport-udp, I have a question to the implementors here on the list.
-transport-udp is basically finished and -protocol just needs a brush up
(aka "hopef
> > when you look at the wish that some users
> > express for encyption, namely both are a one way flow over
> a datagram transport
> > with some application client out there somewhere:-) And as
> I said, these issues
> > have been mulled over by isms and netconf and, a year or so
> on, there a
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 mode
I agree with Darren.
Rainer
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Darren Reed
> Sent: Friday, January 20, 2006 3:07 PM
> To: Chris Lonvick
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Syslog] Re: Threat model and charter
>
unauthenticated TLS
- authenticatated TLS
both are mandatory to implement but the user can 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, Rai
Tom,
I agree there are some issues with truncation, but I think they are
inherent. We have specified that the message should be truncated at the
end of the message. In the text I proposed, I wanted to make sure that
the message ends with a technically-complete UTF-8 sequence. Based on
Anton's comm
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
ainer
> -Original Message-
> From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 12, 2006 9:41 PM
> To: Rainer Gerhards
> Cc: [EMAIL PROTECTED]
> Subject: SD-ELEMENT names
>
> Rainer and all:
>
> I'd like to propose a slight
nt: Wednesday, January 11, 2006 6:18 PM
> To: Rainer Gerhards
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Syslog] Sec 6.1: Truncation
>
> Rainer:
>
> Thanks for the update. Comments below.
>
> > I have now changed section 6.1 to:
> >
> > ###
> > 6.
Anton,
> (d) Do we have to address message observation threat? If not.
> Then we don't need neither TLS/SSH - syslog-sign would do.
> This does not prevent new transport to be used. Some can be
> used by just underlying tunnels anyway.
Based on my (obviously limited) experience, this is the
Sam, thanks for your reply, I think I am getting closer (and many thanks
for bearing with me)...
>
> >> We also need to do the analysis of what security is actually
> >> required by syslog deployments. If the ansers are different,
> >> we'll have to deal with that.
>
> Rainer>
o what is already
being deploed (signing shouldn't be too hard for an implementor if
openssl is already used for TLS...).
Rainer
> -Original Message-
> From: Chris Lonvick [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 11, 2006 3:19 PM
> To: Balazs Scheidler
> C
> 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
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]
>
OTECTED]
> Sent: Wednesday, January 11, 2006 1:04 PM
> To: Rainer Gerhards
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Syslog] Re: Threat model and charter
>
> On Wed, 2006-01-11 at 10:37 +0100, Rainer Gerhards wrote:
> > Chris,
> >
> > However, it *is* possible
ainer
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards
> Sent: Monday, January 09, 2006 4:49 PM
> To: Anton Okmianski (aokmians)
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Syslog] Sec 6.1: Truncation
>
> >
Chris,
I can probably not comment on everything in the conversation between
Chris and Sam, but I can put in some real-world experience. With syslog,
we have not (yet) natively implemented TLS (this is planned, but if an
I-D will surface, we'll probably wait a little bit and try to do it "the
stan
> > 1) transport level implements security mechanisms on a per
> hop-by-hop
> > basis, the message itself is not authenticated, each of the relay
> > stations can modify the message
> >
> > 2) syslog-sign implements per-message, end-to-end
> authenticity where the
> > relay hosts cannot modify m
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 I
me a
separate document, so I would prefer not to dig too deep into relay
behaviour. 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 Gerhar
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 sp
> -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&qu
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
> mean
Chris,
> > 1) Require some transport like syslog over TLS|DTLS be implemented.
>
> RFC 3195 requires the use of RFC 3080 which requires TLS.
small glitch: RFC 3080 provides support for a TLS profile, but it does
not mandate it. Most existing RFC 3195 implementations do NOT support
the TLS tunin
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 consens
Hi all,
first of all, I would like to whish a happy new year to each of you!
I am now back in the office and at final edits to syslog-protocol. I
discovered one more thing: The current draft supports leap seconds.
There already is a lot of discussion whether or not leap seconds should
be introduc
r 22, 2005 10:27 AM
> 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 = ONEC
al Message-
> From: David B Harrington [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 15, 2005 6:50 PM
> To: Rainer Gerhards; 'Darren Reed'
> Subject: RE: [Syslog] #7, field order
>
> Hi,
>
> Having a public feud won't help us achieve our goals.
>
tch [mailto:[EMAIL PROTECTED]
> Sent: Saturday, December 17, 2005 4:59 PM
> To: Rainer Gerhards
> Cc: [EMAIL PROTECTED]; Chris Lonvick
> Subject: nailing down characters in syslog-protocol
>
> I would like to see a stricter definition of characters in
> syslog-protocol.
> Wi
Darren,
that's why I take your comment not seriously:
> > data for that field.
> >
> > If you don't understand the difference here, I think the fields need
> > to be defined something like this:
> >
> > field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255
> > missing ::= "-"
>
> And
OTECTED]
> Sent: Wednesday, December 14, 2005 3:14 PM
> To: Rainer Gerhards
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Syslog] RE: syslog-protocol draft
>
> > Darren,
> >
> > I have seen nobody backing your position, so I think it was
> consensus to
> > i
Darren,
I have seen nobody backing your position, so I think it was consensus to
ignore these comments.
Rainer
> -Original Message-
> From: Darren Reed [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 14, 2005 2:30 PM
> To: Rainer Gerhards
> Cc: Balazs Scheidler; [
Bazsi,
> > many thanks for your mail. I am working on a new draft. But as it is
> > xmas time, it's quite busy, so other things also come into
> my way. My
> > goal is to finish a new version before xmas holiday, but I can not
> > totally commit on that. I'd appreciate if you could review
> it w
comes out.
Many thanks,
Rainer
> -Original Message-
> From: Balazs Scheidler [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 14, 2005 1:50 PM
> To: [EMAIL PROTECTED]
> Cc: Rainer Gerhards
> Subject: syslog-protocol draft
>
> Hi,
>
> I was just wonder
Hi WG,
as it looks, there seems to be another implementation of RFC 3195. I am
forwarding this from the RFC 3195 list.
Rainer
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Peter Hall
> Sent: Saturday, December 10, 2005 3:08 PM
> To: [EMAIL PROTE
Chris,
I can agree to what you propose. So it's fine with me.
Question: does it make any sense to answer some of Patrik's questions (in order
to obtain some more advise). I guess he is pretty busy, so we might save this
for later. I'd appreciate your advise.
Rainer
> -Original Message---
Hi WG,
the topic of MSG encoding as well as its content (e.g. NUL and LF
characters) has not yet been solved. The past days, I've talked to a lot
of my friends not on this list and I have also looked at various ways to
solve the issue. Be prepared, this is another long mail, but I think it
is appr
OTECTED]
> Sent: Thursday, December 01, 2005 7:11 PM
> To: Rainer Gerhards; Tom Petch; [EMAIL PROTECTED]
> Subject: RE: [Syslog] #7 field order
>
> Rainer, a better way to phrase this is may be that none of
> the fields are optional (except for maybe SD, depending on
> how you
Chris,
Wouldn't David's text be suitable? I think it is very clear and precise.
With it, probably the whole issue hadn't started. I know this WG likes
it very brief, but isn't it worth the extra lines?
Rainer
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
101 - 200 of 291 matches
Mail list logo
