Subject: [sacm] Call for adoption of draft-coffin-sacm-nea-swid-patnc as a SACM WG document

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 17 May 2016 16:21:51 +0000

Folks,

As discussed during our last couple of meetings, this is the official call for adoption of https://datatracker.ietf.org/doc/draft-coffin-sacm-nea-swid-patnc/ as a SACM working group document.

Please reply with any comments or concerns along your support of this action to the mailing list.

Thanks,
Karen and Adam

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 17 May 2016 16:50:52 +0000

I support adoption.

Regards,

Dan

From: sacm [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Tuesday, May 17, 2016 7:22 PM
To: [email-masked]
Subject: [sacm] Call for adoption of draft-coffin-sacm-nea-swid-patnc as a SACM WG document

Folks,

As discussed during our last couple of meetings, this is the official call for adoption of https://datatracker.ietf.org/doc/draft-coffin-sacm-nea-swid-patnc/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dcoffin-2Dsacm-2Dnea-2Dswid-2Dpatnc_&d=CwMFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=GEA5UGUTeAMvXRNQqw0fM7jl6M5Yybwo-9HPQniq4-g&s=KNFH3kQPLcd36Z_Z1RdbtmigJnUyywBQ6FG7b7HxEFQ&e=> as a SACM working group document.

Thanks,
Karen and Adam

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 17 May 2016 17:37:05 -0400

Remind us again why this ID references the 2009 version
of ISO/IEC 19770-2, when there a 2015 apparently significantly
different version has been adopted and is referenced in the
NISTIR 8060 as the basis for implementations?

It's interesting that the 2015 version for the GUID data
element references 19770-5.  It's great to see it's apparently
now publicly available at
https://www.iso.org/obp/ui/#iso:std:iso-iec:19770:-5:ed-2:v1:en

The version question seem rather significant for progressing
the working group document.  Was there some discussion
somewhere?

--tony

On 2016-05-17 12:21 PM, Karen O'Donoghue wrote:
> Folks,
>
> As discussed during our last couple of meetings, this is the official 
> call for adoption of 
> https://datatracker.ietf.org/doc/draft-coffin-sacm-nea-swid-patnc/ as 
> a SACM working group document.
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Michael Godsey <[email-masked]>
Date: Wed, 18 May 2016 00:18:00 +0000

I echo the concern and question.   If this points to the 2009 version, it needs to be updated.  Not only did we put a ton of work into revising the -2 standard for 2015, but this also obsoletes the 2009 version.  As noted the NISTIR 8060 was based entirely on the 19770-2:2015 version, leveraging the many changes implemented for better instrumentation and fidelity of tag data, tag relationships, etc.

From: sacm [mailto:[email-masked]] On Behalf Of Tony Rutkowski
Sent: Tuesday, May 17, 2016 2:37 PM
To: Karen O'Donoghue <[email-masked]>; [email-masked]
Subject: Re: [sacm] Call for adoption of draft-coffin-sacm-nea-swid-patnc as a SACM WG document

--tony

Thanks,
Karen and Adam

sacm mailing list

[email-masked]<mailto:[email-masked]>

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 18 May 2016 10:29:44 -0400

For those unfamiliar with this topic, there
is a fairly good explanation of why the old
2009 version was significantly flawed and
revised at:
http://tagvault.org/2015/06/11/isoiec-19770-2-revision-moving-to-publication/

--tony

ps. Still waiting for someone to request ISO
to make the specification publicly available
without coughing up CHF 178.  It's not that
difficult, and has been widely done for
important specifications.  It is also generally
required for standards that are imposed as
normative requirements by government.

On 2016-05-17 8:18 PM, Michael Godsey wrote:
>
> I echo the concern and question.If this points to the 2009 version, it 
> needs to be updated.Not only did we put a ton of work into revising 
> the -2 standard for 2015, but this also obsoletes the 2009 version.As 
> noted the NISTIR 8060 was based entirely on the 19770-2:2015 version, 
> leveraging the many changes implemented for better instrumentation and 
> fidelity of tag data, tag relationships, etc.
>
> *From:*sacm [mailto:[email-masked]] *On Behalf Of *Tony Rutkowski
> *Sent:* Tuesday, May 17, 2016 2:37 PM
> *To:* Karen O'Donoghue <[email-masked]>; [email-masked]
> *Subject:* Re: [sacm] Call for adoption of 
> draft-coffin-sacm-nea-swid-patnc as a SACM WG document
>
>     As discussed during our last couple of meetings, this is the
>     official call for adoption of
>     [email-masked] <mailto:[email-masked]>
>

-- 

________________________________ **

*Anthony Michael Rutkowski*

EVP, Industry Standards & Regulatory Affairs

[email-masked] <mailto:[email-masked]>

+1 703 999 8270 <tel:+1%20703%20999%208270>

________________________________ **

*Yaana Technologies LLC *

542 Gibraltar Drive

Milpitas CA 95035 USA

---

From: Jerome Athias <[email-masked]>
Date: Wed, 18 May 2016 17:58:21 +0300

Maybe a misread and difference between the Specification and the XML Schema
in 2.1.
"The SWID specification is available from ISO/IEC at
http://www.iso.org/iso/catalogue_detail.htm?csnumber=53670.
The XML schema for a SWID tag file is available from ISO:
http://standards.iso.org/iso/19770/-2/2009/schema.xsd.
The most current working and production versions of the XML schema for
SWID tags can be found in the directory listing
http://standards.iso.org/iso/19770/-2/.
The US National Institute of Standards and Technology (NIST) also has
published guidelines for
   SWID tag creation, which provide further guidance for those
   interested in the use and best practices surrounding SWID tags.
   [NIST-SWID]"

2016-05-18 17:29 GMT+03:00 Tony Rutkowski <[email-masked]>:
> I echo the concern and question.   If this points to the 2009 version, it
> needs to be updated.  Not only did we put a ton of work into revising the -2
> standard for 2015, but this also obsoletes the 2009 version.  As noted the
> NISTIR 8060 was based entirely on the 19770-2:2015 version, leveraging the
> many changes implemented for better instrumentation and fidelity of tag
> data, tag relationships, etc.
>
>
>
> As discussed during our last couple of meetings, this is the official call
> for adoption of
> https://datatracker.ietf.org/doc/draft-coffin-sacm-nea-swid-patnc/ as a SACM
> working group document.
>
>
>
> ________________________________
>
> Anthony Michael Rutkowski
>
> [email-masked]
> +1 703 999 8270
> ________________________________
>
> Yaana Technologies LLC
>
> 542 Gibraltar Drive
>
> Milpitas CA 95035 USA
>
>

---

From: Michael Godsey <[email-masked]>
Date: Wed, 18 May 2016 15:23:29 +0000

The current version of the 19770-2:2015 schema can always be found here (note difference from below):  
 http://standards.iso.org/iso/19770/-2/2015-current/schema.xsd 

The schema must be published along with and at the time of the standard, thus a "point in time" version is in the 19770/-2/2015/ directory.   The previous as-published version is in the 19770/-2/2009 directory structure as well.   However, the "up to date" version of the 2015 edition of the standard is always at the link above, the 19770/-2/2015-current/ directory. 

RE the NIST IR:  
A few weeks ago NIST hosted a workshop on SWID adoption (which I attended, along with other software publishers, some end customers, and reps from various US Govt agencies).  We mainly reviewed the final draft version (released April 2016)  of NISTIR 8060 – Guidelines for the Creation of Interoperable Software Identification (SWID) Tags.   
•	This NIST IR (plus related reference info) can be found on their portal at: http://csrc.nist.gov/publications/PubsNISTIRs.html 
•	Or here is a direct link to the NIST IR 8060 itself:  http://dx.doi.org/10.6028/NIST.IR.8060  

This is a really good reference which includes sections giving an overview of SWID Tags, the SWID Tag structure, and some implementation guidance for Tag creators.   I think this would be a good reference to include, as it is available without any paywall.   

Also in the TagVault board meeting yesterday we discussed the need to provide some help/guidance for adoption of SWID tags, similar to the NISTIR 8060, which being a US document is not appealing to all countries.   We decided to create a reference implementation guide which would come out of TagVault and be available to anyone.   I am guessing this should be available in maybe 3-4 months.  

-----Original Message-----
From: Jerome Athias [mailto:[email-masked]] 
Sent: Wednesday, May 18, 2016 7:58 AM
To: Tony Rutkowski <[email-masked]>
Cc: Michael Godsey <[email-masked]>; Karen O'Donoghue <[email-masked]>; [email-masked]
Subject: Re: [sacm] Call for adoption of draft-coffin-sacm-nea-swid-patnc as a SACM WG document

Maybe a misread and difference between the Specification and the XML Schema in 2.1.
"The SWID specification is available from ISO/IEC at http://www.iso.org/iso/catalogue_detail.htm?csnumber=53670.
The XML schema for a SWID tag file is available from ISO:
http://standards.iso.org/iso/19770/-2/2009/schema.xsd.
The most current working and production versions of the XML schema for SWID tags can be found in the directory listing http://standards.iso.org/iso/19770/-2/.
The US National Institute of Standards and Technology (NIST) also has published guidelines for
   SWID tag creation, which provide further guidance for those
   interested in the use and best practices surrounding SWID tags.
   [NIST-SWID]"

2016-05-18 17:29 GMT+03:00 Tony Rutkowski <[email-masked]>:
> For those unfamiliar with this topic, there is a fairly good 
> explanation of why the old
> 2009 version was significantly flawed and revised at:
> ps. Still waiting for someone to request ISO to make the specification 
> publicly available without coughing up CHF 178.  It's not that 
> difficult, and has been widely done for important specifications.  It 
> is also generally required for standards that are imposed as normative 
> requirements by government.
>
>
> needs to be updated.  Not only did we put a ton of work into revising 
> the -2 standard for 2015, but this also obsoletes the 2009 version.  
> As noted the NISTIR 8060 was based entirely on the 19770-2:2015 
> version, leveraging the many changes implemented for better 
> instrumentation and fidelity of tag data, tag relationships, etc.
>
>
>
> Subject: Re: [sacm] Call for adoption of 
> Remind us again why this ID references the 2009 version of ISO/IEC 
> 19770-2, when there a 2015 apparently significantly different version 
> has been adopted and is referenced in the NISTIR 8060 as the basis for 
> implementations?
>
> It's interesting that the 2015 version for the GUID data element 
> references 19770-5.  It's great to see it's apparently now publicly 
> available at 
> The version question seem rather significant for progressing the 
> working group document.  Was there some discussion somewhere?
>
> --tony
>

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 18 May 2016 12:29:14 -0400

Helpful, Michael,

Anyone planning to work on and publish
a derivative JSON version to reduce the bloat?
That could also assist in getting it out of ISO
land.

--tony

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Wed, 18 May 2016 17:38:24 +0000

Hi all,

To answer Tony's original question: "Why are we supporting the 2009 version of SWID tags given its known flaws?" - The question of whether to retain support for the 2009 SWID specification was raised at IETF 95 and, within that room, the consensus was to support both versions. The reason was that there are existing 2009 SWID tags deployed today and there was a desire to allow them to be delivered by SWID M&A. If SWID M&A only supported the 2015 SWID version, those older version tags are effectively lost to SACM assessment. Between this and the fact that the same design supports both versions of SWID tags (albeit using a slightly different procedure, which will be better clarified in the next revision), it seemed like there was little point in explicitly excluding collection and delivery of any 2009 tags that might exist.

Regarding Michael's comment about adding a reference to NIST IR 8060 - that sounds like a great idea to me.

Charles

> From: sacm [mailto:[email-masked]] On Behalf Of Michael Godsey
> Sent: Wednesday, May 18, 2016 10:23 AM
> To: Jerome Athias <[email-masked]>; Tony Rutkowski
> <[email-masked]>
> Cc: [email-masked]; Karen O'Donoghue <[email-masked]>
> The schema must be published along with and at the time of the standard,
> thus a "point in time" version is in the 19770/-2/2015/ directory.   The
> previous as-published version is in the 19770/-2/2009 directory structure as
> well.   However, the "up to date" version of the 2015 edition of the standard
> is always at the link above, the 19770/-2/2015-current/ directory.
> 
> RE the NIST IR:
> A few weeks ago NIST hosted a workshop on SWID adoption (which I
> attended, along with other software publishers, some end customers, and
> reps from various US Govt agencies).  We mainly reviewed the final draft
> version (released April 2016)  of NISTIR 8060 – Guidelines for the Creation of
> Interoperable Software Identification (SWID) Tags.
> •	This NIST IR (plus related reference info) can be found on their portal
> at: http://csrc.nist.gov/publications/PubsNISTIRs.html
> This is a really good reference which includes sections giving an overview of
> SWID Tags, the SWID Tag structure, and some implementation guidance for
> Tag creators.   I think this would be a good reference to include, as it is
> available without any paywall.
> 
> Also in the TagVault board meeting yesterday we discussed the need to
> provide some help/guidance for adoption of SWID tags, similar to the NISTIR
> 8060, which being a US document is not appealing to all countries.   We
> decided to create a reference implementation guide which would come out
> of TagVault and be available to anyone.   I am guessing this should be
> available in maybe 3-4 months.
> 
>

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 18 May 2016 14:16:38 -0400

Hi Charles,

Thanks.  Useful to have this information.  On
checking the presentation, this topic is indeed
treated on the Issue 2 slide.  What is somewhat
disconnected, however, is that although the
slide says there is support for both, only 2009
presently appears.  There is also a strong case
made for dropping both, as well as describing
the 2009 tags as a small minority in the near
future.  Is there any actual data here?

Cudos to whoever put together the slides.
Nicely done.  Any answer to the JSON question?

Two questions not asked: who might do the
work to bridge the gap with the gazillion other
software identifier approaches out there, and
whether some form of out-of-band SWID capability
(as is used with may of the other SWID mechanisms)
cannot be included.  For a lot of IoT stuff, it is
essential.

--tony

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 18 May 2016 11:27:34 -0700

> cannot be included.  For a lot of IoT stuff, it is

This right here is an excellent point.  There are other software ID 
mechanisms out there and SWID is not going to cover everything for which 
there is an alternative.

Because this proposal is so SWID-specific, I can't get behind it. 
However, if it was genericized to allow for use of current and possible 
future tagging mechanisms, I could certainly support that.

--gun

---

From: "Cheikes, Brant A." <[email-masked]>
Date: Wed, 18 May 2016 18:33:16 +0000

It is also worth noting that p. 17 of the final NIST IR 8060 does indeed reference the publicly-available 2015 SWID XSD using the same URI that Michael shows below, namely:
http://standards.iso.org/iso/19770/-2/2015-current/schema.xsd

/Brant

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Michael Godsey
Sent: Wednesday, May 18, 2016 11:23 AM
To: Jerome Athias <[email-masked]>; Tony Rutkowski <[email-masked]>
Cc: [email-masked]; Karen O'Donoghue <[email-masked]>
Subject: Re: [sacm] Call for adoption of draft-coffin-sacm-nea-swid-patnc as a SACM WG document

RE the NIST IR:

---

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

Tony/Gunnar,

I agree. Details below.

> This right here is an excellent point.  There are other software ID
mechanisms
> out there and SWID is not going to cover everything for which there is an
> alternative.
> 
However, if it
> was genericized to allow for use of current and possible future tagging
> mechanisms, I could certainly support that.

This makes sense. Even those strongly attached to the use of SWID tags would
like to make sure that this specification can handle future revisions of the
ISO SWID specification, and as you both note, there are other structures out
there which people might wish to use.

Basically, it seems to me that we want to support a common, core set of
functionality related to inventory and inventory events, but that we want to
have some flexibility in the data (I'll call these "records") used to convey
that information to a policy server. Are we in agreement on this? (I don't
think we want the nature of what one can infer from a report to change based
on the record structure used to convey that report.)

Given this, the following are the core capabilities of SWID M&A for
reporting records as I see them:
1) Records need to be associated with specific instances of a specific
software product and version thereof. 
--- If the same version of the same product is installed multiple times,
there will need to be multiple records naming the same product and version -
one associated with each actual installation. (We need to convey that a
given product+version is installed "exactly X times" rather than "at least
one instance".)
--- Changes to a software product need to result in a change in the
associated record. (The record needs to distinguish between AcmeApp v1.2.3
and AcmeApp v1.2.4, since this is critical to multiple consumers of this
data.)
--- Records associated with a product+version need to be consistent over
time and across endpoints. (There needs to be an easy way for the SWID-PV to
say "this is the same product+version" across different reports and between
reports from different machines.)
2) If the record is more than about 200 bytes, there needs to be a concise
identifier for this record. In SWID tags, this is created by the combination
of the TagCreatorRegID and the TagID fields. (Concise identifiers are used
in multiple places in SWID M&A to convey information without bloating
messages.)

Do you (or anyone) have any questions or concerns about any of these core
capabilities, or have any others to add? I think all of the other SWID M&A
capabilities (monitoring for changes, tracking and ordering of events,
subscriptions, processing targeted requests, etc.) are fairly neutral with
regard to the record structure used in messages assuming the two
requirements above are met. Let me know if you disagree about that.

Capabilities do not need to be inherent in the record itself. (For example,
there is nothing in a SWID tag that allows one to distinguish between
multiple installations of a single product.) There just needs to be a
reliable, deterministic mechanism by which these capabilities can be met
while using the record. 

I will work on putting together some proposals on how different record types
can be clearly labeled in SWID M&A messages so recipients can know the type
of content they are getting prior to parsing. (Probably want a way for
SWID-PVs to express a preference too... need to think about this.) While I
am doing that, if you have a favorite non-ISO-SWID record that you would
like to see supported, could you put together any necessary requirements
that would be needed to ensure it aligns with the core capabilities
described above? I think that would be very useful for fleshing out this
flexibility.

I am interested in your thoughts on this. Thanks for the input.

Charles

---

From: Adam Montville <[email-masked]>
Date: Thu, 19 May 2016 19:37:19 -0500

This is a good discussion.

From my personal perspective, I would not want to preclude other identification mechanisms from being used in the future, but we do have to start somewhere and grow from there.  In that light, I do not believe this draft should marry our work to SWID and only SWID till death do us part.  Software identification has to be flexible—that’s just the reality of it.  But, at some point, there has to be a semantic layer to pull it all together.

The second point I want to make is that this is a call to adopt the draft into the working group, presumably to do work on it.  So the fact that the draft currently only references this or that version of a standard matters less now than if it makes its way to IESG down the road.

Kind regards,

Adam

> On May 19, 2016, at 3:27 PM, Schmidt, Charles M. <[email-masked]> wrote:
> 
> Tony/Gunnar,
> 
> I agree. Details below.
>

---

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

Hi Tony,

I think some of your concerns are in the process of being addressed in the
thread discussing support for other types of software identifiers (Subject =
"Call for adoption of draft-coffin-sacm-nea-swid-patnc as a SACM WG
document") but I wanted to make sure I addressed all your
questions/concerns.

> presently appears.  

I don't have any hard data here, but I would not be surprised if there have
yet to be an 2015 version tags published in the wild. The 2015 specification
was only released late last year, so I wouldn't be surprised if most vendors
who have pledged support for SWID tags have yet to update their processes.

> There is also a strong case

No actual data, I'm afraid. I base my comment on the observation that there
doesn't seem to be any voices saying they prefer the 2009 version to the
2015 version. (As you noted in a previous email, the 2009 version has a
number of issues.) Given that, the number of 2009 tags should pretty much
cease to grow, while the number of 2015 tags should increase, especially if
certain large vendors follow through on promises to support more
comprehensive ISO SWID coverage of their products. So this was a speculation
on my part (as hopefully indicated by my noting that 2009 tags "should be" a
minority in the future), but I think a reasonable one.

> Nicely done.  

Thank you.

>Any answer to the JSON question?

I have not heard of any actual efforts to create a JSON data format for SWID
tags, but Henk's CBOR binding
(https://datatracker.ietf.org/doc/draft-birkholz-sacm-coswid/) might address
most of your concerns about XML's size.

> cannot be included.  For a lot of IoT stuff, it is

Hopefully this concern is going to be addressed by the plan to open up the
specification to support other record formats (as described in the "Call for
adoption...." thread mentioned earlier.

Please let me know if I have misunderstood your concerns.

Thanks,
Charles

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 20 May 2016 11:51:18 -0700

Inline...

> in multiple places in SWID M&A to convey information without bloating

I tried to find fault, but I think as a basic core set, this is good 
coverage.

In ongoing practice there are undoubtedly going to be more capabilities 
desired for other use cases, and some tagging solutions will have useful 
capabilities that are not available in others. Extensibility is assumed.

I think it's also a necessity that a common data model be used 
regardless of the tag type/source.  For hopefully obvious reasons.