Subject: [mile] Review of draft-ietf-mile-sci-02.

From: Yves Lafon <[email-masked]>
Date: Mon, 2 Apr 2012 09:30:34 -0400 (EDT)

All,
I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see [1]).

Document: draft-ietf-mile-sci-02
Title: IODEF-extension to support structured cybersecurity information
Reviewer: Yves Lafon
Review Date: April 2, 2012

Review Summary:  This draft is almost ready for publication, small 
important issues needs to be addressed or clarified before publication.

Document Summary:
The document define a 'wrapper' document to present in a common format 
different cybersecurity report formats.

Major Issues:

There are two issues.
* In the normative reference section, there are reference to many document 
where the licensing information is not clear, like [CAPEC]. It would be 
good to clarify the license information of the documents linked in the 
normative section.

* The schema provided is invalid, this line needs to be fixed based on 
intent:
       <xsd:attribute name="dtype" type="iodef:dtype-type"
        use="prohibited" value="xml"/>

Both issues are major issues as they need being fixed, but I consider them 
easy to fix.

Minor Issue:

In the definition of 'AttackPattern' class, the restriction in the prose 
(4.3.1) is not expressed in the schema.
<<
AttackPatternID:  OPTIONAL.  STRING.  An identifier of an attack
       pattern to be reported.  This attribute SHOULD be used whenever
       such identifier is available, but could be omitted if no such one
       is available.  In this case, either RawData or Reference elements,
       or both of them, MUST be provided.
Same issue with 'Platform', 'Vulnerability', 'Weakness', 'EventReport', 
'Verification'...
Also the other MUST-level requirement of ensuring consistency of the value 
might be tested using a schematron schema, that could be a useful addition 
if the goal of the schema is to provice automated verification.

In the example, the foreign namespaces definition also include links to 
schemas, it might be better to remove those and keep in the main schema 
the list of possible namespaces (and their schemas), ie: keep the schema 
referring to other schema for people requiring schema validation, and 
remove verbosity in instances (it should affect only the definition of 
XMLDATA). The downside being that the main schema  needs to be updated 
when the list in 4.1 is updated (and schema link should be in the list in 
4.1).

HTH,

[1] <http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 3 Apr 2012 11:50:02 +0900

Thank you very much, Yves, for your kind review.
I appreciate that very much.

Let me modify the draft to handle the issues you kindly pointed out along
with the other issues raised at the Paris meeting.

Kind Regards,
Take

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yves Lafon
> Sent: Monday, April 02, 2012 10:31 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [mile] Review of draft-ietf-mile-sci-02.
> 
> All,
> Both issues are major issues as they need being fixed, but I consider
> them easy to fix.
> 
> Minor Issue:
> 
> when the list in 4.1 is updated (and schema link should be in the list
> in 4.1).
> 
> HTH,
> 
> [1]
> <http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirec
> torate>
> 
> --
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile