Subject: Resolution of Comments on Last Call of IDMEF

From: Mike Erlinger <[email-masked]>
Date: Mon, 10 Dec 2001 09:56:59 -0800

Attached is a list of Glenn's comments and the various responses to them.
We will discuss each of these and hopefully reach consensus on any
modifications to the lastest version of IDMEF.  Since the WG Last Call
is over, we will handle no new comments, but rather seek to quickly
reach consensus on the following open comments.

mike
----------------------------------------------------------------------------------------

 <Glenn> 0. Some of the	references point to expired documents (e.g. ref	3).

 ------------
 Dave

 The references	are to the most	recent versions	of the documents, although yes,
 those have expired.  There's not much that can	be done	about that other than

 to keep resubmitting them every six months.

 I believe there was a plan to move the	requirements document (and maybe the
 SMI/XML document, I forget) to	"informational"	RFC status when	we submit all

 this stuff.  I	don't recall the details or know the status of this, however.
 -----

 PROPOSED  RESOLUTION

 We will remove	the references.	 The only document that	the WG has agreed
 to move forward is the	requirements document.	Therefore references to

 the others will be removed.

 *************************************************************************

 Glenn>	1. Section 3.1 could do	with some more pruning.

 --------------
 Dave

 This section has not changed in quite some time.  Is there something specific
 you want to cut?

 -------------

 PROPOSED RESOLUTION
 No further comments on	the mail list.	Therefore this issue is	closed.

 *************************************************************************

 Glenn>	2. sec 4.4.7 NTP timestamps. the definitions is	not very clear.

 Glenn>	textual	representation of two 32-bit numbers separated by a '.'.
 Glenn>	That is	what we	want - right ?

 --------------
 Dave

 No, two hexadecimal representations (not "textual," that's too	vague).	 I
 think the sentence that's there is pretty clear on this.

 But if	you have alternate wording to propose...?

 -------------

 PROPOSED RESOLUTION
 No further comments on	the mail list.	Therefore this issue is	closed.

 *************************************************************************

 Glenn>	3. I am	alarmed	to see that Alert-ID is	optional. I feel this encourages

 Glenn>	sensors	to break mamagers.
 -------------

 Dave

 Alert-ID is not optional.  It will always appear in an	alert; it may have the
 value of zero (the default).  We have always permitted	the value of zero for

 analyzers that	cannot generate	unique ids.

 The rules on whether or not Alert-ID must be provided have not	changed.  The
 only rules that have changed are the uniqueness rules;	the current rules as

 reflected in the document were	decided	upon at	the March, 2000	IDWG meeting.
 -------------

 PROPOSED RESOLUTION

 Daves comments	indicate that Glenn misread the	document.
 No further comments on	the mail list for a different wording.

 Therefore this	issue is closed.

 *************************************************************************

 Glenn>	4. Sec 5.2.4 figure 5.7	-  The AdditionalData class appears twice

 ------------
 Dave

 Fixed.
 -----------

 RESOLUTION
    Fixed

 *************************************************************************

 Glenn>	5. Sec 5.2.4.1 The Analyzer Class

 Glenn>	The text says: The Analyzer class identifies the analyzer from which
 Glenn>	the alert or heartbeat message originates.  Only one analyzer may be

 Glenn>	encoded	for each alert or heartbeat, and that MUST be the analyzer at
 Glenn>	which the alert	or heartbeat originated. ....

 Glenn>	I do not think that we are very	clear about the	"origination" of the

 Glenn>	alert. A clarification about this would	probably avoid confusion.
 ------------

 Dave

 I think the sentence that follows the two you quoted above clarifies what we
 mean pretty well (i.e., we don't let you record "relay" analyzers along the

 way).

 But if	you have a clarification you like better than you want to propose...?
 ------------

 Andy
 I agree. I think the text as written is clear.

 ------------

 PROPOSED RESOLUTION
 Mail list comments indicate that clarification	is there.

 No further comments on	the mail list for a different wording.
 Therefore this	issue is closed.

 *************************************************************************

 Glenn>	6. Sec 5.2.4.1 The Analyzer Class

 Glenn>	This class seems to be mandatory. But all the constituent elements are
 Glenn>	optional !

 ------------
 Dave

 No, the analyzerid attribute is not optional.
 ------------

 *************************************************************************

 Glenn>	7. Sec 5.2.4.2 The Classification class
 Glenn>	The text says The Classification class provides	the "name" of an alert,

 Glenn>	or other information allowing the manager to determine what it is (for
 Glenn>	example, to decide whether or not to display the alert on-screen,

 Glenn>	what color to display it in, etc.).

 Glenn>	The example does not seems very	appropriate.

 ---------
 Dave

 If you	have a better example to propose...
 ---------

 Andy
 I'd tend to agree with	Glen here a bit. The purpose of	the sentence in

 question is to	get the	point across that the class tells the Manager how
 to logically interpret	and categorize the alert message and thus assumes

 that such ability is desired, but then	the parenthesized "for example"
 speculates on the reasons a manager might wish	to categorize. I see

 Glenn's point that the	example	doesn't	completely match the point. Do we
 ened an example? Can we take it out? If not, maybe change it to something

 like "for example, to relay specific alert information	and references from
 the analyzer to the manager"

 ---------

 PROPOSED RESOLUTION
 Either	remove the example or Add Andy's comments.

 *************************************************************************

 Glenn>	8.  Sec	5.2.4.2	The Classification class
 Glenn>	The text says: url  Exactly one.  STRING.  A URL at which the manager

 Glenn>	(or the	human operator of the manager) can find	additional information
 Glenn>	about the alert.  The URL may include an in-depth description of the

 Glenn>	attack,	appropriate countermeasures, or	other information deemed
 Glenn>	relevant by the	vendor.

 Glenn>	The "URL may include" may be confusing.

 ---------

 Dave
 Changed "URL" to "the document	pointed	to by the URL"

 --------

 RESOLUTION
 Fixed

 *************************************************************************

 Glenn>	9. Sec 5.2.4.4 The Target Class

 Glenn>	The text says: Node  Zero or one.  Information about the host or device
 Glenn>	that is	receiving the events (network address, network name, etc.).

 Glenn>	Sensors	(network sensors) will probably	never know if the target IS
 Glenn>	"receiving".

 ---------

 Dave
 Changed to "...at which the event(s) is being directed."

 ---------
 RESOLUTION

    Fixed

 Glenn>	Same probably applies to "Source". class.

 ---------

 Dave
 I don't believe it does.  Source says "...is causing the event(s)."

 ---------
 PROPOSED RESOLUTION

    No Further comments	on the mail list, leave	as is.

 *************************************************************************

 Glenn>	10. Sec	5.2.4.6	The AdditionalData Class
 Glenn>	The Type attribute seems to be irrelevant. Or, have I missed

 Glenn>	something?
 -----------------

 Dave
 Why do	you believe it to be irrelevant?  It specifies the type	of data	that

 the element contains; without knowing that, a manager (especially one that
 may not know what the data is,	but wants to show it to	the user or some

 such behavior)	cannot do anything meaningful with the data.
 -----------------

 PROPOSED RESOLUTION
    No Further comments	on the mail list, leave	as is.

 *************************************************************************

 Glenn>	11. Sec	5.2.6 The Assessment Classes

 Glenn>	Is it OK to have "textual descriptions of  impact" ? This raises the
 Glenn>	basic issue -

 -----------------
 Dave

 Unless	you have an all-encompassing pleases-everybody set of attributes that
 we can	use instead...

 This has been a topic at more than one	IDWG meeting; I	don't believe it was

 ever resolved.	 The current approach is to have some broad categories,	but
 to leave the details to free-form text.  This way, at least the information

 gets up to the	manager, even if we can't solve	the standard format problem
 now.

 -----------------
 Eric Williams

 While I feel there may	become a tendency early	on to overuse the
 "free-form" nature of the "textual descriptions of impact" that

 tendency will most likely be short lived.  Based on some of the other
 discussion on this issue re: "verbosity" it seems likely more compact

 forms will prevail and	thus deprecate the textual description as
 things	move forward.  Textual is OK, a	good short term	compensatory

 measure.
 -----------------

 PROPOSED RESOLUTION
    No Further comments	on the mail list, leave	as is.

 *************************************************************************

 Glenn>	is the IDMEF meant to facilitate mechanical interpretation

 Glenn>	of alerts ?
 Glenn>	is the IDMEF meant to facilitate mechanical parsing of

 Glenn>	alerts
 Glenn>	(e.g. for display purposes)

 Glenn>	is the IDMEF meant for none of above ? Or, some	of both	of
 Glenn>	above

 Glenn>	This relates to	similar	format descriptions for	Action class too

 ------------------
 Dave

 According to the requirements document:

   IDMEF is planned to be a standard format which automated Intrusion Detection
   Systems (IDS) can use for reporting what they have deemed to	be suspicious

   or of interest.

 So the	answers	to your	questions would	be No, No, and None of the above.
 --------------

 Andy
 Yeah. Glenn, maybe check out the conversations	on the list from about 3

 weeks ago. This result	is one that everyone finally decided we	could live
 with, especially in regards to	the comments Dave metnioned about the

 requirements doc. I for one can't think of another representation I could
 agree with. But if you	have a specific	suggestion...

 --------------
 Cynthia

	 As Dave and Andy indicated, there has been substantial
	 discussion of this topic on the list and there	has been

	 difficulty getting consensus on a fixed list of values
	 to be used. Part of the problem is that it is not possible

	 to determine all of the possible alerts/actions that may be
	 generated in the future. In the absence of a perfect and

	 complete list of values, general categories with the specific
	 details left to free-form text	seemed like a reasonable
	 alternative. The general categories, given by attributes,
	 can be	used for automated processing; the free-form text

	 can be	used for providing the necessary flexibility. While
	 there may still be some adjustments that are desirable, for

	 example to attribute values, the current scheme provides a
	 combination of	structure and flexibility that should be

	 amenable to both analyzers and	managers.
 ----------

 PROPOSED RESOLUTION

    No Further comments	on the mail list, leave	as is.

 Glenn>	12. Sec. 5.2.7.1 The Node class

 Glenn>	I do not understand the	purpose	of the category. What will be criteria
 Glenn>	for filling this item? A name may belong to multiple domains

 Glenn>	in hosts file, dns and nis. A clarification may	be helpful.

 ----------
 Dave

 The category specifies	where the analyzer got the name	from; it doesn't matter
 if it could have gotten it from more than one place.  I changed the first part

 of the	description to read "the 'domain' from which the name information was
 obtained".

 ----------

 PROPOSED RESOLUTION
    No Further comments	on the mail list, leave	as is.

 *************************************************************************

 Glenn>	13. Sec	5.2.7.1.1. The Address Class

 Glenn>	I do not understand all	the ranks in the category. Are all these
 Glenn>	required. e.g. rank 7, 8 , 9 , 10?

 ----------

 Dave

 Addresses are used to represent hosts and users, that's why there's the kind
 of odd	mix.  And it was decided some time ago (two or three IDWG meetings ago)

 that networks needed to be represented	too.

 Why would you remove all four of the IPv4 notations?  IPv6 has	not taken over
 the world yet.

 ----------

 PROPOSED RESOLUTION
    No Further comments	on the mail list, leave	as is.

 *************************************************************************

 Glenn>	Do we require the domain name representation of	an address ? That is

 Glenn>	not present ?

 -----------------
 Dave

 Do you	mean PTR records?  Or something	else?
 -----------------

 Eric Williams
 I think Glenn means PTR's here	Dave.  My opinion is that since	PTR

 may be	unreliable unless all caches along the resolution path,	and
 the authoritative records, are	trusted	(not likely) you don't need

 that in or mapped to the Address class.
 ---------------

 PROPOSED RESOLUTION
    No Further comments	on the mail list, leave	as is.

 *************************************************************************

 Glenn>	14. Sec. 5.2.7.4.2 The SNMPService Class
 Glenn>	The significance and purpose of	this class is not clear. This is

 Glenn>	better dropped.
 ------------

 Dave

 I have	no objection, but I think the group needs to decide this, as it	has
 been in the draft since "Day 1."

 -----------
 Andy

 Who's out there that wants this? If we	drop SNMPService, does that

 indicate anything about dropping the WebService tag (or whatever its now
 called)?

 ----------
 Cindy

	 Is there a reason that	there are extensions to	Service	for
	 WebService and	SNMPService but	not other types	of services?

	 Having	argued for the re-instatement of action	and confidence,
	 I'm tending towards the cautious when it comes	to dropping

	 elements.
 ---------

 Eric Williams
 I think this was meant	to address issues of frequency of traffic use

 and to	segregate the additional information associated	with the
 service.  I don't think it goes any farther than that,	and I feel it

 is appropriate	for the	Service	context, particularly since it would
 dis-aggregate the traffic of interest from 'nominal' traffic for

 these services	in the format itself, where underdevelopment (or
 deprecation) of this 'sub/additional' class of	service	does not get

 us as close to	the "suspicious	or of interest." requirement as	the
 current specification.	 I am for keeping this in the spec.

 Others	are all	handled	well I think.

 ---------

 PROPOSED RESOLUTION
    No Further comments	on the mail list, leave	as is.

 *************************************************************************

-- 
Mike Erlinger, Professor and Chair Computer Science
www:      http://www.cs.hmc.edu/~mike
email:    [email-masked]
smail:    Computer Science Dept., Harvey Mudd College,
          301 E. 12th Street, Claremont, CA, 91711 
          909-621-8912,   FAX: 909-621-8465

---

From: "Glenn Mansfield Keeni" <[email-masked]>
Date: Tue, 11 Dec 2001 10:48:58 +0900

My coments are inline:
[The parts about which I do not have further comments are deleted.]

>  Glenn> That is what we want - right ?
Question: are we sure about "hexadecimal representation". I could not verify
whether this is decimal or hexadecimal. I thought it was decimal.
>5.2.
The document I have (draft-ietf-idwg-idmef-xml-05.txt) does not say anywhere
that AlertID is mandatory. Correct me if I am wrong.
  In Sec 4.4.9 item (2)
   2. The Alert, Heartbeat, Source, Target, Node, User, Process,
      Service, File, Address, and UserId classes' (Sections 5.2.2,
      5.2.3, 5.2.4.3, 5.2.4.4, 5.2.7.1, 5.2.7.2, 5.2.7.3, 5.2.7.4,
      5.2.7.5, 5.2.7.1.1, and 5.2.7.2.1) "ident" attribute, if
      specified, MUST have a value that is unique across all messages
      sent by the individual analyzer.
