Re: [sacm] CoSWiD review

[Henk Birkholz <[e-mail]>]

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
> [e-mail]
>