Subject: [sacm] Robert Wilton's Discuss on draft-ietf-sacm-coswid-20: (with DISCUSS and COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 15 Feb 2022 02:28:52 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-sacm-coswid-20: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Sorry, but I have a couple of issues that it would be helpful to discuss ...

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?

Thanks,
Rob

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

   +-------+-------------------------+--------------------------------+
   | 4     | decimal                 | A floating point number (e.g., |
   |       |                         | 1.25 is less than 1.3)         |
   +-------+-------------------------+--------------------------------+
   | 16384 | semver                  | A semantic version as defined  |
   |       |                         | by [SWID].  Also see the       |
   |       |                         | [SEMVER] specification for     |
   |       |                         | more information               |
   +-------+-------------------------+--------------------------------+

I'm surprised to see 16384 assigned for Semver, is there a reason why are not allocating 5?

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 17 Feb 2022 11:16:16 +0100

Hi Rob,

analogous to Ben, we'll address your comments in sequence. Thanks a lot! 
Again, we hope to address all the discuss item at minimum until the 
upcoming cut-off.

Viele Grüße,

Henk