And in Sec 5.2.2. it says
  Alert is represented in the XML DTD as follows:

      <!ELEMENT Alert                           (
          Analyzer, CreateTime, DetectTime?, AnalyzerTime?, Source*,
          Target*, Classification+, Assessment?, (ToolAlert |
          OverflowAlert | CorrelationAlert)?, AdditionalData*
        )>
      <!ATTLIST Alert
          ident                 ID                      #IMPLIED

   The Alert class has one attribute:
   ident
      Optional.  A unique identifier for the alert, see Section 4.4.9.

I do not see the mandatory AlertID ? What am I missing ?
>  Glenn> alert. A clarification about this would probably avoid confusion.
Well, what happens when Alert 1 was received from sensor Aconfirmed by
Sensor B and forwarded  - in that case is the alert originated by B or
relayed
by B?
>  Glenn> This class seems to be mandatory. But all the constituent elements
are
Once again I seem to be reading the wrong document
Section 4.4.9 says
4.4.9 Unique Identifiers

   There are two types of unique identifiers used in this specification.
   Both types are represented by STRING data types.

   These identifiers are implemented as attributes on the relevant XML
   elements, and must have unique values as follows:

   1. The Analyzer class' (Section 5.2.4.1) "analyzerid" attribute, if
      specified, MUST have a value that is unique across all analyzers
      in the intrusion detection environment.

      The "analyzerid" attribute is not required to be globally unique,
      only unique within the intrusion detection environment of which
      the analyzer is a member.  It is permissible for two analyzers, in
      different intrusion detection environments, to have the same value
      for "analyzerid".

      The default value is "0", which indicates that the analyzer cannot
      generate unique identifiers.

