I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mile-sci-09.txt Reviewer: Alexey Melnikov Review Date: 2013-10-16 IETF LC End Date: 2013-10-22 Summary: This draft is nearly ready for publication as a Standard Track document. Major issues: I have a couple of IANA related questions/comments about this document. I hope they would be easy to address. In 4.1: The SpecID attributes of extended classes (Section 4.3) must allow the values of the specifications' namespace fields, but otherwise, implementations are not required to support all specifications of the IANA table and may choose which specifications to support, though the specification listed in the initial table needs to be minimally supported, as described in Section 5. In case an implementation received a data it does not support, it may expand its functionality by looking up the IANA table or notify the sender of its inability to I've been told in the past that IANA's website is not designed for mass retrieval of data by multiple devices. So very few (if any) specifications actually recommend automatic download of data from IANA's website. I think this needs to be discussed with IANA. parse the data by using any means defined outside the scope of this specification. In Section 7: Allocation Policy: Expert Review [RFC5226] and Specification Required [RFC5226] . (And similar text in 4.1: The table is to be managed by IANA using the Expert Review [RFC5226] and Specification Required [RFC5226] allocation policies as further specified in Section 7 . ) I think this is not very clear. If you just meant Specification required (which implies Expert review), I would describe it as: Allocation Policy: Specification Required [RFC5226] (which includes Expert Review [RFC5226]). If you meant for Expert Review to be used as an alternative when there is no specification, then you need to rephrase this to be clear. Minor issues: 4.2. Extended Data Type: XMLDATA This extension inherits all of the data types defined in the IODEF model. One data type is added: XMLDATA. An embedded XML data is represented by the XMLDATA data type. This type is defined as the extension to the iodef:ExtensionType [RFC5070] , whose dtype attribute is set to "xml." I think you meant "xml". I.e. the value doesn't include any dots. In 4.3.1: Platform: Zero or more. An identifier of software platform involved in the specific attack pattern, which is elaborated in Section 4.3.2 . It would be good to have an idea of what kind of values can be used. In particular I am thinking if you are planning to reuse any existing registries. In Section 9.1: [MMDEF] IEEE ICSG Malware Metadata Exchange Format Working Group, "Malware Metadata Exchange Format". [EICAR] European Expert Group for IT-Security, "Anti-Malware Testfile", 2003. These 2 references don't look Normative, as they are only used in an example. Nits: 1. Introduction To efficiently run cybersecurity operations, these exchanged information needs to be machine-readable. IODEF provides a structured means to describe the information, but it needs to embed various non-structured such information in order to convey detailed Delete "such" before "information"? If that is not the right fix, then I don't know what you were trying to say here. information. Further structure within IODEF increases IODEF documents' machine-readability and thus facilitates streamlining cybersecurity operations. In Section 3, last paragraph: Another example is that, when an administrator wishes to check the configuration of host computers in his organization, he may send a query to host computers, which may automatically generate XML-based software configuration information upon receiving thequery by running thequery --> the query a software and may embed that to an IODEF document, which is then sent back to the administrator. In 4.3.5: WeaknessID: OPTIONAL. STRING. An identifier of a weakness to be reported. This attribute SHOULD be used whenever such identifier is available/ Both RawData and Reference elements MUST NOT be used I think you meant "." instead of "/". when this attribute is used, while either of them MUST be used if this attribute is omitted. 4.3.7. Verifcation typo: Verification A Verification consists of an extension to the Incident.AdditionalData element with a dtype of "xml". The extension elements describes incident on vefifying incidents. typo: verifying