On Fri, Dec 22, 2006 at 07:17:18PM +0100, tom.petch wrote:
> I am not convinced that the proposed solutions match the underlying problem.
>
> Syslog:
> - can be -protocol or RFC3164 (or RFC3164bis or ...)
> - may be signed.
> - may be secured with TLS (or SSH or DTLS or ...)
> - could run ov
I am not convinced that the proposed solutions match the underlying problem.
Syslog:
- can be -protocol or RFC3164 (or RFC3164bis or ...)
- may be signed.
- may be secured with TLS (or SSH or DTLS or ...)
- could run over UDP or TCP (or SCTP or ..)
What we have then done is to bind -protocol
Much of the reason 3195 is specified is because there is no good
alternative. Healthcare has been asking for a stable standard that gets
implemented for 4 years now. It is getting hard to justify this
allegiance to the syslog community. There are many in the healthcare
community that want to define
Ah... interesting. I knew that Cisco had something brewing, but I never
heared that it was released. I still agree with you that 3195 should not
specifically be mentioned by -sign. I assume that implementing 3195bis
(when available) is probably not hard if you implemented 3195.
Rainer
> -Ori
Hi,
I'm OK removing references to RFC 3195 from syslog-sign for the points you
mention. I'd welcome other opinions.
I agree that RFC 3195 is due for an update but I disagree with most of
your other points. A major vendor has found customers requesting it and
has implemented it.
http://www
> The Chairs have been discussing this already. We have a candidate to
> write the update. The length limit in RFC 3195 was constrained by RFC
> 3164 and we have moved beyond that with the transport IDs which
> identify
> realistic maximum lengths. Updating RFC 3195 to have a greater length
> sh
Hi,
The Chairs have been discussing this already. We have a candidate to
write the update. The length limit in RFC 3195 was constrained by RFC
3164 and we have moved beyond that with the transport IDs which identify
realistic maximum lengths. Updating RFC 3195 to have a greater length
shou
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
sign-gen
Hi,
The Chairs have spoken to the author of RFC 3164. The author agrees that
it should be OBSOLETED. ;-)
I did discuss this with someone who has been trying to de-cruft a lot of
ancient RFCs. It is not usual to OBSOLETE an INFORMATIONAL RFC but
there's nothing that says that we can't do i
Hi,
Overwhelming consensus is that references to 3164 will be removed from
syslog-sign.
Alex, Please start working on this but don't submit any changes until
after WGLC is complete on 28 Dec.
All: Please continue to review the document and let's get this out the
door.
Thanks,
Chris
P.S
I agree; make it obsolete, acknowledging the role it has had in moving syslog
along.
Tom Petch
- Original Message -
From: "Anton Okmianski (aokmians)" <[EMAIL PROTECTED]>
To: "Rainer Gerhards" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, December 21, 2006 7:12 PM
Subject: RE:
On Fri, Dec 22, 2006 at 11:24:10AM +0900, Glenn M. Keeni wrote:
> >- How do I find out which encapsulations are supported (plain, beep,
> > tls, ...)?
> That is the problem we are trying to solve.
> Can that be done by defining appropriate domains for
> syslog transport over TLS
> syslog
12 matches
Mail list logo
