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

[Scott Bradner <[e-mail]>]

yup - tnx

Scott

> On Jan 25, 2022, at 3:53 PM, Henk Birkholz <[e-mail]> wrote:
> 
> 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?
>> Scott