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

[Henk Birkholz <[e-mail]>]

And we create the proposal here:

> https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/46

:-)

On 25.01.22 21:53, Henk Birkholz 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
> 
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm