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

Yves Lafon <ylafon@w3.org> Mon, 02 April 2012 13:30 UTC

Return-Path: <ylafon@w3.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B52F21F84FA; Mon, 2 Apr 2012 06:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf1pPjhwKeC8; Mon, 2 Apr 2012 06:30:39 -0700 (PDT)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF2021F84F7; Mon, 2 Apr 2012 06:30:39 -0700 (PDT)
Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from <ylafon@w3.org>) id 1SEhL8-0001Nx-3a; Mon, 02 Apr 2012 09:30:34 -0400
Date: Mon, 02 Apr 2012 09:30:34 -0400
From: Yves Lafon <ylafon@w3.org>
To: apps-discuss@ietf.org, draft-ietf-mile-sci.all@tools.ietf.org
Message-ID: <alpine.DEB.1.10.1204020528070.21068@wnl.j3.bet>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
Cc: mile@ietf.org
Subject: [apps-discuss] Review of draft-ietf-mile-sci-02.
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 13:30:40 -0000

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