and in 5.2.4.1 it says
  analyzerid
      Optional (but see below).  A unique identifier for the analyzer,
      see Section 4.4.9.

      This attribute is only "partially" optional.  If the analyzer
      makes use of the "ident" attributes on other classes to provide
      unique identifiers for those objects, then it MUST also provide a
      valid "analyzerid" attribute.  This requirement is dictated by the
      uniqueness requirements of the "ident" attribute (they are unique
      only within the context of a particular "analyzerid").  If the
      analyzer does not make use of the "ident" attributes however, it
      may also omit the "analyzerid" attribute.

>  I don't believe it does.  Source says "...is causing the event(s)."
Yes. But a network IDS may not know whether the source it sees is
indeed causing an event. There is a "Spoofed" flag - which may have
values yes/no/unknown.
>     No Further comments on the mail list, leave as is.
OK. Say that I have

      Type: ntpstamp
      Meaning: the ntp format timestamp when the action was taken against
                     the attack
Now say we do not have the type - what will be lost ?
And then Meaning is "optional" ?
Without meaning what will one make out the additionalData value ?
I understand the point. But I am afraid that keeping both enumerated and
free form in the same definition is revolutionary. General practice is to
keep enumerated with "other" as one of the candidates. How will the
parsers work and what meaning can be made out of the field. When
one sees a value how does one know whether it is one of the enumerated
values or some other free form encoding by some sensor. So now we will
have to define free form ...

