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

[Éric Vyncke via Datatracker <[e-mail]>]

É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.

## 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.

# 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