An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information
Note: This ballot was opened for revision 10 and is now closed.
( spt ) Yes
Jari Arkko No Objection
( Richard Barnes ) No Objection
Comment (2013-11-19 for -11)
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?
( Stewart Bryant ) No Objection
( Gonzalo Camarillo ) No Objection
Spencer Dawkins No Objection
( Adrian Farrel ) No Objection
Stephen Farrell (was Discuss) No Objection
Comment (2013-12-06 for -12)
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 , is that just me? I get a directory listing for the 2nd.  When I look at  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;-)  http://standards.ieee.org/develop/indconn/icsg/mmdef.html  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.)
Brian Haberman No Objection
Comment (2013-11-19 for -11)
I support Barry's DISCUSS points.
Joel Jaeggli No Objection
Barry Leiba (was Discuss) No Objection
Comment (2013-12-12 for -12)
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.