>  Glenn> required. e.g. rank 7, 8 , 9 , 10?
I did not want to take off all of those!
Among the categories 7 and 10 say pretty much all that is there say about
IPv4
addresses (hosts and networks). I do not see the purpose of 8 and 9.
>  Glenn> Do we require the domain name representation of an address ? That
is
No. Just plain DNS addresses e.g. www.ietf.org. some analyzers (e.g. a log
analyzer ) may get a FQDNS only. It will have to use it as the address
unless
the address is optional (It is not.)
>  that in or mapped to the Address class.

Glenn

---

From: "David A. Curry" <[email-masked]>
Date: Tue, 11 Dec 2001 09:29:13 -0500

>>>>> On Tue, 11 Dec 2001, Glenn Mansfield Keeni, identified as "Glenn" below,
>>>>> wrote:

  Glenn> Question: are we sure about "hexadecimal representation". I could
  Glenn> not verify whether this is decimal or hexadecimal. I thought it was
  Glenn> decimal.

Yes, it should be hexadecimal - we're encoding "floating point" numbers (see
the ntp spec for exactly what they are).  The sentence and the example both
specify hexadecimal numbers.

  Glenn> 3. I am alarmed to see that Alert-ID is optional.

  Glenn> The document I have (draft-ietf-idwg-idmef-xml-05.txt) does not say
  Glenn> anywhere that AlertID is mandatory.

