I agree with your concerns.
I believe the only real issue you need to solve before you are done
with the chartering discussion is whether you are going to have a
transport or whether you are going to use something like syslog-sign.
I *think* that you'll need to know what security threats you cons
Rainer and all:
I'd like to propose a slight terminology change for syslog protocol for
structured data. I think there is confusion even in this group about current
terminology. For example, we (me included) keep referring to "structured data
element", when we mean "structured data parameter".
I think that you are leaping too soon into implementation space. That is
why the threat model is requested first. Off the top of my head here are
some components of the threat model. I organize these in terms of "Asset,
Threat, Mitigation". There are certainly more threats because I know I
have
Banzsi:
I agree truncation does not solve the issue - that's why I don't want to
over-design it.
Splitting is an option I'd leave to application-layer running above syslog. It
is not precluded. Just a matter of another RFC with extra sd-elements.
If we do fragmentation in syslog transport/p
Hi Sam,
I also have a concern that we may try to craft an answer that provides
good security but that won't actually be deployed. As an analogy, snmp
has similar characteristics to syslog. usm has good security properties
but has not been widely deployed. isms is trying to redress that and
On Thu, 2006-01-12 at 10:45 +0100, Rainer Gerhards wrote:
> Anton & all,
>
> You have good points and I have to admit I am still thinking what is the
> best way. I would appreciate if some other WG members could express
> their thoughts...
My pragmatic view is that overly long messages should be
Anton & all,
You have good points and I have to admit I am still thinking what is the
best way. I would appreciate if some other WG members could express
their thoughts...
Thanks,
Rainer
> -Original Message-
> From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday,
