[sacm] Francesca Palombini's No Objection on draft-ietf-sacm-coswid-20: (with COMMENT)

[Francesca Palombini via Datatracker <[e-mail]>]

Francesca Palombini 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 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.