Subject: [Gen-art] Gen-ART LC Review of draft-ietf-mile-sci-09

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Oct 2013 14:40:23 +0100

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

---

From: "Black, David" <[email-masked]>
Date: Thu, 17 Oct 2013 16:58:56 -0400

Alexey,

> Expert Review [RFC5226]).

That was the intent; your suggestion is clearer.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexey Melnikov
> Sent: Thursday, October 17, 2013 9:40 AM
> To: [email-masked]
> Cc: <[email-masked]> Team; The IESG
> Subject: [Gen-art] Gen-ART LC Review of draft-ietf-mile-sci-09
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 21 Oct 2013 23:27:47 +0900

Hello Alexey and all,

Thank you very much for your kind comments.
Let me comment inline below.

> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Thursday, October 17, 2013 10:40 PM
> Subject: Gen-ART LC Review of draft-ietf-mile-sci-09
> 
Gen-ART,
> please see the FAQ at

Thank you very much for your kind assistance.

> Please resolve these comments along with any other Last Call comments you
> may receive.
> 
> 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.

Thank you very much for your kind comment on this issue.
I understood. I believe I should change the sentences.

I do not have any intention to encourage users to dynamically access to or
download the data from IANA.
I think automatic download is not necessary since I am not expecting the
IANA table to change so frequently.
Users of IODEF-SCI tools may manually look up the IANA table and change
configuration of the tools, if needed.
Indeed, the tools we implemented and published in the Github has a local
table that copies the contents of the IANA table, but the copy was done
manually (not automatically).

So, I would like to change the last sentence as below.

   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
   parse the data.  Note that the look-up could be done manually or
   automatically, but automatic download of data from IANA's website is
   not recommended since it is not designed for mass retrieval of data
   by multiple devices.

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

The sentences in Section 4.1 is now as follows.

   The table is to be managed by IANA following the allocation policy
   specified in Section 7.

The sentences in Section 7 is now as follows.

      Allocation Policy: Specification Required (which includes Expert
      Review) [RFC5226].

> I think you meant "xml". I.e. the value doesn't include any dots.

The sentence is now as follows.

   attribute is set to "xml".

> particular I am thinking if you are planning to reuse any existing

The Platform class is defined in Section 4.3.2, and values such as CPE
identifiers are used there.
In this case, the values are chosen from the registries (= CPE dictionary,
http://nvd.nist.gov/cpe.cfm ).

>                "Malware Metadata Exchange Format".

Indeed, MMDEF is a specification that needs to be minimally supported (MTI).
(In Section 4.1, this specification (MMDEF) is chosen as an initial entry of
the IANA table, and Section 5 (Mandatory to implement features) says that
the specifications listed in the initial IANA table needs to be supported.)
So, we need MMDEF as an normative reference.

example.

I've moved it to the informative reference section

> Delete "such" before "information"? If that is not the right fix, then I
> don't know what you were trying to say here.

Deleted.

>     software configuration information upon receiving thequery by running

Fixed.

> I think you meant "." instead of "/".

Fixed.

>        this attribute is omitted.

Fixed.

>     elements describes incident on vefifying incidents.

Fixed.

Again, thank you very much for your kind comments.
The attached is the fixed one.

Kind regards,
Take