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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
