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

[Adam Montville <[e-mail]>]

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. <[e-mail]> wrote:
> 
> Tony/Gunnar,
> 
> I agree. Details below.
> 
>> 	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.
>> 
>> 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.
> 
> 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
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm