An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information
draft-ietf-mile-sci-13

The -12 version has addressed all the comments I had on the substance of the document, and thanks very much for considering and addressing those comments.  And particular thanks for the work on the Security Considerations section.

I had the following DISCUSS point, which I'm moving down here to a non-blocking comment:

-- Section 5 --

The shepherd writeup is silent about review by any XML schema experts.  How confident are we that the XML in here has had sufficient review?

One of the authors replied to this comment as follows:

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

Regarding the 1st discussion issue, I think the schema is fine, because

1. I myself have been checking the schema by using a schema validation tool, called "MSV".

2. I also have received feedback from a researcher in Japan who has been working for semantic web (that includes XML schema and RDF/OWL etc.)

3. From the MILE colleagues, I've received feedback on 23rd Feb, 2012
(http://www.ietf.org/mail-archive/web/mile/current/msg00553.html)

4. The IODEF-SCI tool we have implemented uses the schema without any error.
(https://github.com/TakeshiTakahashi/IODEF-SCI/wiki/IODEF-SCI-tools)

5. Though minor changes exist, the basic structure of the XML schema hasn't been changed at all almost for two years.

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

On (3), I see that the changes went into the -03 version of the document.  It's good to see that there was some schema review, and that errors were found and changes were made.  Thanks for that confirmation.

For some reason, I still have a nagging feeling about the XML review, but I'm moving to No Objection, and leaving it to the responsible AD to decide whether there's been enough review of the XML schema.  If Sean's OK with it, I'm OK with it.

I support Barry's DISCUSS points.

I note that the all-caps "URGED" in Section 6 is defined in neither RFC 2119 nor RFC 6169.  Might it be better to say "RECOMMENDED" here?

Thanks for handling my discuss points.

--- old comments below, I didn't check if they'd been
handled, feel free to ping me if I should check 
something

- section 3, last para: does this mean we're putting up
IODEF as an alternative to NEA and/or SACM? I think it'd
be better to drop that use-case or if not to distinguish
it from other IETF protocols that do the same thing. (Or
maybe I'm confused?)

- 4.1: I get weirdness when I try to de-reference the
1st reference URI [1], is that just me? I get a
directory listing for the 2nd. [2] When I look at [2]
and load the xsd file I find there, I don't find the
string "AttackPattern." How is that IANA registry entry
going to be useful? It confuses me mightily;-)

   [1] http://standards.ieee.org/develop/indconn/icsg/mmdef.html
   [2] http://grouper.ieee.org/groups/malware/malwg/Schema1.2/

- 4.1: I don't understand the last para at all

- 4.3: s/This draft/This specification/ (Same thing at
the start of section 5)

- section 5: Are you really asking that receiver's do
XML schema validation? You say "MUST be able to" which
is not quite the same, but generally doing schema
validation on the fly is very dangerous and error prone.
Maybe you mean that they MUST be able to process inputs
that conform to the relevant schema and fail-safe for
other inputs that don't conform? But at what level? Say
if an XML document is received that has a Remediation
element with no SpecID - should the entire input
Document be ignored or what?

- section 6: "URGED" in caps is odd, and saying "areas
of concern" but then only having one subsection seems
odd too.

- section 6 generally: I support Barry's discuss

- section 6: Isn't this missing something about access
control and filtering outbound documents?  Maybe all
that's needed is a reference to some other RFC, but
won't it be common to do such authorization and
filtering?

- section 6: You mention signatures - do you mean use of
XMLDSIG? If so, a reference would be good and it'd be
even better to say which element might be signed, and to
check that that element has an ID so the signature
Reference can point to the to-be-signed data.

- section 7: In the absence of a definition of
Cybersecurity, I think its a bad idea to have an IANA
registry with that term in the title.  (Just a personal
opinion.)