Re: [apps-discuss] [mile] Review of draft-ietf-mile-sci-02.

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: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of
> Yves Lafon
> Sent: Monday, April 02, 2012 10:31 PM
> To: apps-discuss@ietf.org; draft-ietf-mile-sci.all@tools.ietf.org
> Cc: mile@ietf.org
> Subject: [mile] Review of draft-ietf-mile-sci-02.
> 
> 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/ApplicationsAreaDirec
> torate>
> 
> --
> Baroula que barouleras, au tiéu toujou t'entourneras.
> 
>          ~~Yves
> 
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile