[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?