Whoops.  You found an error in the text -- the DTD fragment in Section 5.2.2
is wrong.  It should read:

	<!ATTLIST Alert
	    ident		CDATA		'0'

(it is correct in the DTD).  I have fixed this.

This specifies that "ident" (AlertID) will *always* appear to a manager (or
anything else parsing an IDMEF message).

Note that specifying a non-zero *value* for "ident" is optional (and has
always been so).  So it is "optional" in the sense that an analyzer does
not have to provide a value (and it does not have to do "ident=0" since
that's the default).

  Glenn> The text says: The Analyzer class identifies the analyzer from
  Glenn> which the alert or heartbeat message originates.

  Glenn> Well, what happens when Alert 1 was received from sensor Aconfirmed by
  Glenn> Sensor B and forwarded - in that case is the alert originated by B or
  Glenn> relayed by B?

For this to happen in the current IDMEF, B would have to pass the message
from A on to the manager without changing it in any way, so that it would
appear to the manager to have come from A.  So the answer to your question
is "it was originated by A and relayed by B."

Many moons ago (maybe around the time of the Australia meeting; I forget),
I proposed some tags to address the issue you describe (i.e., to identify
multiple relay points along the path).  The decision of the group at that
time was to focus only on direct analyzer-to-manager communications, and
not deal with this issue directly in this version of the format.

  +> No, the analyzerid attribute is not optional.

  Glenn> Once again I seem to be reading the wrong document Section 4.4.9 says
  Glenn> 4.4.9 Unique Identifiers

Same answer as above -- the DTD will ensure that "analyzerid" will always
be there.  It may have a value of zero, but it will always be there.

  +> Dave I don't believe it does.  Source says "...is causing the event(s)."

  Glenn> Yes. But a network IDS may not know whether the source it sees is
  Glenn> indeed causing an event. There is a "Spoofed" flag - which may have
  Glenn> values yes/no/unknown.

Okay, I changed it to "appears to be causing..."

  Glenn> 10. Sec 5.2.4.6 The AdditionalData Class The Type attribute seems to
  Glenn> be irrelevant.

  Glenn> OK. Say that I have

  Glenn> Type: ntpstamp Meaning: the ntp format timestamp when the action was
  Glenn> taken against the attack Now say we do not have the type - what will
  Glenn> be lost ? And then Meaning is "optional" ? Without meaning what will
  Glenn> one make out the additionalData value ?

If you don't have the type, you will have two hexadecimal numbers separated
by a period.  Those *might* be an ntpstamp.  They might also be a string
that just happens to look like an ntpstamp, but isn't one.  You have no
way of knowing without the type.

Meaning is optional because it may not be needed in the case of type=xml,
in which case the meaning would be provided by the elements.

  Glenn> 11. Sec 5.2.6 The Assessment Classes Is it OK to have "textual
  Glenn> descriptions of impact"?

  Glenn> I understand the point. But I am afraid that keeping both enumerated
  Glenn> and free form in the same definition is revolutionary. General
  Glenn> practice is to keep enumerated with "other" as one of the
  Glenn> candidates. How will the parsers work and what meaning can be made out
  Glenn> of the field. When one sees a value how does one know whether it is
  Glenn> one of the enumerated values or some other free form encoding by some
  Glenn> sensor. So now we will have to define free form ...

The enumerated portion lets managers do some (very) basic things with the
data.  The free format lets an analyzer provide additional detail *to a
human* -- it is not intended for use by managers.  If we could solve
that problem, we wouldn't need free format.

Nobody is "happy" with the current state., but we recognize that it's as
good as we can do at the moment.  It is fully expected that this issue
will be revisited and improved in a later revision, once we learn more.

  Glenn> 13. Sec 5.2.7.1.1. The Address Class I do not understand all the ranks
  Glenn> in the category. Are all these required. e.g. rank 7, 8 , 9 , 10?

  Glenn> I did not want to take off all of those!  Among the categories 7 and
  Glenn> 10 say pretty much all that is there say about IPv4 addresses (hosts
  Glenn> and networks). I do not see the purpose of 8 and 9.

Those were added at some meeting or another, I forget which one.  The ipv4-
net is to allow specification of address blocks (with ipv4-net-mask).  I
thing ipv4-addr-hex might just be for consistency with ipv6-addr-hex, but
I forget.

  Glenn> Do we require the domain name representation of an address?

  Glenn> No. Just plain DNS addresses e.g. www.ietf.org. some analyzers (e.g.
  Glenn> a log analyzer ) may get a FQDNS only. It will have to use it as the
  Glenn> address unless the address is optional (It is not.)

The FQDN would be encoded in the Node element that contains Address (and
in your case, you would just specify an empty Address with category set
to unknown).

--Dave

---

From: Cynthia McLain <[email-masked]>
Date: Tue, 11 Dec 2001 10:26:55 -0500

Hi Glenn and all,

My comments to selected items are included in-line.

> whether this is decimal or hexadecimal. I thought it was decimal.

4.4.7 NTP Timestamps

   NTP timestamps are represented by the NTPSTAMP data type, and are
   described in detail in [13] and [14].  An NTP timestamp is a 64-bit
   unsigned fixed-point number.  The integer part is in the first 32
   bits, and the fraction part is in the last 32 bits.

   Within IDMEF messages, NTP timestamps MUST be encoded as two 32-bit
   hexadecimal values, separated by a period ('.').  For example,
   "0x12345678.0x87654321".

   See also Section 7.4 for more information on NTP timestamps.

Seems pretty clear to me...

> I do not see the mandatory AlertID ? What am I missing ?

I think of the "real" alert id as being the Classification
(which is mandatory). Isn't the ident provided to allow
support for some sort of stateful alert processing? It
isn't clear to me how much use ident will get but it seems
good to have...optional seems fine in that case.

> >  Glenn> alert. A clarification about this would probably avoid confusion.
...
> Well, what happens when Alert 1 was received from sensor A, confirmed by
> Sensor B, and forwarded  - in that case is the alert originated by B or
> relayed by B?

It depends, if B changes or filters the Alert, for example if B is a
correlation engine, then B would produce its own alert so the alert
would originate from B. If B simply relays the Alert, the alert would
still originate from A. It seems like the current text is clear enough.

>       may also omit the "analyzerid" attribute.

   <!ATTLIST Analyzer
       analyzerid          CDATA                   '0'

Actually it isn't optional, per se, but there is a default
value. There does seem to be a potential problem in that
analyzerid needs to be an "ident" if idents are used elsewhere
but may be something else if idents aren't used elsewhere.
<$.02>
My suggestion is to make analyzerid #REQUIRED and add an
ident attribute that is used when the other idents are used.
</$.02>.

> >     No Further comments on the mail list, leave as is.

Do you want "...appears to be causing the event(s)"?

> Without meaning what will one make out the additionalData value ?

Won't the type help a manager figure out how to
parse/interpret the information? If the type is
xml, then the XML information could provide the
meaning (for example, if a DTD is specified). I
think it's fine as-is. Analyzers should just
"do the right thing".

> have to define free form ...

I don't think it's deserved, but thanks for calling
it revolutionary. :-) The enumerated values are preferred
over free-form text. The free-form text is provided to
allow the analyzer to capture information that is not
represented by the enumerated types. (It was the best we
could come up with so far). Perhaps the text in the IDMEF
draft should be enhanced to make the expected use of the
free-form text clear...

One example of where the free-form text would be useful
is when an Impact element with type set to "recon"
additionally specifies "limited" in the content. Please
see my message dated 11/04/2001 on the idwg mailing list.
It includes some examples of the use of content.

> addresses (hosts and networks). I do not see the purpose of 8 and 9.

NIS is very different from NIS+ so I don't see the
point of getting rid of 9 or 10. NDS also has
peculiarities all its own, so that leaves 8.

--Cindy