Re: [sacm] CoSWiD review

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Mon, 25 March 2019 14:23 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E3112038C; Mon, 25 Mar 2019 07:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kDWoJDeHjEv; Mon, 25 Mar 2019 07:23:08 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CD81203D0; Mon, 25 Mar 2019 07:23:06 -0700 (PDT)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x2PEMvQR027906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Mar 2019 15:22:58 +0100
Received: from [31.133.157.13] (31.133.157.13) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 25 Mar 2019 15:22:52 +0100
To: Chris Inacio <inacio@cert.org>, "draft-ietf-sacm-coswid@ietf.org" <draft-ietf-sacm-coswid@ietf.org>, "sacm@ietf.org" <sacm@ietf.org>
References: <etPan.5c98d92a.174793da.1328d@cert.org>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <259d3c88-f992-691d-02f4-96dbbdb1fa4f@sit.fraunhofer.de>
Date: Mon, 25 Mar 2019 15:22:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <etPan.5c98d92a.174793da.1328d@cert.org>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [31.133.157.13]
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/H2CjwJ-IyqLmzp3VwQISXXv-VzE>
Subject: Re: [sacm] CoSWiD review
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2019 14:23:12 -0000

Hi Chris,

first of all, thank you for your feedback!

Sitting in secdispatch right now, I'll address the most prominent ones 
(which means there will be a follow-up before the SACM session) in a 
timely fashion.


On 3/25/19 2:35 PM, Chris Inacio wrote:
> General: I’m going to assume that the CDDL has been validated. Is there 
> a method of checking/ensuring that?

The included CDDL data definition in 2.8 always is always valid.

Is the only tool for CDDL still the
> Ruby based tool from Carsten?

For the moment - yes. This will change in the foreseeable future (I 
cannot speak on behalf of proprietary solutions).

> 
> Section 2.5: Same thing as the unspsc, can we do better than just having 
> a raw URI in the document as reference: http://www.w3.org/TR/xpath20/

Yes, there has to be an alternate representation to the XML Path 
Language at some point, but this is out-of-scope of this document and 
also in itself a separate gap to be addressed (not only for use in CoSWID).

Hence, it seems like a a good approach to accommodate for further to be 
expected alternate representations in this version of CoSWID already, 
for example... a CBOR/CDDL based one.

> 
> Section 2.6: Is there a better reference for unspsc, other than having a 
> link in the middle of the document.

This depends on the result. If, we break semantic interoperability with 
ISO/IEC 19770-2:2015 or violate the principle of least surprise, the 
answer might be no.
Up to be discussed in the WG, I think :)

> 
> Section 3.2: The roles/values in the table I think should align with the 
> role values defined in the CDDL 2.8.

2.8 at the moment contains the consistent updated version.
The fragments illustrated throughout the document are mostly not 
updated, therefore sometimes incorrect and have to aligned. This is an 
open issue that is in the progress of being addressed.

> 
> Section 2.3: Still have a TBD for more description.

We have to talk about 2.3. and similar cases. Maybe the best approach is 
to reduce the semantic representation, off-load the burden of those 
(already defined semantics) and "just make this a text type?
Up to be discussed in the WG, I think :)


> 
> NITs:

Please expect a follow-up reply :)

Viele Grüße,

Henk

> 
> Abstract: “Next to the inherent capability of SWID tags to express 
> arbitrary context information, Concise SWID (CoSWID) tags support the 
> definition of additional semantics via well-defined data definitions 
> incorporated by extension points.”
> 
> I’m not sure I’m okay with that sentence - it makes a lot of assumptions 
> of the reader and their familiarity with SWID, and also, I’m not sure 
> that SWID can represent arbitrary context information. And, please be 
> clear about what context information.
> 
> Section 2.6: Depending on how a software organizations distributes 
> revisions, this
> this value could be specified in a primary (if distributed as an value 
> could be specified
> 
> Organizations -> organization
> 
> Table in section 3.2: Can you change the description to be more 
> “…definition…” [ref] instead duplicating it as “From [SAM] 
> ”…description…“ ”. The “[ref]” basically means this is from that source. 
> (Chris’ personal style preference here, so up to authors to ignore this.)
> 
> 
> 
> --
> Chris Inacio
> inacio@cert.org
>