[sacm] Robert Wilton's No Objection on draft-ietf-sacm-coswid-21: (with COMMENT)
Robert Wilton via Datatracker <noreply@ietf.org> Mon, 21 March 2022 12:55 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: sacm@ietf.org
Delivered-To: sacm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDA43A1A6E; Mon, 21 Mar 2022 05:55:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sacm-coswid@ietf.org, sacm-chairs@ietf.org, sacm@ietf.org, Christopher Inacio <inacio@cert.org>, Karen O'Donoghue <odonoghue@isoc.org>, inacio@cert.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <164786735123.7485.9071110363221240259@ietfa.amsl.com>
Date: Mon, 21 Mar 2022 05:55:51 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/odvWhsV_r9205TovpzdYrQ-PW-s>
Subject: [sacm] Robert Wilton's No Objection on draft-ietf-sacm-coswid-21: (with COMMENT)
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.29
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, 21 Mar 2022 12:55:56 -0000
Robert Wilton has entered the following ballot position for draft-ietf-sacm-coswid-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, I've discussed this with Roman and Henk and I've agreed to remove my discuss so that the document can be approved and move forward before the new IESG handover. The proposal for the two issues below are: (1) I think that it would be helpful to have a liaison statement between the SACM WG and ISO that confirms the ongoing expectation and evolution of SWID and CoSWID, i.e., my understanding is that ISO intends to reuse the IANA registry and I think that it would be good to get that more formally confirmed now whilst everyone agrees, so that this doesn't end up being a problem in future when participants have changed and moved on to new projects. This doesn't need to block the progression of this document, it could be done in parallel. I also don't think that this had to be written into the document, but possibly a comment in the document may be helpful to set the context for future readers. (2) Regarding the Semver 2.0.0 reference, the suggestion from Roman, which I agree with is that it would be better if the SEMVER reference cited the ITU SWID spec as the normative reference and the current accurate github reference becomes informative. ---------------- Previous discuss comments: 1. While an attempt to align SWID and CoSWID tags has been made here, future revisions of ISO/IEC 19770-2:2015 or this specification might cause this implicit information model to diverge, since these specifications are maintained by different standards groups. This text concerns me, in that it seems that the IETF is expecting or allowing the SWID and CoSWID specification to diverge. Would it be possible to have stronger text here? E.g., to indicate: - the intent is to keep the two spec's consistent. - nothing should be added to CoSWID without working with ISO/IEC to update CoSWID - if SWID evolves then CoSWID should be similarly updated. Or, otherwise, are ISO/IEC okay with the IETF effectively forking their specification in future? 2. [SEMVER] Preston-Werner, T., "Semantic Versioning 2.0.0", <https://semver.org/spec/v2.0.0.html>. I want to check whether this URL is stable enough for a normative reference. During the YANG Semver work we discovered, that despite the Semver specification stating that is follows the Semver rules, in fact it doesn't! Specifically, the specification has been updated without changing the version number. The proposed solution for the YANG semver draft was to reference a specific data and revision of the "YANG Semver 2.0.0" specification in github. the YANG Semver 2.0.0 specification on a given data. [semver] "Semantic Versioning 2.0.0 (text from June 19, 2020)", <https://github.com/semver/semver/ blob/8b2e8eec394948632957639dfa99fc7ec6286911/semver.md>. Would doing something similar be wise here?
- [sacm] Robert Wilton's No Objection on draft-ietf… Robert Wilton via Datatracker