The Intrusion Detection Message Exchange Format (IDMEF)
RFC 4765

Received changes through RFC Editor sync (changed abstract to 'The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.

This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. This memo defines an Experimental Protocol for the Internet community.')

[Ballot comment]
I'm probably a No Objection on this to avoid delay, but
I note that there is nothing to tell the reader how
its success or failure as an Experimental spec will
be evaluated. Experimental does not mean de facto standard!

[Ballot comment]
I'm probably a No Objection on this to avoid delay, but
I note that there is nothing to tell the reader how
its success or failure as an Experimental spec will
be evaluated. Experimental does not mean de facto standard!

[Ballot comment]
If the XML Schema were normative I'd enter this as a discuss.  Since it's not, though, a comment will suffice.

XML namespaces minted in the IETF should be registered with IANA as described in RFC 3688.  This document uses an IANA URL to identify the namespace.

There's also some redundancy in the schema.  I see an empty derivation by restriction, for example:


 
 


Any place this type is referenced, xsd:string can be used instead since there's no actual restriction included in this definition.  What they've done with the above is create an alias for the Schema "string" type, which can make things confusing to understand.

[Note]: 'Returning for publication as an experimental RFC rather than a
proposed standard.  When I talked to the IESG about this the plan was
to completely remove the schema.  The authors really want appendix c
to stay as non-normative; if the IESG cannot accept this then we can
use an rfc editor note.' added by Sam Hartman

[Ballot comment]
Comment transferred from old ballot:

i think the point is

both water and air are allowed. one may be better for washing your
car.

[Ballot comment]
Comment transferred from old ballot:
>To: Randy Bush

> discuss

> ...

> 2) Section 3.3.4 mentions XML Schema and how they would one day use it.
> Well, it has been out for awhile, so why aren't they? If they
> switched from DTD's to XML Schema, they could probably get rid of half
> of the data type sections (3.4.1 to 3.4.6) and their entire need for UML.

This isssue is discussed in section 4.7 of
draft-hollenbeck-ietf-xml-guidelines-07.txt, recently approved as a BCP.
This section makes it clear that either a DTD or a Schema based approach
is permissible; neither one is inherently better than the other:

    The choice of tool depends on the needs for extensibility or for a
    formal language and mechanism for constraining permissible values
    and validating adherence to the constraints.

I read this as saying that unless a case can be made that these needs
aren't met by the chosen mechanism we should not be insisting they make a
different choice.

[Ballot discuss]
Dicuss comment transferred from old ballot:

needs to separate into at least two docs, the xml and transport model
and the particular application

xml-dir review comment

1) There is too much description and teaching about XML and UML. The
document should merely reference the XML and UML standards and explain
the restrictions and/or extensions to those specs in the definition of
IDMEF.

2) Section 3.3.4 mentions XML Schema and how they would one day use it.
Well, it has been out for awhile, so why aren't they? If they
switched from DTD's to XML Schema, they could probably get rid of half
of the data type sections (3.4.1 to 3.4.6) and their entire need for UML.

[Ballot discuss]
Discuss transferred from old ballot:

note:
      I would have thought that there should eb an IANA considerations
      section that at least points to sec 5 on how extensions
      can get made but also, I would have thought that sec 5 would
      have included what IETF proocesses (see RFC 2434) should
      be used to extend teh protocol

      I'm sensitive to this because we are getting a pile of
      requests to extend IETF protools (MPLS, RSVP etc) of
      late and we did not have any -must be extened within the
      ietf only- IANA mesage so we are being asked to OK
      some messy extensions - it woudl be good to cut this off at the
      pass and include such restrictions in new docs

[Ballot discuss]
Discuss comment transferred from old ballot:

Yes, I should have discovered this earlier, but this last week has been
too much. I just passed the document to the xml-directorate for review.
I will send in a new ballot as soon as I get a response.

This imply I hope this only have to wait until say monday, and not next
telechat before it can pass.

So, please, do the rest of the ballot!

[Ballot discuss]
Discuss transferred from old style text ballot:
I think I had a Defer (after initially thought I would be noObj.

But I need to rais a Discuss.

Section: 4.2.7.4.2 The SNMPService Class

The description of this Class shows only how to deal with SNMPv1/v2c
where authentication is done by (very weak) communitty String.

WWWWWe just made SNMPv1/v2c Historic. Of course they are still in
wide use, but SNMPv3 (which we just publsihed as STD 62) is already
deployed at many places and will get more and more deployment.

I think this document should recognize that and also address SNMPv3
where we no longer have a community String.

I also wonder if in the many examples on Pages 76 and folloing, if
it is OK to use domain names and IP addresses as they do. In other
words, do they violate one of our NITS:
        Addresses used in examples should prefer use of fully
  qualified domain names to literal IP addresses, and prefer use
  of example fqdn's such as foo.example.com to real-world fqdn's
  See RFC 2606 for example domain names that can be used
        There is also a range of IP addresses set aside for this
  purpose. These are 192.0.2.0/24 (see RFC 3330). Private
  addressess that would be used in the real world should be
  avoided in examples.

Let me add that the IPR section is also missing for this doc
that is targeted for STDs track.

IESG has finally come to a consensus on what needs to be
done to the document.

There are three major things that need to be done.  First,
and probably the hardest, the XML tutorial needs to be moved to an
appendix.  Second, an
IANA Considerations section needs to be added.  Third, the SNMP
discussion needs to talk about SNMPv3, and not just SNMPv1.

State Changes to Last Call Issued                                  from Requested                                        by jhargest