[sacm] Benjamin Kaduk's No Objection on draft-ietf-sacm-coswid-21: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sacm-coswid-21: 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/about/groups/iesg/statements/handling-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:
----------------------------------------------------------------------

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"