> > > What exactly does this mean? If it means that the implementation is free
> > > to store records any way it likes on the disk, then I agree. I disagree
> > > if it means the WG produces a document that merely says something like:
> > > "Logs are sent as an uninterpreted ascii stream over port TCP port XXX,
> > > with IPsec as an option for authentication and confidentiality."
> > >
> > > Without structure in the messages, we're still stuck with the current mess
> > > where programs can't parse logs without all kinds of special log-specific
> > > knowledge.
> >
> > The message that came out of the BOF was that this is a different problem
> > to the original one (of investigating the security problems inherent with
> > the current proyovol), being looked at, and may even be the responsibility
> > of a different group (such as IDWG - Intrusion Detection). The IETF does
> > not encourage or support redundant and separate efforts being made to work
> > on the same thing.
>
> So this essentially limits us to the current protocol which sends a numeric
> facility, a numeric severity, and then a textual message.
I think the replacement must support the old API that allows logging
only an unstructured text message. However, it does seem that the
message could be structured, e.g. XML encoded ULM tags and event data
model. This could be segregated from the unstructured streams by
limiting them to the old facilities codes, or a small subset of facility
codes. The XML encoding service would effectively form a layer above the
old syslog(3) API, supporting the new facility codes with an object
oriented data model.
The real question is whether the scope of the discussion should include
the event and logging process data model of ULM and this current
discussion. IETF comments seem to indicate it should not, because the
Intrusion Detection WG (IDWG) and possibly other activities are
producing data models that are somewhat related. I think it should,
because the lack of an event model and a structured representation are
serious problems in managing event data for security applications of
event logging, and XML seems a natural way to approach both the schema
and encoding of this model.
There was no consensus on encoding and transport of attack event records
in the IDWG meeting I attended -- there seems to be an SNMP-centric
contingent that wants a MIB -- but XML is definitely under discussion
there. Note that their data model is both more restricted and much
larger, because they are dealing with events that indicate a possible
attack, not general network and system event notification. I think we
should continue to develop both the event data model and an XML encoding
and approach IDWG with it, to get their input on the schema.
I get the strong sense that we have been invited to proceed even if
there's still no formal blessing of the working group. Some toes may be
trod upon, hopefully lightly, but that seems to be the way things happen
at the IETF.
--
Alex Brown <[EMAIL PROTECTED]> +1 617 504 8761
