Subject: [sacm] Proto consensus: Content decisions

From: "Schmidt, Charles M." <[email-masked]>
Date: Fri, 20 May 2016 19:20:28 +0000

Hello all,

Between the discussions at IETF 95 and the virtual interim yesterday, there
appears to be "in room" consensus on a few proposed updates and expansions
to SWID M&A. As no IETF consensus is complete without mailing-list
consensus, I'm sending out messages on each point of proto-consensus. This
email combines three separate items, but as they all seem to touch on the
core question of the nature of the content delivered by SWID M&A I'm going
to include them all here. These issues are:

1-	Support for both the 2009 and 2015 versions of the SWID
specification (Issue #2 from the slides presented at IETF 95 -
https://www.ietf.org/proceedings/95/slides/slides-95-sacm-3.pdf)
2-	Denotation of tag data format (ne bindings) (Issue #4 from the
slides presented at IETF 95)
3-	Selection of an MTI tag data format (Issue #5 from the slides
presented at IETF 95)

These three issues, as well as the ongoing thread initiated by Tony and
Gunnar regarding support for records other than ISO SWID tags, all relate to
what inventory evidence is collected and how it is represented in messages
to the SWID-PV. As such, it probably makes sense to discuss them together.

Item 1 above addresses that there are two revisions of the ISO SWID
specification, published in 2009 and 2015, respectively. These
specifications are not interoperable, although they both seek to address the
same use cases. As the 2015 specification is expected to replace the 2009
specification going forward, the group was asked if support for the 2009
specification should be deprecated in favor of the newer (and more capable)
2015 specification. At the meeting it was noted that virtually all existing
SWID tags in the world today use the 2009 format. The consensus in the room
was that support for 2009 ISO SWID tags should be retained to ensure this
existing evidence was not lost. [As an aside, given the current discussions
on supporting record structures other than ISO SWID tags, supporting for
both 2009 and 2015 ISO SWID tags would be a natural offshoot of such
flexibility.]

Item 2 above addresses that ISO SWID tags could, in theory, be represented
using multiple data formats. (Examples of data formats include XML, JSON,
CBOR, etc. In the slides I referred to this as "bindings" but I have since
been informed that using this term could lead to confusion.) The group was
asked whether multiple data formats for ISO SWID tags should be supported.
It was noted that certain classes of devices, such as resource-constrained
machines, might prefer more compact SWID representations, while others might
prefer XML. The consensus in the room was that support for multiple data
formats made sense. [As an aside, if there is consensus to support other
record structures beyond ISO SWID tags, those other record structures might
use any of a number of data formats. Thus flexibility in record structures
will need to imply flexibility in the formats supported.]

Item 3 above asks, "Given flexibility in data formats as described in Item
2, should any particular data formats be Mandatory to Implement?". The
observation was that, without an MTI binding, SWID-PCs and PVs could never
assume their correspondent would understand the information delivered
because it might be expressed using an unsupported data format. While an MTI
format cannot reasonably dictate the types of records that will be
discovered on an endpoint, it can ensure that SWID-PVs are able to process
certain types of records if they are found. During the discussion at IETF 95
it was observed that virtually all SWID tags in existence today are
expressed in XML, and the ISO SWID standard provides a normative XML Schema
for SWID tags but does not include normative structure definitions for other
bindings. Based on this, the group concluded that it made sense for XML to
be an MTI format for ISO SWID tags. [Now that we are looking into records
other than ISO SWID tags, the set of possible record types is broader. There
may be a case for adding other MTI record/format combinations. That will
require further discussion. However, as Adam noted in his email, we need to
start somewhere and ISO SWID XML tags seems like a reasonable starting
point.]

Hopefully that isn't combining too many different concepts at once. Please
respond if you have any questions or concerns about 1) supporting both 2009
and 2015 ISO SWID tags, 2) supporting multiple data formats for ISO SWID
tags, 3) identifying XML format ISO SWID tags as an MTI record+format for
the specification.

Thanks,
Charles