The Intrusion Detection Message Exchange Format (IDMEF)
RFC 4765

Note: This ballot was opened for revision 16 and is now closed.

(Scott Bradner) Discuss

Discuss (2005-08-18)
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

(Randy Bush) Discuss

Discuss (2005-08-18)
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.
Comment (2005-08-18)
No email
send info
Comment transferred from old ballot:

i think the point is

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

(Steven Bellovin) Yes

(Ned Freed) Yes

Comment (2005-08-18)
No email
send info
Comment transferred from old ballot:
>To: Randy Bush <randy@psg.com>

> 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.

(Sam Hartman) Yes

(Brian Carpenter) (was No Record, No Objection) No Objection

Comment (2006-03-02 for -)
No email
send info
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!

(Bill Fenner) No Objection

(Patrik Fältström) No Objection

(Scott Hollenbeck) No Objection

Comment (2006-02-27 for -)
No email
send info
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:

<xsd:simpleType name="mime-type">
  <xsd:restriction base="xsd:string">
  </xsd:restriction>
</xsd:simpleType>

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.

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) (was Yes) No Objection

Comment (2006-03-02 for -)
No email
send info
It would be helpful to have boilerplate about this not being
a standard.

(Thomas Narten) No Objection

(Jeffrey Schiller) No Objection

(Bert Wijnen) (was Discuss, No Objection) No Objection

(Alex Zinin) No Objection