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
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes:
Rainer Hi Sam WG, I understand the reasoning behind requiring a
Rainer security mechanism. I just want to remind everyone that a
Rainer major drawback in Vancouver was that we had lost some
Rainer backwards-compatibility to
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes:
Rainer 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
-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
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes:
Rainer Sorry, yes, I was totally wrong in my wording. What I
Rainer intended to say was that the keys are exchanged on a
Rainer medium different then the current session (e.g. key
Rainer servers).
This is not typically how
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
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes:
Rainer This looks like I misunderstood your intension. I thought
Rainer that unsecured UDP should no longer be supported.
That was not my intent.
Rainer So what
Rainer you actually said is that we can go ahead with the
Rainer:
I agree - this is better than a convoluted rule.
I think we only have any business in defining truncation for
relays. For collectors, we have tried to stay away from
describing how messages are stored.
For relays, I think it would be useful to state that relay
can't
Rainer:
I agree - this is better than a convoluted rule.
I think we only have any business in defining truncation for relays. For
collectors, we have tried to stay away from describing how messages are stored.
For relays, I think it would be useful to state that relay can't just drop
Sam
I was about to say that we were getting into useful detail but that we could
sort out the charter without it, but you seem to saying not. That is, I was
hoping that where the charter says
The goal of this working group is to address the security and integrity
problems
it might say
Tom == Tom Petch [EMAIL PROTECTED] writes:
Tom without committing us to either a -sign or a secure transport
Tom approach (and yes, we did start the transport wars, some time
Tom ago, with SSH v TLS:-(
I really think that you need to identify your deliverables in the
charter.
12 matches
Mail list logo
