Subject: Unresolved Proposals (Sangree) (Message 3 of 4)

From: "David A. Curry" <[email-masked]>
Date: Wed, 03 Jan 2001 14:00:56 -0500

The following items were proposed by Paul Sangree, but not resolved at the San
Diego meeting.

 1. Add <AdditionalData> to <Classification> to allow the provision of other
    information besides a URL and a name.

    *** NOTE: This proposal was not discussed in San Diego.

    *** COMMENT: I'm not sure I'd do this; it would make processing the
        classification much harder for managers.  You can use the existing
        <AdditionalData> to do this (especially once we allow it to contain
        arbitrary tags), and that keeps all the "weird" stuff in one place.

 2. Add a <Context> element for representing alert context.

    *** NOTE: It was agreed in San Diego that this proposal needs more work.

 3. Add summarized lists (count attributes).

    *** NOTE: It was agreed in San Diego that this is generally desirable, but
	that the issue of which particular elements should have count
	attributes added to them needs further work.

 4. Add information about automated actions taken by an analyzer.

    *** NOTE: This proposal was not discussed in San Diego.

    *** COMMENT: We used to have these, and they were removed (I believe at
	the 2/2000 interim meeting) because we couldn't come up with a set of
	standard actions, and free-form information didn't seem appropriate.
	This information can always be included in <AdditionalData>.

 5. Remove <sport> and <dport> from <Service> and add <port> to <Source> and
    <Target>, to allow specifying multiple source ports.

    *** NOTE: This proposal was not discussed in San Diego.

 6. Add "class", "manufacturer", "model", and "version" attributes to the
    <Analyzer> element to allow analyzers to be better identified, and to
    give hints on what stuff in <AdditionalData> might mean.

    *** NOTE: This proposal was not discussed in San Diego.

 7. Fix the definition of the "impact" attribute by breaking it into three
    smaller attributes, "severity", "completion", and "type".

    *** NOTE: It was agreed in San Diego that the idea of breaking this up is
        desirable, but that the specifics still need to be worked out.  Most
        people liked a "severity" with three (hi/med/low) to seven (use the
        ones from syslog - emerg/alert/crit/err/warning/notive/info/debug)
        values.