Re: [sacm] Éric Vyncke's No Objection on draft-ietf-sacm-coswid-20: (with COMMENT)

[Henk Birkholz <[e-mail]>]

Dear Éric,

I just realized that we - of course - also addressed your comments :-) 
Actually we did that first.

Please also find them addressed in the iesg-eval branch on github.

> https://github.com/sacmwg/draft-ietf-sacm-coswid/tree/iesg-eval

References and replies are in-line, below.

Viele Grüße,

Henk

On 08.02.22 14:33, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-sacm-coswid-20: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document. The document is deep in CBOR &
> CDDL so my review is quite superficial as I do not have the expertise on these
> domains.
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
> 
> Special thanks to Christopher Inacio for the shepherd's write-up including the
> section about the WG consensus, but I would have preferred to see a
> justification for the intended status.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> # COMMENTS
> 
> There appear to be little traffic on the CBOR mailing list about CoSWID but
> Carsten Borman is in the acknowledgment section and I am trusting the ART AD
> for the CBOR review.
> 
> The id-nits tool detects a couple of issues (e.g., RFC 8126 and BCP 26 are
> duplicates).
> 
> ## Section 1
> 
>    "While SWID
>     and CoSWID are intended to share the same implicit information model,
>     this specification does not define this information model, or a
>     mapping between the the two data formats.  While an attempt to align
>     SWID and CoSWID tags has been made here, future revisions of ISO/IEC
>     19770-2:2015 or this specification might cause this implicit
>     information model to diverge, since these specifications are
>     maintained by different standards groups."
> 
> After reading the above, I was wonder whether there is still value to define
> such a 'moving target' specification. Suggestion: introduce the extension
> mechanism early in section 1.

Addressed in 29057dd

> 
> ## Section 2
> 
> Is there any reason why some CamelCase names (e.g., "version") are not
> identical in the KebabCase names (e.g., "software-version") ? This break
> automatic mapping for a minor improvement; hence, a short explanation would be
> welcome.

Yes, there is. We tried to adhere to the SWID nameing as best as we 
could, but in a select few cases we decided in concert with SWID a 
subset of the SWID authors to increase the precision a bit.

> 
> # NITS
> 
> ## Section 1
> 
> "...between the the two data formats...." ;-)
> 
> ## Other nits
> 
> "e.g." and "for example" should be followed by a ","
> 
> s/16 byte binary string /16-byte binary string / and similar

All nits are addressed in 425ee58

> 
> 
>