Concise Software Identification Tags
draft-ietf-sacm-coswid-24

Thank you for the work on this document.

Many thanks to Rich Salz for his review: https://mailarchive.ietf.org/arch/msg/art/adGh-_pOSDVJObN06Qps2Scilts/ and thanks to the authors for addressing it.

I support Rob's first DISCUSS point: I had the same reaction when reading that text. I also have some additional comments, mostly having to do with the use of SHOULD in the document.

Francesca

1. -----

   *  If the patch item is set to "true", the tag SHOULD contain at
      least one link item (see Section 2.7) with both the rel item value
      of "patches" and an href item specifying an association with the
      software that was patched.

   *  If the supplemental item is set to "true", the tag SHOULD contain
      at least one link item with both the rel item value of
      "supplemental" and an href item specifying an association with the
      software that is supplemented.

FP: This is missing text about why these are SHOULD and not MUST or MAY. I agree with John Klensin, who formulated it very clearly:

If SHOULD is used, then it must be accompanied by at least one of:
 (1) A general description of the character of the exceptions and/or in what areas exceptions are likely to arise.  Examples are fine but, except in plausible and rare cases, not enumerated lists. 
 (2) A statement about what should be done, or what the considerations are, if the "SHOULD" requirement is not met. 
 (3) A statement about why it is not a MUST.

2. -----

   *  artifact (index: 37): To be used with rel="installation-media",

FP: Should "installation-media" be "installationmedia" instead?

3. -----

   *  date (index 35): The date and time the information was collected
      pertaining to the evidence item.

FP: Please add a reference to Section 3.4.1	[RFC8949] and mention that this is the standard date/time string.

4. -----

      space, the "decimal" version scheme SHOULD be used.

FP: Here (and following bullets) is another case that either requires a better context description about the use of SHOULD, or should be rephrased (possibly avoiding the BCP 14 SHOULD) for example:

      space, it is expected that the "decimal" version be used.

5. -----

Section 4.3 

FP: Another place where SHOULD appears without explanation.

Hi,

I've discussed this with Roman and Henk and I've agreed to remove my discuss so that the document can be approved and move forward before the new IESG handover.

The proposal for the two issues below are:

(1) I think that it would be helpful to have a liaison statement between the SACM WG and ISO that confirms the ongoing expectation and evolution of SWID and CoSWID, i.e., my understanding is that ISO intends to reuse the IANA registry and I think that it would be good to get that more formally confirmed now whilst everyone agrees, so that this doesn't end up being a problem in future when participants have changed and moved on to new projects.  This doesn't need to block the progression of this document, it could be done in parallel.  I also don't think that this had to be written into the document, but possibly a comment in the document may be helpful to set the context for future readers.

(2) Regarding the Semver 2.0.0 reference, the suggestion from Roman, which I agree with is that it would be better if the SEMVER reference cited the ITU SWID spec as the normative reference and the current accurate github reference becomes informative.

----------------

Previous discuss comments:

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

This text concerns me, in that it seems that the IETF is expecting or allowing the SWID and CoSWID specification to diverge.

Would it be possible to have stronger text here? E.g., to indicate:
 - the intent is to keep the two spec's consistent.
 - nothing should be added to CoSWID without working with ISO/IEC to update CoSWID
 - if SWID evolves then CoSWID should be similarly updated.

Or, otherwise, are ISO/IEC okay with the IETF effectively forking their specification in future?


2.
   [SEMVER]   Preston-Werner, T., "Semantic Versioning 2.0.0",
              <https://semver.org/spec/v2.0.0.html>.

I want to check whether this URL is stable enough for a normative reference.  During the YANG Semver work we discovered, that despite the Semver specification stating that is follows the Semver rules, in fact it doesn't! Specifically, the specification has been updated without changing the version number.  The proposed solution for the YANG semver draft was to reference a specific data and revision of the "YANG Semver 2.0.0" specification in github.
 the YANG Semver 2.0.0 specification on a given data.

   [semver]   "Semantic Versioning 2.0.0 (text from June 19, 2020)",
              <https://github.com/semver/semver/
              blob/8b2e8eec394948632957639dfa99fc7ec6286911/semver.md>.

Would doing something similar be wise here?

Thank you for this document. I found it an interesting read.

Also, much thanks to Scott Bradner for his OpsDir review, and to the authors for addressing it.

Thanks for the document.

I would appreciate a verbose explanation of TBD1 and TBD2, not really clear what they are.

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

Many thanks for the updates in the -21 to address my previous
Discuss and Comment points; it was a pleasure to read.

A few final notes on the -21 (with I think just one remaining
unchanged from my previous remarks):

Section 2.3

   *  tag-version (index 12): An integer value that indicate the
      specific release revision of the tag.  Typically, the initial
      value of this field is set to 0 and the value is increased for
      subsequent tags produced for the same software component release.

To apply a slightly finer point to my previous comment, do we want to
s/increased/incremented by one/?

Section 2.7

   *  rel (index 40): An integer or textual value that (integer label
      with text escape, see Section 2, for the "Software Tag Link Link
   [...]
      relations/link-relations.xhtml as defined by [RFC8288].  When a
      string value defined in the IANA "Software Tag Link Relationship
      Values" registry matches a Relation Name defined in the IANA "Link
      Relation Types" registry, the index value in the IANA "Software
      Tag Link Relationship Values" registry MUST be used instead, as
      this relationship has a specialized meaning in the context of a
      CoSWID tag.  String values correspond to registered entries in the
      "Software Tag Link Relationship Values" registry.

I'm not sure if the last sentence still makes sense (there were heavy
edits near it as part of the move to "integer label with text escape").
A similar comment applies to "use (index 42)" as well.

Section 2.9.2

My previous inquiry about forcing a certain filesystem structure on
CoSWID consumers got a very helpful reply.  My follow-up question is: is
it worth mentioning in the document the corollary of the [Co]SWID
structure that the on-filesystem path is fixed by the tag publisher?

Section 5.2

                               Tags to be evaluated (the base
   collection) include all tags in the context of where the "swidpath
   URI" is referenced from.  For example, when a tag is installed on a
   given device, that tag can reference related tags on the same device
   using a URI with this scheme.

This definition of "the context" feels rather under-specified and prone
to conflicting interpretations.

NITS

From -20 to -21 a number of internal references changed from Section 2.5
to "Section 2.4, paragraph 2", which mostly don't seem to make sense to
me.  Please double-check.

Section 2.3

   *  version-scheme (index 14): An integer or textual value
      representing the versioning scheme used for the software-version
      item, as an integer label with text escape (Section 2, for the

needs a close paren somewhere

Section 9

   Converse, generators of CoSWID tags need to ensure that only public

"Conversely"