Status of IDMEF

Dear all,

after some silence on the mailing list, I am happy to inform all of you
that some progress has been made on the IDMEF draft. Here is the current
list of issues and what has been done to resolve them. Please refer to
the ML archives for a complete description of issues.

IESG Comment section 3.1.3:
--> Change "IDMEF-compliant applications SHOULD" to "IDMEF-compliant
applications MUST" and drop the 2 other paragraphs in the section.

IESG Comment section A.3.4:
--> drop paragraph. Move to schemas not done yet, need to port all DTD
modifications to the schema file. Planned to either -12 (time
permitting) or -13.

IESG Comment section 3.2:
--> UNRESOLVED. May be resolved by moving to schemas.

IESG Comment section 3.2.4:
--> RESOLVED BUT NOT DISCUSSED. Comment reinserted below for reference.
> [[
> Using XML character references to encode binary data seems seriously
> broken to me.  Character references in XML denote Unicode code points,
> *not* byte values.  I suggest looking to the XML encryption work for
> ways to encode binary data in XML.
> ]]
>
> Now I haven't a clue what this document is specifiying.  There is a
> reference to a BYTE datatype, but no description I can see of how it
> is encoded in XML.
In current draft BYTE has been specified as base64.

IESG Comment section 4:
--> There is only one draft.

IESG Comment section 3.2.5:
--> Enumerated types section simplified and amended.

IESG Comment section 4 (namespaces):
--> UNRESOLVED
> This part contains a number of enumerated string values.  It seems to
> me that these could more usefully be assigned URIs (maybe, URNs).
> Using XML namespaces, these could then become element names, with all
> but the last part of the URI being the namespace URI.  I think this
> would better support the claimed requirement (section 2.1.1) for easy
> extensibility.

IESG Comment section 5:
--> UNRESOLVED - HAS NOT BEEN DISCUSSED
> I'm uneasy about the approach to extensibility, particularly DTD
> extensions.  For an Internet standard it feels rather fragile,
> depending on things like XML parameter-entity references within a
> DTD-declaration.   This is a gut feel, which I cannot substantiate.
Herve> I don't get this. Should we ignore it ?

IESG Comment section 2.2.1
--> UNRESOLVED. I think we should register a namespace with IANA. Mike ?
>> Also, despite this in section 2.2.1:
>> [[
>>    In anticipation of the widespread use of XML namespaces, this memo
>>    includes the definition of the URI to be used to identify the IDMEF
>>    namespace.
>> ]]
>> I could not find a definition of the namespace URI.

IESG Comments section 7
--> Fixed in document by substituting version=3D"1.0" with version=3D"1.0=
"
xmlns=3D"????". This is pending resolution of issue above. This needs to
be fixed back into Section 1 of DTD.

IESG Comment section 7.8
--> UNRESOLVED. I'll try to run the thing by an XML expert (at least the
DTD) once everything else is resolved.
>> Section 7.8:
>>
>> The example contains what I think is an incorrect attempt to use XML
>> namespace prefix 'VendorCo:'.  Specifically, there is no
>> xmlns:VendorCo declaration in the XML data.  I don't think the attempt
>> to define the namespace in the DTD is valid ... or if it is, I don't
>> think it's advisable, because it means the namespace cannot be
>> identified without access to the DTD.
>>
>> (I'm not certain about this, and think it should be run by an XML
>> expert.)

[Issue 1] Duplicate name in classifications
[Issue 2] Incomplete URLs for Classifications in examples
[Issue 6] Classification and name
[Issue 7] Classification and URL
[Issue 8] Classification and ident
--> RESOLVED. The structure of the Classification class has changed
heavily. The Classification class now provides name and ident for the
alert, and the Reference class carries the former Reference data. A
user-specific tag has been added.
--> THIS NEEDS TO BE DISCUSSED/VALIDATED.

[Issue 3] additionaldata and meaning
--> PROPOSED RESOLUTION. I propose to leave the specification of the
keyword list for meaning to a BCP draft, unless somebody undertakes to
provide me with such a list.

[Issue 4] additionaldata and encoding
--> PROPOSED RESOLUTION: leave as is and add some text to meaning saying
that it should provide an idea of the way to access the data, e.g.
"packet-payload-as-base64". There seems to be little consensus here, and
there may be a conflict with the general encoding of the document.

[Issue 5] duplicate information related to protocol information.
--> RESOLVED: Modified definition of Service class and precised wording.

[Issue 9] Alert routing
--> RESOLVED: Added self-reference to analyzer and usage text.

[Issue 10] Severity scale too narrow
--> UNSOLVABLE :-). I think that adding an integer there is quite risky.

[Issue 11] Informational messages
--> RESOLVED. Use the "info" keyword for severity.

[Issue 12]Messages too verbose
--> RESOLVED. We know XML messages are large, compress them and use
ident references.


I'll send the current draft in another message. Please let me know what
you think.

Herv=E9
--=20
Herv=E9 Debar             <mailto:[email protected]>
Tel: +33 (0)2 31 75 92 61            GSM: +33 (0)6 74 09 09 66
France T=E9l=E9com R&D                   Fax: +33 (0)2 31 75 93 13
42 rue des Coutures  (--)  BP 6243  (--)  F-14066 Caen Cedex 4