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

[Roman Danyliw <[e-mail]>]

Hi Henk!

> -----Original Message-----
> From: sacm <[e-mail]> On Behalf Of Henk Birkholz
> Sent: Tuesday, January 25, 2022 6:41 PM
> To: Roman Danyliw <[e-mail]>; Scott Bradner <[e-mail]>
> Cc: Salz, Rich <[e-mail]>; [e-mail]; Robert Sparks
> <[e-mail]>
> Subject: Re: [sacm] IETF LC Directorate reviews for draft-ietf-sacm-coswid
> 
> Hi Roman,
> 
> replies to your two new points in-line below:
> 
> On 25.01.22 22:42, Roman Danyliw wrote:
> > 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,Einverstanden. Wenn man erst mal ein Team ist und sich
> >> versteht dan
> >>
> >> 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/.
> 
> DE review is essential here, I think, and it would be useful to make use of that
> even in standards actions. Unless, you think that might impose an artificial
> bureaucratic disincentive for standards actions (which I personally do not think
> it does).

(Personal view) I agree with you -- the DE and related DE criteria should be used for all registrations (whether they fall into "specification required" or "standards action").  To make that the case, the text and tables which say a particular range is restricted to "standards action" need to read "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?
> 
> Yes, there is awareness about that outcome and it actually sets these
> registry actions a bit apart, which is not bad.

Understood.

To my earlier question above, did something change with how SWID would be managed?

Documenting the situation as discussed with Scott makes sense.

Thanks,
Roman

> >
> > Regards,
> > Roman
> 
> Viele Grüße,
> 
> Henk
> 
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm