Last Call Review of draft-ietf-mile-sci-09
review-ietf-mile-sci-09-genart-lc-melnikov-2013-10-18-00

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