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

Scott Bradner <sob@sobco.com> Mon, 24 January 2022 11:32 UTC

Return-Path: <sob@sobco.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DC43A0EE5 for <sacm@ietfa.amsl.com>; Mon, 24 Jan 2022 03:32:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.916
X-Spam-Level:
X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_RDNS_DYNAMIC_FP=0.002, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAKsNqG4Dt8Y for <sacm@ietfa.amsl.com>; Mon, 24 Jan 2022 03:32:53 -0800 (PST)
Received: from sobco.sobco.com (173-166-5-71-newengland.hfc.comcastbusiness.net [173.166.5.71]) by ietfa.amsl.com (Postfix) with ESMTP id E34753A0EE3 for <sacm@ietf.org>; Mon, 24 Jan 2022 03:32:51 -0800 (PST)
Received: from smtpclient.apple (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 7A467229C06; Mon, 24 Jan 2022 06:32:50 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
From: Scott Bradner <sob@sobco.com>
In-Reply-To: <17f95b5f-2890-b658-eabb-4bee19ad3404@sit.fraunhofer.de>
Date: Mon, 24 Jan 2022 06:32:49 -0500
Cc: Roman Danyliw <rdd@cert.org>, sacm@ietf.org, "Salz, Rich" <rsalz@akamai.com>, Robert Sparks <rjsparks@nostrum.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E77143BB-F615-4DCF-A1EE-3504D88957AC@sobco.com>
References: <BN1P110MB0939568CF0E61FF364CD6B7EDCBF9@BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM> <17f95b5f-2890-b658-eabb-4bee19ad3404@sit.fraunhofer.de>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/9frKgww4NWEHs6xXqZpzGBrnhvE>
Subject: Re: [sacm] IETF LC Directorate reviews for draft-ietf-sacm-coswid
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2022 11:32:58 -0000


> On Jan 24, 2022, at 6:26 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> 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