Re: [sacm] IETF LC Directorate reviews for draft-ietf-sacm-coswid

[Roman Danyliw <[e-mail]>]

Hi!

> -----Original Message-----
> From: Henk Birkholz <[e-mail]>
> Sent: Tuesday, January 25, 2022 3:54 PM
> To: Scott Bradner <[e-mail]>
> Cc: Roman Danyliw <[e-mail]>; [e-mail]; Salz, Rich
> <[e-mail]>; Robert Sparks <[e-mail]>
> Subject: Re: [sacm] IETF LC Directorate reviews for draft-ietf-sacm-coswid
> 
> Hi Scott,
> 
> yes, we added some clarifying text to section 6.2.
> 
> Does that address your open issue appropriately?
> 
> 
> Viele Grüße,
> 
> Henk
> 
> On 24.01.22 12:32, Scott Bradner wrote:
> >
> >
> >> On Jan 24, 2022, at 6:26 AM, Henk Birkholz
> <[e-mail]> wrote:
> >>
> >> And here are the corresponding responses. Scott, Rich, and Robert are
> included to the TO, analogously.
> >>
> >>> (1) Scott Bradner did an OPSDIR review --
> https://datatracker.ietf.org/doc/review-ietf-sacm-coswid-18-opsdir-lc-bradner-
> 2021-08-07/.  The following feedback does not appear to be discussed or
> resolved:
> >>>> along the same line - it would seem to me that the IANA repository
> >>>> should be at https://www.iana.org/assignments/coswid  (or co_swid)
> >>>> not https://www.iana.org/assignments/swid
> >>> I believe the comment is about the following text in a few places in Section
> 6.2.*:
> >>>     [TO BE REMOVED: This registration should take place at the following
> >>>     location: https://www.iana.org/assignments/swid]
> >>> Earlier in the text in Section 6.2:
> >>> "6.2.  Software Tag Values Registries
> >>>     The following IANA registries provide a mechanism for new values to
> >>>     be added over time to common enumerations used by SWID and
> CoSWID."
> >>> It would seem that if in fact things should stay in "assignments/swid",
> there is a missing registration procedure item -- nothing can be added if it isn't
> in the SWID specification.  I under the impression from earlier conversations
> that we wanted to provide flexibility for CoSWID to potentially extend it's own
> data model independent of SWID (i.e., there could be data elements in CoSWID
> that were not in SWID).  If so, this suggests that "assignment/coswid" should be
> used instead (as Scott was suggesting).
> >>
> >> This seems to be a misunderstanding that we did not capture well. The
> registry we are looking for must serve both the SWID space and the CoSWID.
> >> While these are fueled by two documents - namely from ISO-IEC and IETF - it
> is beneficial for interoperoperabitly to align them. Now - we understand that
> SWID is not CoSWID and that the IETF is not responsible in any way how ISO
> operates. Yet, IETF will be in charge of the registry from now on - and ISO
> action will have to work throgh the IETF process as defined in the I-D. And that
> is a decision made in consensus with the ISO authors and the SACM WG.
> >>
> >> There is no requirement in CoSWID or the registration procedures that
> require anything added to a registery must first exist in the ISO-IEC SWID
> specification.
> >>
> >> In summary, that is why it is okay to do the registry under 'swid'. This is also
> why the name 'swid' was chosen as a neutral name for software identification
> that can serve both uses for the registered values.
> >
> > OK - is that going to be clarified in the document?

Has something changed?  During the AD review (https://mailarchive.ietf.org/arch/msg/sacm/lZsk8wlOprU-WKPxgQAYLfBzDdE/):

==[ snip ]==
** There are a number of places in the text where normative guidance is framed as "SWID/CoSWID".  Is this document suggesting any behavior of SWID, or is that just a short-hand because this CoSWID is just a different representation of the SWID information (?) /data(?) model?  What is the SWID behavior relative to the IANA registries?

** In the long term, will SWID and CoSWID diverge and how should this be handled? This spec seems to defined a number of helpful extension points.  Does SWID have to use those? It might be helpful to clarify that in the text.  Section 2.2 (i.e., "The inclusion of extension points ...") and Section 2.3 ("... references to the IANA registries will be added to the next revision of [SWID]")hints that only future version of SWID might pick up these extensions.  The Section 5 IANA registrations call the registries "SWID/CoSWID" which seems confusing since SWID doesn't use them now.  Can you help me understand the state of play with SWID.  Without the background, it seems like a big leap that we're going to make registries for future work in another SDO (if they haven't already asked).
==[ snip ]==

I posed a similar question but the answer was different.  In these earlier discussions I walked away understanding that CoSWID was a fork of SWID and it was acceptable that minor inconsistencies.  The abstract even says " CoSWID supports a similar set of semantics and features as SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information."  For this reason, the IANA registry text present in -15 was even renamed from "SWID/CoSWID" to "CoSWID".

If I understand the explanation above correctly, now it seems that SWID is going to be using the CoSWID registries.  Does that imply some new co-evolution strategy?  Did something change from Fall 2021?

In rechecking the language in Section 6.* around which ranges have which registration procedures (standards action vs. specification required), I wanted to raise a two new points:

** (Based on unrelated discussions around the CWT registry that encountered a similar situation)  This document provides crisp guidance for the DE.  Should this DE guidance be applied for both "standards action" and "specification required" registry entries. I ask because per RFC8126, only "specification required" required applies DE review.  If you want DE review for all registrations s/standards action/standards action with expert review/.

** If SWID and CoSWID is going to be using these registries, does ISO understanding and it is intentional that SWID/ISO will not be able to register values in the lower/smaller "standards action" range?

Regards,
Roman