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

[Henk Birkholz <[e-mail]>]

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

On 15.02.22 11:28, Robert Wilton via Datatracker wrote:
> 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?
> 
> 
>